Re: [PATCH] Implement local-eval, local-compile, and the-environment

[Andy Wingo]

Hi Mark,

On Sat 07 Jan 2012 21:20, Mark H Weaver <address@hidden> writes:

> The problem is that primitive-eval does not represent lexical variables
> as variable objects.

True.

> We could change that, but I'm reluctant to make the evaluator any
> slower than it already is.

Using variable objects has the possibility to make the evaluator faster,
actually, if at the same time we make closures capture only the set of
free variables that they need, instead of the whole environment.  That
way free variable lookup would be something like (vector-ref
free-variables k) instead of cdring down the whole environment chain.

> More importantly, is there any guarantee that mutable lexicals will
> continue to be represented as variable objects in future native code
> compilers?  Do we want to commit to supporting this uniform
> representation in all future compilers?

I don't know that we should commit to it externally, but internally it's
OK.  If we did have to commit to it externally even that would be OK, as
I don't think it will change.

> The nice thing about this strategy is that it places no constraints
> whatsoever on how lexical variables are represented.  It allows us to
> use primitive-eval to evaluate a local expression within a lexical
> environment created by compiled code, or vice versa.

This is a very nice property.  I just wanted to mention that this hack
is available to you, if you want.

>> What's the purpose of the (if #t e) ?
>
> That's to force expression context.  There's no proper way to add new
> definitions to an existing local environment anyway.  (the-environment)
> is treated like an expression, thus terminating definition context.
> Therefore, the form passed to `local-eval' should be constrained to be
> an expression.
>
> BTW, I think I want to change (if #t e) to: #f e.  That should require a
> less complicated analyzer to optimize away.
>
> Is there a better way to force expression context?

I guess it's not clear to me why you would want to force expression
context.  This expression would be an error either way:

  (let ()
    (local-eval '(define x 10) (the-environment)))

and this one:

  (let ()
    (local-eval '(begin (define x 10) x) (the-environment)))

is equivalent to

  (let ()
    (local-eval '(letrec* ((x 10)) x) (the-environment)))

so there is no ambiguity.

>>> +    (global-extend 'core 'the-environment
>>
>> This one is really nasty, and I'd like to avoid it if possible.  Are
>> there some short primitives that psyntax could export that would make it
>> possible to implement `the-environment' in a module?
>
> I don't see how it could be made much simpler.  At the very least, it
> needs to generate the following things:
>
> * The module name

How about using another procedure for this.  Racket calls it
"syntax-source-module", but we could probably call it "syntax-module" as
our phasing story isn't as complicated.

  
http://docs.racket-lang.org/reference/stxops.html#(def._((quote._~23~25kernel)._syntax-source-module))

> * The list of ordinary variables (these need to be boxed)
> * The list of simulated variables (we need to reuse the original box)

A special form to get all visible variables, and syntax-local-value plus
a weak hash to do the optimization?

> * The list of others, i.e. unsupported lexical bindings

In what case do you get unsupported lexical bindings?

There were a few points in your mail that I didn't comment on, because
they made sense to me.  What do you think about the psyntax comments,
though?

Andy
-- 
http://wingolog.org/