Packages in Erlang: new documentation
Fri Sep 5 09:53:08 CEST 2003
Richard A. O'Keefe wrote:
> I pointed out that apply/3 and spawn/3 and suchlike could be made
> to work in the presence of module renaming.
> This is a good time to point out that the longer I ponder this,
> and I have been thinking about Erlang modules for about 7 years now,
> the clearer it seems to me that
> (1) Module names must be completely decoupled from file names.
> [This does not mean that you cannot have a _default_ mapping
> from module names to file names, only that you cannot have a
> _fixed_ mapping.]
I agree that the names should be decoupled to allow people to organize
the files on their disk.
I disagree in that the flexibility should not be limitless. In
particular, my ideal would be that a human would need no more than a
single lookup to determine where to find any set of modules.
(Think situations like: a consultant is trying to make sense of the file
organisation of a customer.)
> It is possible to have a system of hierarchical modules. That's
> how Pop-2 does it, and that's how Ada does it, and that's how Mercury
> does it. In those languages, modules may contain types, functions,
> _and other modules_.
Minor point: I'm not sure that nested modules gain much.
> (3) Having packages that do not package is unhelpful.
> Java is notorious for this: packages are accessibility scopes,
> but anybody can sneak new classes and subpackages into a package
> without the package having any say about it.
> This is really a fundamental problem with Java packages, and the
> scheme under consideration is far too Java-like for my taste.
> If there are to be packages, then a package should be able to list
> its children and insist that no other purported children are legitimate.
This is a problem because classes in the same package have additional
If "being in the same package" doesn't give a module any additional
privileges, there's no point in doing so and the problem disappears. (I
haven't looked too deeply into the Erlang package proposal, so I'm not
sure how the situation here is. I'm just pointing out that there are
more design alternatives than have been made out.)
When weighing the alternatives, I see that closing the packages means
that programmers have to write manifestos. That's redundant information,
with all the associated problems.
> (4) A satisfactory solution to the "package" problem must deal with the
> issues of
> - including a module at more than one place in the space of packages
I'm not sure how this becomes relevant?
> - including more than one version of a module in a complete system
This is most definitely relevant.
The Unix solution (simply include version numbers in the module names)
seems to work best.
> If you consider these issues, you discover that the one thing that
> a module must NOT do is to know its exact place in a hierarchy of
Again, I think the design space is larger than presented.
> (7) JAM was not the last word in Erlang implementations.
> BEAM will not be the last word in Erlang implementations.
> "BEAM does so-and-so in such-and-such a manner" may decide what
> designs are easy to experiment with atop BEAM, but must not be
> allowed to dictate which designs are considered at all.
Agreed - modulo the constraint that the time of the Erlang team is limited.
In other words: design alternatives should be discussed even if they go
beyond current BEAM mechanisms, but BEAM compatibility should definitely
be a factor when deciding which mechanism to implement.
More information about the erlang-questions