Parameterised modules

[Richard Carlsson]

On Thu, 4 Sep 2003, Chris Pressey wrote:

> Instead of parameterized modules, what about full-fledged lambda
> modules?
>
> Analogous to funs, I'll call them mods.  Also analogous to funs I'll use
> the following syntax:
>
>   Mod = mod
>     function1(A1, A2) -> something.
>     function2(A1, A2) -> something_else.
>   end,
>
> This way you can 'parameterize' a module like so:
>
>   String = "Hello, world!",
>   Mod = mod
>     print() -> io:fwrite("~s", [String]).
>   end,
>   Mod:print().

I have considered this, but the implementation issues are
very hairy indeed, when you have to think about things like
code updates (if the result _is_ a module, then calling
it should not have different semantics from calling any
other module - right?), and distributed Erlang.

Java introduced such a thing in 1.1 - they call it "anonymous
classes", in analogy with "anonymous functions" (lambdas). They
are often used for writing small, one-shot callback objects
such as listeners. They implement them by letting the compiler
autogenerate names like "Foo$3" (for the third anonymous class
in class "Foo"), so you get extra object files "Foo$3.class", etc.

But you don't do a lot of dynamic code update in Java, and it
seems that they are not worried about the fact that if two "nodes"
are running the same code initially, but one gets a bug fix that
causes the numbering of these "anonymous" classes to change,
the whole thing could go down.

I've been thinking a lot about the problems with "anonymous things",
code update and distribution, but I don't have any good answers yet.
That's mainly why I did not mention the possibility of "anonymous
modules" in my workshop presentation.

	/Richard


Richard Carlsson (richardc@REDACTED)   (This space intentionally left blank.)
E-mail: Richard.Carlsson@REDACTED	WWW: http://user.it.uu.se/~richardc/
 "Having users is like optimization: the wise course is to delay it."
   -- Paul Graham