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