[erlang-questions] newbie: why c.erl is special?

Richard Carlsson richardc@REDACTED
Wed Mar 5 15:06:57 CET 2008


The compiler expands all module references to their fully qualified forms,
so at runtime, there is no aliasing problem.

The one thing programmers have to think about, is that if you pass "just
some atom" as an argument to some function, the compiler will not expand
that atom, so if you are giving the name of a module (e.g., as a callback),
you need to make sure to use the fully qualified form.

So yes, there is an assymetry: module names used in explicit calls are
expanded, but "plain atoms" are not. On the positive side: it's a rather
simple approach that works pretty well and is fully compatible with
existing code without adding new datatypes to the language.

But since parameterized modules (which came later) require adding a
first-class module data type (currently implemented as tuples), all the
code which currently assumes (and checks) that module callbacks are atoms
would need to be rewritten in any case, so encoding the namespace structure
in the (full) module names is not the only way.

But personally, I think I actually like the package system as it is. It is
straightforward and works, and does not add *too* much cruft to the
language. I know that some people consider it "inside out", but i think
it's an advantage to have each module clearly state its full name. That
provides stability and enables you to build a vocabulary of modules you
know, and you don't have to look in another file to find out what the
name used to access the module in the current file is supposed to be.

Sure, you can define a whole sub-language for specifying how modules
are composed out of other modules and how this module in that file over
there is actually called Brian who is known as Brian, but there is a
thing such as too much flexibility getting in the way of getting things
done. On the other hand, I loathe long module names such as
'megaco_per_bin_media_gateway_control_v2' (or nasty surprises for newbies,
such as 'c') , so some namespace control is definitely needed.

     /Richard

Christian S wrote:
> On Wed, Mar 5, 2008 at 12:29 PM, Richard Carlsson <richardc@REDACTED> wrote:
>>  I planned to implement exactly this, but never got around to it.
>>  I'll fix it if I can find some spare time.
> 
> A problem with aliases is that the expectation is that an atom will
> identify the same module even when it crosses boundaries into code
> from other modules.
> 
> 
> Scenario:
> 
> I define a behaviour for creating/looking up cookie sessions in a
> webserver. (With the intention that one could back end it in files,
> mnesia or a sql rdbm.)
> 
> I tell the webserver to use the module stupidly identified by the name
> 'session' that implements this behaviour.
> 
> The webserver has a -import_as/-alias where 'session' is an alias for
> a module that is not the same as my module.
> 
> ...problems! Or at least confusion.
> 
> 
> 
> 
> As I see it, there needs to be a first-class module-type to get around
> it. A resolved module. Something that is not an atom.
> 
> "Module = module(session)" the same way there is "Fun = fun M:F/A"
> (rather than the old {M,F} wart).
> 
> The value of module(Atom) would globally identify the module locally
> known by the name in Atom.
> 
> 
> 
> Or is there some more clever way to get around the problems in
> module-local aliases?
> 
> 
> PS.
> I think this name-space-discussion has occurred two-three times the
> years I have been following the list.






More information about the erlang-questions mailing list