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

[Richard Carlsson]

Just to hammer down the point: the runtime system never sees
two different modules called lists. The import_as would cause
the names to be substituted at compile time. Atoms that are
not necessarily module names by context would either have to
be written fully qualified from start, or be wrapped in some
construct that marks them for expansion, such as:

   -import_as(foo, my_foo)
   ...
   f() ->
       gen_server:start(i_am_a_module_name(foo), ...)

(It would actually be a very good thing if all atoms that in
fact are used to name modules, would be marked up as such, in
one way or another. Dialyzer and other analyses would be much
helped by this. Currently, Erlang programs are way too liberally
sprinkled with random atoms which turn out to be a module name.)

The basic point is: you never pass an atom that represents a
module name to anyone else unless it is already fully qualified.

     /Richard

Bengt Kleberg wrote:
> Greetings,
> 
> How does the erlang run time handle 2 modules called lists?
> 
> Which lists module will those other modules that have not done
> -import_as(lists, stdlib_lists).
> get?
> 
> 
> bengt
> 
> On Wed, 2008-03-05 at 21:23 +1100, Anthony Kong wrote:
>> Hi, Shiwei,
>>
>> I'd concur that a capability to alias an imported module sounds like
>> an attractive idea.
>>
>> I personally would prefer a new directive called "import_as".
>>
>> ======
>> -module(lists). %% I want to call my module lists too.
>> -import_as(lists, stdlib_lists).
>>
>> ...
>> lists:copycat() ->
>>   stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c])
>>
>> ======
>>
>> Just the same as your idea of "-alias".
>>
>> Until then, I probably have to learn to live in this namespace flatland :-)
>>
>> Cheers, Anthony
>>
>>
>>
>> 2008/3/1 shiwei xu <xushiweizh@REDACTED>:
>>> I think flat module namespaces is a defect of erlang design.
>>>
>>> For example, I write a foo.erl, It works well. But maybe in a late erlang
>>> version (eg. R13B)  also write such  module named  foo.erl. Then,  you can
>>> see  my application goes wrong.
>>>
>>> How to avoid things like this? Let's see the following ways:
>>>
>>> 1. Adjust module searching paths, and let user path (which contains my
>>> foo.erl) take precedence over erlang stdlib/otp path. But, this way can't
>>> always work well. If some other stdlib/otp modules use system foo.erl (not
>>> my foo.erl), Things goes wrong.
>>>
>>> 2. Write erlang modules always named with a prefix (a fake namespace. For
>>> example, projectname_foo.erl or organization_projectname_foo
>>> .erl). This way really can solve the problem. But, It seems ugly.
>>>
>>> Is there a way let's user still can call foo:func (not call foo.erl provied
>>> by stdlib/otp, but my projectname_foo.erl)? I have a suggestion:
>>>
>>> Can erlang provide a 'module name alias'? That is, I can rename a module's
>>> name temporarily in a module? For example:
>>>
>>> -module(a_module_that_call_my_foo).
>>> -alias(foo, organization_projectname_foo). %% alias
>>>
>>> some_func_call_foo() ->
>>>     foo:func().  %% same as: organization_projectname_foo:func()
>>>
>>> Currently I can do this by using the 'define' keyword. For example:
>>>
>>> -module(a_module_that_call_my_foo).
>>>  -define(FOO, organization_projectname_foo). %% alias
>>>
>>> some_func_call_foo() ->
>>>     ?FOO:func().
>>>
>>> It works well, but a bit ugly.
>>>
>>>
>>>
>>> On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff <sysop@REDACTED> wrote:
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 29, 2008, at 14:34, Anthony Kong wrote:
>>>>
>>>>> If I rename c.erl to something else, the problem goes away.
>>>>>
>>>>> What is special about "-module(c)" ?
>>>>   Welcome to the world of flat module namespaces.
>>>>
>>>>   The code module is your friend in these circumstances.
>>>>   Look into code:clash() and code:which(module).
>>>>
>>>>   code:which(c) should return "<base path>/lib/erlang/lib/stdlib-
>>>> <ver>/ebin/c.beam"
>>>>
>>>>
>>>> -Matt
>>>> --
>>>> Matt Stancliff            sysop@REDACTED
>>>> AIM: seijimr              iPhone: 678-591-9337
>>>> "The best way to predict the future is to invent it." --Alan Kay
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>> _______________________________________________
>>>  erlang-questions mailing list
>>>  erlang-questions@REDACTED
>>>  http://www.erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions