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

[David Kastrup <dak@gnu.org>]

Andy Wingo <wingo@pobox.com> writes:

> It took some time for everyone to understand the problem.  In the end,
> there were four workable possibilities.
>
>   1) Keep using closures.
>
>   2) Incorporate local-eval and the-environment into Guile 2.0.
>
>   3) Have lilypond use its own evaluator or compiler.
>
>   4) Have lilypond make the embedded lilypond code expand out to actual
>      Scheme.  (It was unclear whether the lilypond grammar allowed
>      this.)

It is pretty clear that the Lilypond grammar will not allow this.  It
has ambiguities that can only be resolved at runtime and impact both the
parse tree as well as the tokenizing process.

> Mark and Noah looked at implementing local-eval, and I recommended
> staying with the closure solution.  Ludovic noted success with method
> (3) in the Skribilo context.

Mark basically showed a sketch that worked by switching off the compiler
of the current top form when the-environment got used.

With LilyPond, my basic statement was that performance of the Scheme
part was a non-issue when compared against the Lilypond parts.  As an
afterthought, this may not be totally correct: if you have code of the
kind

(define-music-function ... (x y z)
  (do a complex calculation purely in Scheme)
  (return results using #{ ... #}))

then the speed of the "calculation" can conceivably govern the runtime
after all, so switching off all compilations in the enclosing top form
might have runtime effects not masked by the costs of #{ ... #}.  It is,
however, untypical to have costly calculations in the front end of
Lilypond.  The runtime is usually spent elsewhere, mostly in C++ code.

> I would like to start a new thread around local-eval, but besides
> that, we should probably agree on the summary first.  So please do
> send any corrections to this summary to the list.  Thanks :)

A note to point 4) if LilyPond were a language for which expansion to
Scheme would be feasible, compilation of the whole nested constructs
would have to happen in one humongous piece since there is no other way
to share lexical environments.

And a note to point 1) the Scheme compiler is more likely to complain
about (lambda () arbitrary-garbage-sexp) than the interpreter when the
preliminary closure-building step picks up line noise from inside of
Lilypond comments or strings.

In comparison to the previous code version running under Guile 1.8,
robustness, cleanliness and manageability of the code have taken a step
backwards.  It's not a mile, but not trivial either.

-- 
David Kastrup