Hans Aberg <haber...@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
