This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Change to variable interface request


Jim Blandy wrote:
> 
> What's really going on here is that you want to evaluate an expression
> in an environment defined by an alist, right?


That's correct.  When I was implementing an object system based on modules
I noticed that the obarray within the module was storing variables so that
eval2 could be used to execute within the module.  However, a variable
was essentially two pairs, one of which, as far as I could tell did nothing.
So to implement GOOS I have used just a pair to store a binding, saving space.  
But to get eval2 to evaluate within an object I have to pass variables to eval
via a lookup closure proc, this is were variable-bind-pair comes in.  A variable is
temporarily created so that eval2 can function.  And it works!

It is not so much to get evals to work on alists but for any arbitrary
storage that uses pairs.  Even an obarray using pairs instead of variables
could be evaluated within, saving a great deal of space.

It is not essential to have an eval for an object system.  But I like
syntax of GOOS's make-class very much.  You can write arbitrary programs
within the make-class definition, not just define slots.  I think
this approach points out something very deep about the relationship of
scheme and object systems.

Another alternative would be to create another eval, say eval3 that expects
pairs, instead of variables, however a new *toplevel-lookup-closure* would
have to be created that would return pairs instead of variables, since I
delegate any bindings I cannot resolve to the top level environment.

Wheww!  Did you get all that?

Wade