[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)
   (lambda (x)
     (env (list x form)))))

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

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]