[erlang-questions] Why do we need modules at all?
Tue May 24 15:16:24 CEST 2011
2011/5/24 Frédéric Trottier-Hébert <>
> 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
name ! Pid
Mod = load([ .... lists of funs ...])
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,
> 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
> 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
> Fred Hébert
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions