Hi, I'd like to clarify one point here.
On Mon 23 Jan 2012 13:52, Andy Wingo <wi...@pobox.com> writes: > If we want to change the format of <lexical-environment>, we have two > more compelling options. One would be to make a compatible change, > but that's not always possible. An example of a compatible change would be adding a field to the record. The embedded make-struct calls from the expansion would result in a record with the new number of fields, but with #f for the new fields. This is actually a quite powerful capability. For example if we wanted to add a field to list the names of the bound identifiers, for the record printer, we could. If at some point we decided that was a bad idea, we change the record printer, and ignore those new fields. That's the other thing: we are free to change the runtime, within the local-eval module, to do what we like. You won't ever get an old runtime with a new expansion, so the problem is easier than it would otherwise be. The suggested approach of using an all-in-one wrapper procedure still has the runtime compatibility problem, but it's just as tricky (if not more) to manage, because you have to remember what free identifiers the expanded procedures could have referenced. > The second would be to define another <lexical-environment-2> or > something; new expansions of `the-environment' would embed references > to this new vtable. Record type predicates could distinguish them for > the purposes of local-eval/local-compile. The patches that I attached to this message use an abstraction to deal with the "env" that is passed to local-eval / local-compile being a module or a <lexical-environment>. In the unlikely case that a <lexical-environment-2> is needed, it would be trivial to extend this with a third case. But there are a number of compatible changes to go through before reaching this state. In summary, I think we have the compatibility needs covered here adequately. I don't look expect radical changes in this area, but even if they do make sense (quite possible), I don't see the drawbacks of this approach. Regards, Andy -- http://wingolog.org/
