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

[Christian S]

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.