[erlang-questions] Why we need a -module() attribute?
Thu Feb 25 11:35:39 CET 2016
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>
> > 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
> > But how difficult it would be to trick the compiler to find module
> > (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
> > 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
> > 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)
> Actually it's far easier to make a new language that compiles to Erlang
> to change the existing Erlang - that's because we want backwards
> 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.
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions