Re: Anything better for delayed lexical evaluation than (lambda () ...)?

[David Kastrup <dak@gnu.org>]

Andy Wingo <wingo@pobox.com> writes:

> It is my opinion -- and I could be wrong here, either by
> misunderstanding (again!) the issues, or for whatever reason -- that
> closures are the best solution to the #{#} problem.
>
> Reasons:
>
>   * Lambda is standard, well-understood, and general.

Well, if they are standard, what benefits does using GUILE give us?

>   * Using `lambda' does not preclude compilation.
>
>   * Using closures does not require any additional work on the part of
>     Guile.  (This is only partly selfish; it also decreases the amount
>     of coupling of lilypond to any particular Guile version.)

Any particular Scheme version.

>   * Allows for integration with the debugger, in 2.0.  (Currently,
>     interpreted code does not debug well.)

Sounds like putting the cart before the horse.  After all,
interpretative environments offer a lot of potential to be _better_ for
debugging than compiled code.  One should not lightly waste this.  In
particular since macro expansion is basically an interpretative
operation and macros are among the nastiest things to debug.

>   * Potentially more efficient, and will benefit from future speed
>     improvements in Guile.
>
> WDYT?

Well, take a look at the following:

dak@lola:/usr/local/tmp/lilypond$ out/bin/lilypond scheme-sandbox
GNU LilyPond 2.15.22
Processing `/usr/local/tmp/lilypond/out/share/lilypond/current/ly/scheme-sandbox.ly'
Parsing...
guile> '#{ ##{ \displayLilyMusic $p #} #}
(#<procedure embedded-lilypond (parser lily-string filename line closures)> parser " ##{ \\displayLilyMusic $p #} " #f 0 (list (cons 2 (lambda () (#<procedure embedded-lilypond (parser lily-string filename line closures)> parser " \\displayLilyMusic $p " #f 0 (list (cons 20 (lambda () p))))))))
guile> 

This case of mutual nesting is not all that outlandish, and the nested
lambdas, while managing to carry the value of p from the current lexical
environment to the inner layer, are not all that pretty.  This could be
just

(#<procedure embedded-lilypond (parser lily-string filename line closures)> parser " ##{ \\displayLilyMusic $p #} " #f 0 (get-environment))

instead.  In short, that I have managed to pick out the nicest prybar
does not mean that a lockpick would not be preferable.  And even if (or
rather: particularly when) we were working like the GUILE gods have
intended it, we would be forced to transform every case of nested
expressions into one large humongous block compiled at once in order to
get lexical nesting (possibly by working with macros which don't exactly
make things easier to track), and that would be quite counterproductive
to getting useful error messages whenever something in the course of
this nesting would go wrong.

So even though we can workaround the current situation well enough for
now, I think that GUILE might be selling itself under value when
compared to its competitors, possibly without compelling need when I
look at the sketches of Mark and the discussion of them.

-- 
David Kastrup