Re: Anything better for delayed lexical evaluation than (lambda () ...)?

[David Kastrup]

Andy Wingo <address@hidden> writes:

> On Mon 12 Dec 2011 19:29, Mark H Weaver <address@hidden> writes:
>
>> You are using Guile in a very unusual way.  You have constructed a
>> hybrid language of both Scheme and Lilypond, where each can be nested
>> within the other (so far so good), but -- and here's the kicker -- you
>> apparently want to implement this hybrid language using two separate
>> interpreters maintained by two separate groups that are each able to run
>> code within lexical environments established by the other one.
>>
>> This is a fundamentally bad idea, because this structure makes it
>> impossible for either of these language implementations to evolve in any
>> significant way.  It forces them both to remain simple interpreters.
>
> FWIW Mark I agree with you.
>
> But, in the event that David wants to continue with his current
> strategy,

Uh, reality check.  Lilypond's input language is not "David's current
strategy".

> there are other things that can be done.  David, did you know that
> Guile's evaluator is implemented in Scheme?  That means that if you
> want an evaluator with different semantics -- for example, something
> closer to Kernel[0], as David appears to want -- then you can
> implement an evaluator that provides for fexprs and the like, and it
> will run about as well as Guile's evaluator.
>
> Did you see my implementation of `local-eval' [1]?  It leverages (hah!)
> Guile's macro expander, but otherwise is a straightforward
> interpreter.

It does not help because it requires _advance_ knowledge of when you are
going to want to fish for environments.  You can call Lilypond's
#{ ... #} construct in the normal REPL.  You can call it in any function
definition.  It is pervasive.

With Lilypond, I can always wrap stuff requiring closures into
(lambda ()) preventively at compile time, and execute them on an
as-needed base at runtime.  And that's actually what we do.  But there
is no way to ask Guile when it would be needed since Guile does not hand
out the information about bound variables in a given lexical scope.  To
get at that information, we would have to shadow every binding form
in Guile.

> If you find it slow, there are some simple, classic optimizations that
> can be made.  With some work, it could present a similar interface to
> 1.8's `local-eval', `procedure-environment', `the-environment', and
> such things.

When we are forced to reimplement a toy Scheme interpreter from scratch
anyway, including implementing every single defining form, one really
has to ask oneself why pick Guile in the first place if it does not give
you a Scheme language to work with?  Just for the API?

-- 
David Kastrup