[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: summary: lilypond, lambda, and local-eval
From: |
David Kastrup |
Subject: |
Re: summary: lilypond, lambda, and local-eval |
Date: |
Thu, 15 Dec 2011 18:24:16 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Hans Aberg <address@hidden> 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
- summary: lilypond, lambda, and local-eval, Andy Wingo, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval, Hans Aberg, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval,
David Kastrup <=
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Andy Wingo, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Noah Lavine, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Noah Lavine, 2011/12/18