[erlang-questions] where did my code come from?

[Jesper Louis Andersen]

On Wed, Sep 14, 2011 at 08:46, Bengt Kleberg <bengt.kleberg@REDACTED> wrote:
> Greetings,
>
> This email mentions import renaming. Does that include solving the
> problem that two modules I want to load have the same name?

Well it depends,

You can rename a module when you import it, or
you can rename a module when you export it.

The latter has no meaning in Erlang. All modules are by default
exported under the name they were written with and there is full
visibility. So in Erlang, only import renaming makes (easy) sense. The
idea is then, that you can write an import declaration with renaming
to make a more digestible name locally in an application. But this
doesn't allow for two modules with the same name in the Erlang
Runtime.

It is silly I have to write etorrent_event:notify/2 when in my
application, event:notify/2 would be as good. On the other hand, it
doesn't save me much in the typing department, and it is another level
of proxying my brain has to process.

Another way is to allow modules of the same name, but add some
qualifier when referring to them. So you can say "The module in the
stdlib application" when you import them.

I initally wanted a more expressive module system because I saw it as
necessary for being able to evolve the standard library, while keeping
the old systems on track. The idea was to bulid an alternative stdlib
next to the current one and then prefer it for applications. I've
however come to the conclusion it would be better to add a tool like
Golangs "gofix". Gofix is an indentation-aware syntax fixer and
library upgrader. The idea is that when the basis library is changed,
gofix can be invoked to automatically bring programs up to date as
well. In many cases the application is completely mechanic and can be
used to ease the burden on programmers when using old versions of the
code.

In Erlang the basis is already there. One just has to consider
Wrangler. With an upgrade tool, we could begin evolving the stdlib to
make it more streamlined and consistent. Since Erlang has no types, we
can't easily fix the order of function arguments, but many other cases
can be fixed - and that while providing backwards compatibility
through mechanical upgrade of old source code. It also avoids the
issue with maintaining more than one standard library.



-- 
J.