Packages in Erlang: new documentation

Richard A. O'Keefe ok@REDACTED
Fri Sep 5 01:59:37 CEST 2003


"Vlad Dumitrescu" <vlad_dumitrescu@REDACTED> wrote:
	For the first, that would mean that every remote call will have
	to check first the internal module table for a rename.  That
	would make these calls much slower.

This is a bare assertion without any evidence to support it.
With appropriate use of hash tables and caches, it could be _faster_.

	Again, if a module name is sent as a function argument, the
	local name wouldn't make sense to any other module.

That is certainly a serious problem with the current proposal.

One solution would be to extend the ?MODULE idea.
?MODULE	==> the full name of the current module
+
?MODULE(local_name) ==> the full name of the module locally known as
local_name.

So instead of sending {foo,bar} to another module you'd send
{?MODULE(foo),bar}.

	Sure, we could have a function to retrieve the complete name,
	but personally I feel it's more error-prone than elegant.
	
Is there _any_ way of allowing abbreviations that is _not_ going to be
error-prone?

	Finally, what about functional objects? The environment for a closure would need
	to include the rename table from the defining module.
	
Not the _environment_.  The parent module is simply part of the literal
data for the code.

	>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.
	
	Only that locally you can use baz:fun(...) instead of the full
	module name.

And THAT is the thing that creates all these difficulties.

If baz:f(...) and (X = baz, X:f(...)) don't do the same thing,
the language has serious semantic problems.
If they _are_ to do the same thing, then either you don't have
abbreviations, or you _have_ to look up module names in a per-module
table somehow.

	And also that maybe one wants/needs to rename the 'foo'
	application, and then not all module names have to be updated.

Please explain this more clearly with an example.

The more I think about this, the clearer it seems that ANY kind of
dotted module name scheme is a bad idea, and that something like
the Eiffel approach is likely to be less trouble (more power, less
complexity, less potential for error).




More information about the erlang-questions mailing list