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

[David Kastrup <dak@gnu.org>]

Andy Wingo <wingo@pobox.com> writes:

> Hello David,
>
> Let us focus on solutions.
>
> If the this realm does have a coin, it is good-will.  All participants
> start with ample deposits, but yours is draining fast.  Please listen to
> what people are saying; they are trying to help you.

Lilypond already has an ugly inefficient hack in it that will keep it
working in regard of the closure department largely independent of
whatever Guile development chooses to come up with next.

> On Tue 13 Dec 2011 14:56, David Kastrup <dak@gnu.org> writes:
>
>>> I wonder if we could provide some sort of current-bindings syntactic
>>> form, also.  It would require psyntax hooks, but it could work.
>>
>> I can't help the impression that a dependable and documented
>> long-term strategy and corresponding commitment would at the current
>> point of time be more important than brain-storming about short-lived
>> hacks.
>
> Um... what?  It sounds like `current-bindings' is the thing you need.

It will at least be a year before any solution that does not work with
Guile 1.8 will be accepted into Lilypond.  Any effort spent on something
that is not likely to survive that long because nobody will have ever
used it by the time Lilypond would bother picking it up, is going to be
wasted.  And additional cause for bad blood.

And since we are not talking about time-critical code paths in Lilypond,
we'll be able to kludge around the consequences of Guile sacrificing its
introspective qualities.

I am not worried about Lilypond.  I can work with any size of crowbar.
I am worried about Guile.

> But, um...  I guess what I want to say is that you are making it
> pretty hard to work with you.

Since we are working on different projects, that is not a problem.

Take a look at <URL:http://www.gnu.org/s/guile/>.  It states:

    Successful and long-lived examples of Free Software projects that
    use Guile are TeXmacs, LilyPond, and GnuCash.

If you take a look at
<URL:http://www.texmacs.org/tmweb/about/todo.en.html>, you'll find

    3.Scheme interface
    3.1.General

    Scheme plug-in

        Internally present Guile as a plug-in, which could later be
        replaced by another Scheme implementation.

in their list of things to do.

For GNUCash, you have
<URL:http://wiki.gnucash.org/wiki/Roadmap#Scheme_minimization>

    Scheme minimization

    There are some parts of GnuCash that make a round-trip into scheme
    code for no really good reason. The developers would like to throw
    out those parts of Scheme.

    Reports

    Right now reports are scheme scripts that programatically generate HTML.

    Scheme is impenetrable to most programmers. Expecting users to be
    able to write reports in Scheme is completely unreasonable.

    The ideal solution should have three modules:

        Record selection: Ideally graphical with an SQL-like "advanced" option
        Layout: The original item here suggested an HTML template; that
        could be the "advanced" option, with a simple table/graph being
        the default
        Style: CSS. It's built into WebKit, we should use it.
        Javascript: WebKit supports javascript so complicated
        interactivity can be added. Example: ability to expand/collapse
        levels of the account hierarchy in a report. This could be
        extended with Javascript interfaces to the API so that all of
        the report code is written in Javascript instead of Scheme. 

    Any report module will still need some sort of scripting language to
    "calculate the numbers". Currently we have Scheme for this, but the
    developers would like to get away from that. Python might be a
    better option.

So of your three listed showcase applications, the two others are trying
to get away from Guile and/or Scheme.  And it does not look like
performance is the reason.

So I don't think that throwing out _distinguishing_ selling points of
Guile is necessarily doing you a favor.  And the transparency with which
it integrates with its language environment and the fact that one can
continue to use its evaluator and debugger even for the application for
which it serves as an extension language, certainly is a selling point.
Even if documentation and commitment to interfaces are not doing their
share.

There is a reason that pure Scheme compilers like Chicken and Stalin
don't see widespread employment, and that reason is that the
introspective and interactive character of the Lisp-like languages is
lost to a good degree, and the performance gain does not in itself
suffice to compete with classical compiled languages and their usually
more human-readable code and concepts.

-- 
David Kastrup