<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
More really annoying name space problems:<br>
1) Two binary packages/libs that I need both include the same module
name.<br>
2) Two binary packages/libs that I need must have different versions
of some third lib. <br>
<br>
<br>
bengt<br>
<br>
<div class="moz-cite-prefix">On 02/25/2016 09:02 AM, Benoit Chesneau
wrote:<br>
</div>
<blockquote
cite="mid:CAJNb-9rzww7zAF=BVVk+O6U9D6ekvD_xXq_C0ofjeehTC_CZnQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org"
target="_blank">erlang-questions@erlang.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</body>
</html>