Re: Re: First-class environments

On 4/5/06, Chung-chieh Shan <[email protected]> wrote:
> Joe Marshall <[email protected]> wrote in article <[email protected]> in gmane.comp.lang.lightweight:
> > First-class environments essentially make it impossible to reason
> > about variable values and locations.
>
> Surely people have tried to deal with this problem by applying static
> typing to environments, perhaps along the lines of record typing, which
> would be analogous of keeping track of the typing environment in a
> typical programming language?

I suppose, but I don't recall anyone writing about it.

It would be easy enough to statically reason about first-class
environments if you could explicitly determine what was to be
externally visible in the environment.  For instance, if you had an
environment where X and Y were lexically visible and you wanted them
to be available in the reified environment structure, you could
explicitly generate access and mutation thunks for the variables.  The
compiler would take care of whatever mechanism was needed to make that
work correctly.

The problem would be when you don't know at compile time what the
first-class environment will need to export.  For completeness, you'd
have to export all the bindings, and this would stymie the
optimizations.

Neither of the above scenarios deal with the issue of injecting new
(and possibly shadowing) bindings into an existing environment.

--
~jrm