[erlang-questions] Why we need a -module() attribute?

[Loïc Hoguin]

On 02/19/2016 01:00 PM, zxq9 wrote:
> On 2016年2月19日 金曜日 12:32:11 Loïc Hoguin wrote:
>> I've mentioned that at the beginning of the thread. We're going circles
>> now. :-)
>>
>> I really don't think getting rid of the mandatory -module attribute is
>> such a hard problem to solve...
>
> This whole conversation is sort of weird to me.
>
> Why is having this attribute a problem?

You never had the error that the module name doesn't match the file name?

> Also, this is rather clearly moving in the wrong direction. I imagine
> (hope?) that someday filesystems as we know them will be considered archaic
> vestiges of the past and a very different concept of {Aliases, Meta, Data}
> will evolve. Yet right now, after a few decades of going to ALLLL the
> horrible, torturous trouble of writing "-module(foo)." at the top of files,
> we are suddenly experiencing a collective urge to tie module names to
> filesystem names -- which aren't anywhere close to being uniform across
> systems.

Considering the current compiler code checks that you are a good little 
kid and wrote the same module name as the file name, I don't think that 
an hypothetical file system was in OTP team's mind when they made the 
-module mandatory.

And frankly, if I were to base all my decisions based on hypothetical 
changes 50 years from now I wouldn't write any code. I can't predict the 
future. Can you?

> It seems more like we should be arguing for, say, formalization of version
> semantics (hint: semver or something like it), the runtime to maintain a
> mapping of code resource locations to {ModName, Version}, let the runtime
> know more about what the versions *mean*, treat canonical (but signed and
> distributed) source locations as abstract resources, etc. If we don't care
> about the Mod/Sourcefile mapping any longer then multiple modules becomes
> a non-issue and certain things would be pretty nature to write into a
> single file.
>
> Oh. And namespacing (of some form).
>
> Unless we decide to go down the com.example.my.backwards.modules direction
> Java pushed itself or the "filesystems/are/actually/object/hierarchies" of
> Python (which wound up necessitating that things like virtenv become core
> features) I just don't see this as a meaningful way to deal with the
> file/code mapping. And why do we have that mapping anyway?
>
> -module(same_as_filename).
>
> Is that silly? YES OF COURSE IT IS SILLY. But its a bandaid. And it won't
> break later when filename == modname is no longer true. Keeping it is a tiny
> annoyance, one we are already well conditioned to. I think keeping it is a lot
> better than choosing to make it optional and guaranteeing that a lot of code
> will have to someday be changed once 1 file /= 1 mod. Those other things I
> mentioned seem both more important and dramatically more interesting.
>
> I'm not arguing that the current situation is optimal or something better
> shouldn't eventually be put in place. I'm just saying that this is both the
> least important aspect of that and the one part of the module system we will
> actually need to keep, not toss.
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>

-- 
Loïc Hoguin
http://ninenines.eu
Author of The Erlanger Playbook,
A book about software development using Erlang