Re: syntax-locally-bound-identifiers, local-eval

[Andy Wingo]

Hi,

I'd like to clarify one point here.

On Mon 23 Jan 2012 13:52, Andy Wingo <address@hidden> 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/