Re: First-class environments

Good points.  Ideally, your language would allow you to define a function 
concept that uses restricted environments, so that you could gain the 
optimization advantages you mention.  It would also allow you to define a more 
general function concept that uses fully-featured first-class environments, 
but these would be significantly less useful in practice (I imagine).  Of 
course, having a compiler that knows the difference would be an interesting 
problem.  In practice, you'd probably have the restricted function concept 
built in and tell the user "this is semantically equivalent to defining a 
function like this...".

An interesting question is: what good uses could be made of functions that 
allow direct manipulation of their own environments?

Mike

Joe Marshall wrote:
> On 4/5/06, Michael Vanier <[email protected]> wrote:
>> For instance, are there
>> certain important language features or optimizations that first-class
>> environments make impossible?
> 
> First-class environments essentially make it impossible to reason
> about variable values and locations.  Consider this code:
> 
> (let ((x 5))
>     .....
>     (foo x)
>      .....)
> 
> Without first-class environments, we can know that X will be bound to
> 5 when we call FOO.  We simply check that there are no intervening
> assignments.
> 
> In this code:
> (let ((x 0))
>   (let ((y 1))
>     (lambda () (set! x (+ x y)) x)))
> 
> We don't know the value of X, but we do know that it is lexically two
> frames back and the first variable in the frame.  If we can modify the
> environment, we could introduce a new binding of X in the same frame
> as the binding of Y.  This would require that the code that refers to
> X perform a deep-search on lookup because the binding could be
> shadowed at any time by a closer binding.
> 
> Full-featured first-class environments are therefore a problem, but
> there may be a use for less featureful ones.  If you prohibit
> introduction of new bindings, then you can compile the variable
> lookup.  If you prohibit side-effects and allow the compiler to
> re-arrange the variables, then you can do most of the `normal'
> optimizations.  It is hard to write code that uses this feature though
> because different compilers may choose to lay out the environment
> differently.
> 
> --
> ~jrm