[erlang-questions] Why we need a -module() attribute?

[Benoit Chesneau]

On Thu, Feb 25, 2016 at 10:37 AM Joe Armstrong <erlang@REDACTED> wrote:

> On Thu, Feb 25, 2016 at 8:24 AM, Benoit Chesneau <bchesneau@REDACTED>
> wrote:
> > i'm not sure if people complained but that the second time at least that
> > such topic fall on the mailing list to my knowledge.
> >
> > One sure thing though is that people using elixir like the possibility to
> > mix multiples modules in one file . They find it convenient. At the end
> > multiples beam files will be created by the elixir compiler(builder?) .
> > Convenience is important when you have to code like we do today.
> >
> > I don't really understand all the complexity in that thread. Reading Joe
> > response i understand that the current implementation is not that
> flexible.
> > But how difficult it would be to trick the compiler to find module
> blocks?
> > (like in c++ with objects). Namespace collision can be detected at
> > compilation. case sensitivity is imo out of topic since anyway no real
> > solution exist.
> >
> > So coming back to my initial idea why having something like
> >
> > -module(b).
> > ..
> > -endmodule.
> >
> > couldd't be handeld by the compiler to recreate a module file and handle
> it
> > that way? I guess the main difficulty is for the debugging. The generated
> > module will need to be annotated to tell where to find the initial line
> of
> > code and there are probably some other details of implementation. Anyway
> > what do you think about it?
>
> I did this a few years ago (together with some other fun stuff)
>
> https://github.com/joearms/erl2
>
>
> Actually it's far easier to make a new language that compiles to Erlang
> than
> to change the existing Erlang - that's because we want backwards
> compatibility
> and tool compatibility.
>
> If you make any change like this (or omitting module declaration) you break
> all the tools and all the books.
>
> Eventually change becomes so difficult that adding any new features
> or bug fixes introduces as many problems as are solved - so a rewrite
> becomes necessary.
>
> Personally I hate reading books and articles on the net that say "do this"
> and when you do it, it does not work.
>
> Cheers
>
> /Joe
>
>
Oh I didn't know it was doing it, will reread...

Anyway I wasn't thinking to break the current API but expanding it. Not
sure if it can be done in a backward compatible way. Need to think more
about it.

But yeah I also like to not have to  look on the web what is the new way to
do the thing that was described in the book.  Also I am not very annoyed by
having to create different "files" for a purpose and keep related things at
the same place. It seems at then end the right way to think about a problem.

The real thing that annoys me today is having to prefix all my files in my
project where i just want to have a `btree.erl`file and call `btree:...`
just to make sure it won't conflict with another vendor when used in
another project. Where a "simple" namespacing based on the vendor directory
would work.

- benoît
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160225/0bfe54cc/attachment.htm>