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

[Andy Wingo <wingo@pobox.com>]

On Wed 14 Dec 2011 16:21, David Kastrup <dak@gnu.org> writes:

> 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?

I'm not sure if this is a rhetorical question or not :), but:

  1) Guile has a C library, with C interfaces to its functionality..

  2) Guile is a GNU project.

  3) You're already using Guile features (modules, among them).

But TBH I don't understand this argument.  Lambda is fantastic, and even
if Guile provided other facilities, I would still use it.  It is the
right tool for the job, IMO.

>>   * 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.

This is a great thing.  We share the knowledge and in some times the
implementations from other Schemes.  And there are quite a number of
fine Scheme implementations; if you had to switch, for whatever reason,
you could.

>>   * 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.

I am saying this as the person who wrote the current debugger.

>  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.

Very few languages have proper macros.  Very few Scheme implementations
have macro debuggers.  Racket is the only one I know.  It has a separate
debugger for use at syntax expansion time.

I am saying this as the person who maintains the current macro
expander.

:)

>>   * Potentially more efficient, and will benefit from future speed
>>     improvements in Guile.
>
> 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))))))))

It's not what you see, it's what you don't see :)

In Guile 1.8, you don't see:

 * (Lazy) memoization.  (A 1.8 implementation technique.)
 * Consing up procedure arguments.
 * Consing up lexicals.
 * Looking up lexicals.
 * The evaluator dispatch loop.
 * Out-of-line calls to primitives.

Etc.

You are right in saying that it will be slower on 1.8.  Oh well.  On 2.0
it will probably be faster, and potentially could be much faster -- if
it matters.

I am sympathetic to your argument.  Using closures is more code on your
part than using first-class environments.  If Guile only provided an
interpreter, that would certainly be the way to go.  But using closures
is not without its advantages as well, as I listed, and it works also
with a compiler.

Regards,

Andy
-- 
http://wingolog.org/