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

[zxq9]

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?

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.

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