[erlang-questions] Why we need a -module() attribute?
Jesper Louis Andersen
jesper.louis.andersen@REDACTED
Wed Feb 17 15:45:29 CET 2016
I usually say that any kind of assumption binding the file system to the
module system of the programming language is a mistake.
* You can't use another transport such as a socket for moving data around.
* You are bound by file system lookups for loading modules.
* You can't do nested modules well and have to rely on odd file system
directory structures
* The programmer can't name things logically and are forced to obey the
system
* You can't split the same module into multiple files
* You can't have multiple modules in one file
One language which doesn't make this mistake is Standard ML. You have
another layer in some SML systems, the .mlb file, which then groups files
into a collection of modules, including export/import renaming, stdlib
selection, extension selection and so on.
Were I to create a language, this would be my solution as well.
On Wed, Feb 17, 2016 at 10:45 AM, Konstantin Vsochanov <kost@REDACTED> wrote:
> Hi!
>
> I’m working with Erlang for two years now and enjoy every day of using
> it. However, there are some strange features I’m wondering about. One
> of them -module() attribute.
>
> The module name is strictly defined by the name of the .erl file. You
> can’t change module name with -module() attribute. But the the -module()
> attribute is mandatory. Why? Why we need -module() attribute at all?
> Maybe we can make -module() optional in next Erlang release? So we don’t
> need to repeat file name in first string of every .erl file. Or maybe I
> miss something important?
>
> Feedback is appreciated!
>
> - Konstantin Voschanov
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
--
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160217/a129fbb8/attachment.htm>
More information about the erlang-questions
mailing list