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

[Bengt Kleberg]

In my mind the problem that module renaming should solve is "modules
with the same name in the Erlang Runtime".

The gofix tool, does it handle leagacy/binary code?


bengt

On Wed, 2011-09-14 at 18:26 +0200, Jesper Louis Andersen wrote:
> 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.
> 
> 
>