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

[Richard A. O'Keefe]

On 24/02/16 8:27 pm, Bengt Kleberg wrote:

> Greetings,
>
> Would it be possible to get a more elaborate explanation of what OASES 
> would do?
Map module names, grammar names, include names, &c to data sources,
so that Erlang programmers would mostly deal with portable Erlang-internal
names.
> Given the {module, my_app_part_subpart, "src/myapp/part/subpart.erl"} 
> example below, would src/myapp/part/subpart.erl be available as the 
> module my_app_part_subpart after being loaded in the VM?
Yes.

> How would src/myapp/part/helper.erl refer to it: my_app_part_subpart 
> or subpart or ???

By the name that you provided in the -module directive.
This is not a "hierarchical module names" proposal;
the OASES idea is just "referring to resources in a portable way".
> How would src/myapp/other/subpart.erl refer to it: my_app_part_subpart 
> or part_subpart or ???

By the name that you provided in the -module directive.
> I do not understand the "zip" thing enough to ask about it.

This goes back to IBM mainframes, to Unix Makefiles, and to .ez files.

In the MVS world, you might keep the Fortran code for your project
in a "partitioned data set" (think Unix .a file) called FORTRAN, so
you would refer to FORTRAN(DGEMM) -- the "DGEMM" member
of the "FORTRAN" partitioned data set rather than a Unixy
dgemm.f.  Unix makefiles let you refer to files in a .a file using
foobar.a(membername) and would automatically extract things.

The idea is that you might want to package up a bunch of stuff in a
ZIP file (or some other kind of archive), to save space, or to make
it easier to move stuff around, or whatever.  Why should you have
to extract a file from an archive in order to read it?  Why should
the compiler not be able to read *directly* from the archive?