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

[Bengt Kleberg]

Greetings,

I would like to be hammered a little bit more, please. Since it sounds
difficult to handle at compile time I would like to ask how this will
work. We have the following:
stdlib-0/ebin/lists.beam
a/ebin/lists.beam
b/ebin/b.beam

Erlang is started and lists.beam from directory a is loaded. Then b.beam
is loaded.
b contains a call to lists:reverse/1.
Will b get lists from a or stdlib-0/ebin ?

I know which lists b want, but how does the erlang run time know?


bengt

On Wed, 2008-03-05 at 15:21 +0100, Richard Carlsson wrote:
> 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
> 
> 
>