[erlang-questions] Reified environments (was: Re: Package Support/Use)

Thomas Lindgren <>
Tue Nov 7 17:15:32 CET 2006

--- "Richard A. O'Keefe" <> wrote:

> I've been asked what I meant when I talked about
> reifying module
> environments and having more than one of them.  You
> can think of
> this message as a *draft* description.

Interesting proposal, though I haven't absorbed it
fully. Generically, I think there are a few basic
issues to be considered:

1. How are names resolved within a module (scoping)

2. How are names visible outside a module (hiding)

3. When are names resolved? (e.g., at runtime, compile
time, "package assembly time", ...)

4. Also, given that we have a language with code
change, we have to handle "relinking" on code change.
I can see several options for how that should be done.

What I like about your proposal:
- it seems decently similar to ordinary linking and
library building
- it avoids conflating names, name spaces, object
code, loaded code, files, ...
- reification is a good principle (at unguarded
moments, I might claim it's more important/useful than
static typing)

The drawback is that it seems more complex than the
current model. Not a big problem for me, but I think
the common case should be straightforward and
unsurprising to use. (Your proposal may be perfectly
so, but I haven't really thought it through.)

Also, I'm not sure how it relates to the constructs of
other languages; most seem to be oriented towards
statically building components and assembling them
into an executable. Erlang would need a bit more
dynamism as per point #4. We could also discuss the
finer details of code change, such as how closures or
records really should be handled.

At this point, it strikes me that I'd actually like to
see some requirements. The take-home point might be:
"So, what functionality do we expect our reified
environment or packaging system to provide?"


Want to start your own business?
Learn how on Yahoo! Small Business.

More information about the erlang-questions mailing list