[erlang-questions] Why we need a -module() attribute?
Bengt Kleberg
bengt.kleberg@REDACTED
Thu Feb 25 09:10:01 CET 2016
More really annoying name space problems:
1) Two binary packages/libs that I need both include the same module name.
2) Two binary packages/libs that I need must have different versions of
some third lib.
bengt
On 02/25/2016 09:02 AM, Benoit Chesneau wrote:
> 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).
>
> 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 ":" .
>
> One bonus point is that it would encourage peiple to create libs
> without to care that much if someone is already using that name...
>
> - benoît
>
>
> On Thu, 25 Feb 2016 at 08:24, Benoit Chesneau <bchesneau@REDACTED
> <mailto: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?
>
> - benoît
> On Thu, 25 Feb 2016 at 04:00, Richard A. O'Keefe
> <ok@REDACTED <mailto:ok@REDACTED>> wrote:
>
>
>
> On 25/02/16 1:53 pm, Loïc Hoguin wrote:
> >
> > A similar but larger pain point that's been rationalized by
> people
> > used to Erlang is the expression separators.
>
> I take it you're referring to commas, semicolons, and full stops.
>
> We have a complete solution to that called LFE.
>
> We also have Elixir, which has enough syntactic weirdness of
> its own
> that I decided not to use it.
>
> I briefly played with a Haskell-inspired syntax for Erlang,
> which I still
> think would be a good idea. One thing I certainly kept in
> that design
> was -module directives because of the good they do.
>
> I wouldn't say that I've *rationalised* the issue, just that I
> stopped
> falling off that particular bike very very quickly.
>
> I don't think there is any point in trying to "fix" Erlang
> syntax as it
> stands. I *do* think there is point in developing a whole *new*
> self-consistent
> syntax from the ground up, just like D didn't so much fix C's
> syntax as
> replace it.
>
> (By the way, am I the only person here who remembers that Algol 68
> used ";" for sequence and "," for parallel? Hands up everyone
> on the
> list who has an Algol 68 implementation on their machine.)
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160225/0770803c/attachment.htm>
More information about the erlang-questions
mailing list