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] |
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