also about namespacing that's indeed quite annoying when you have to rename your filed just because you adding a dependancy to a vendor that contain a module with the same name... Or if you want to use your patched module over the erlang core (eg ssl).<br><br>We already have way to point to includes files using relative paths. would be cool to extend it to the import instruction and use paths like in go. Then using the dot internally to distinct from the ":" .<br><br>One bonus point is that it would encourage peiple to create libs without to care that much if someone is already using that name...<br><br>- benoît<br><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 25 Feb 2016 at 08:24, Benoit Chesneau <<a href="mailto:bchesneau@gmail.com">bchesneau@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <br><br>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.<br><br>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. <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 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?<br><br>- benoît<br><div class="gmail_quote"><div dir="ltr">On Thu, 25 Feb 2016 at 04:00, Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 25/02/16 1:53 pm, Loïc Hoguin wrote:<br>
><br>
> A similar but larger pain point that's been rationalized by people<br>
> used to Erlang is the expression separators.<br>
<br>
I take it you're referring to commas, semicolons, and full stops.<br>
<br>
We have a complete solution to that called LFE.<br>
<br>
We also have Elixir, which has enough syntactic weirdness of its own<br>
that I decided not to use it.<br>
<br>
I briefly played with a Haskell-inspired syntax for Erlang, which I still<br>
think would be a good idea.  One thing I certainly kept in that design<br>
was -module directives because of the good they do.<br>
<br>
I wouldn't say that I've *rationalised* the issue, just that I stopped<br>
falling off that particular bike very very quickly.<br>
<br>
I don't think there is any point in trying to "fix" Erlang syntax as it<br>
stands.  I *do* think there is point in developing a whole *new*<br>
self-consistent<br>
syntax from the ground up, just like D didn't so much fix C's syntax as<br>
replace it.<br>
<br>
(By the way, am I the only person here who remembers that Algol 68<br>
used ";" for sequence and "," for parallel?  Hands up everyone on the<br>
list who has an Algol 68 implementation on their machine.)<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></blockquote></div>