[erlang-questions] Why do we need modules at all?

[Joe Armstrong]

2011/5/24 Frédéric Trottier-Hébert <fred.hebert@REDACTED>

> The problem of Erlang with regards to namespaces and modules goes further
> than just module names. In Erlang, the following units can be
> sharing/clashing namespaces: the process registry, ETS tables, module names,
> application names, shared records, etc. They're currently entirely disjoint
> and only held together by convention.
>

Absolutely - and inconsistently

We can say

     Pid = spawn(fun() -> ... end)
     Pid ! M
     register(name, Pid),
     name ! Pid

But not

     Mod = load([ .... lists of funs ...])
     Mod:reverse(...)
     register(lists, Mod)
     lists:reverse(..)

same comment for ets tables etc.


However, any change to one of the solutions needs to somehow be reflected
> into the others, even if it's still by convention.
>
> IMO the basic hierarchy of Erlang seems to begin with the OTP release. The
> name of an OTP application will decide the prefixes used in module names,
> process names, table names, shared record names, etc. There is nothing to
> check that application names are unique except the programmer looking out
> for that, while xref and the compiler can help a bit with the rest.
>
> I think we can generalise OTP to have this given kind of organisation:
>     release -> OTP applications -> [Modules, Tables, Shared Records,
> Processes]
>
> An application itself wouldn't have to worry about namespaces (if we forget
> included applications). The namespace problem comes at the release stage or
> if we're developing entirely outside of OTP, still using applications or
> their equivalent.
>
> To me, this makes it feel like namespace management/giving aliases and
> replacement of values should be managed from the release point of view, but
> I can't offer any suggestions as to how this could take place without
> relying on file renaming and strict use of ?NAMESPACE-like macros throughout
> the code. Nothing easily backwards compatible, and nothing to help people
> who are not using releases though.
>
> This in no way would solve Joe's problem with being undecided as to where
> functions should go, but I think getting rid of modules altogether in Erlang
> wouldn't be doable because of the other dependencies. In places like
> Javascript (client-side) or schemes without good module functionality, you
> pretty much just include the files and people then tend to wrap everything
> in functions or objects to provide an ad-hoc equivalent to namespaces or
> modules. I can see this behaviour emerging if Erlang were to go that way.
>
>
I agree - it's not just "getting rid of modules" there's a whole load of
other stuff.


> --
> Fred Hébert
> http://www.erlang-solutions.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110524/7d104fbd/attachment.htm>