Packages in Erlang: new documentation

[Erik Stenman]

Richard A. O'Keefe wrote: 	
> Clearly I must have misunderstood *someone*, because to make
> what I thought was proposed work, all you have to do is have 
> a local table of renamings in the module, and then have 
> apply/3 and spawn/3 and so on look in that table.

The problem is that a local renaming is not enough. With the 
proposed scheme there can be two modules originally named foo, 
but one has been renamed to bar. How should a third module in 
the system doing apply(M,f,[]), with M bound to 'foo' know 
whether the atom refers to the module foo or the module bar? The atom 'foo'
might have originated from the module renamed to bar and the intention might
have been the module name foo, but you can not automatically just rename all
occurrences of the atom 'foo' in the module to the atom 'bar'. The problem
is that there is no "module-type" in Erlang, apply and spawn refers to
modules by names.



[...]
> There are a number of things about that web page that bother me.
> 
> 
> The first is that while the noun "package" is used often,
> there doesn't seem to be any referent for it.  There are 
> module objects, and there are name objects (the "case X of 
> foo.bar.baz ->" example suggests that dotted names are just 
> symbols).  But there doesn't seem to be any *Erlang* object 
> for a "package" to refer to.  Packages appear to have no 
> properties and enter into no relationships; there are really 
> only package *names*.

More or less, just as there are only module *names* in Erlang today.


> In short, from the inside, there appears to be no significant
> difference between a module name like foo_bar_baz and a 
> module name like foo.bar.baz.

The only difference is that from within the package foo.bar you can 
refer to foo.bar.baz as just baz, but the module foo_bar_baz has to be
referred to with the hole name. You could also call packages module name
spaces if it makes you less confused.

> The second is that there is a fixed relationship between a
> module name and a set of places to look for it.  
[... description of lots of problems cut out ...]

Yes, but this is how modules work in Erlang today, it has not really
anything to do with the new packages. All the problems you describe
are already there in Erlang. The package extension is a suggestion
for a backward compatible extension which will give you some addition
advantages but it will not fix all problems that we have today. 

> Let me put this as bluntly as I possibly can:
>     While there may be a default mapping from Erlang module names
>     to files, it must be possible for someone installing a module
>     or package of modules to put each file exactly where s/he wants
>     without _any_ constraint on how files are named.

It would probably be quite easy to rewrite the Erlang loader
so that it looked in a user specified mapping from module names
to file names. That is, there is really nothing that says that
module names has to be mapped *directly* to filenames. But
this is really an issue that is completely orthogonal to the 
package extension.

/Erik
--------------------------------------
I'm Happi, you should be happy.
Praeterea censeo 0xCA scribere Erlang posse.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3420 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030904/449bfec5/attachment.bin>