Re: summary: lilypond, lambda, and local-eval

[David Kastrup <dak@gnu.org>]

Hans Aberg <haberg-1@telia.com> writes:

> On 15 Dec 2011, at 11:21, Andy Wingo wrote:
>
>> The "delayed evaluation" thread is a bit long and confusing, so I would
>> like to try to summarize it.
>> 
>> Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
>> Lilypond code.  The former uses a reader macro, #{#}.  The latter uses
>> specially-marked variables and expressions, specifically, those preceded
>> by $ or #.
> ...
>> It took some time for everyone to understand the problem.  In the end,
>> there were four workable possibilities.
>> 
>>  1) Keep using closures.
>
> When doing a parser on top of Guile, I noticed one must first build an
> unevaluated closure, and only thereafter call the evaluator. Scheme
> has some restrictions forcing this, for example, the lambda cannot
> appear as a free symbol, though it is possible in Guile using
> scm_sym_lambda.
>
> It might be useful with a variation of scm_eval_string() that only
> parses and builds the closure, but not calls the evaluator.

I am not sure what you mean with "closure" here, but just "read" parses
a form.

I was actually surprised playing around with the dirty call/cc hack I
posted about just how many uses of my-eval and my-env appear to do what
you would expect to in Guilev1:

(define (my-eval form env)
  (call-with-current-continuation
   (lambda (x)
     (env (list x form)))))

(define-macro (my-env)
  (call-with-current-continuation identity))

(define (xxx)
  (let* ((x 2))
    (set! x (+ x 3))
    (my-env)))

(format #t "~a\n"
	(my-eval
	 '(begin (set! x (+ x 5))
		 x)
	 (xxx)))

So far, just fooling around in the expectation that things will break
has not succeeded.  One probably should do a more analytic attempt of
breakage.  I have little doubt that using a compiler would make it much
less likely to get working results, but haven't tried.

Of course, exporting a half-finished evaluator is much less likely to
work reliably and with tolerable amount of stored information than a
properly exported environment would.

-- 
David Kastrup