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

[David Kastrup]

Andy Wingo <address@hidden> writes:

> On Tue 13 Dec 2011 10:02, David Kastrup <address@hidden> writes:
>
>> Lilypond's input language is not "David's current strategy".
>
> I was referring to your implementation strategy.

It's not a strategy.  Merely the least painful way to do things at a
given point of time.  The given point of time is that we need to cater
for both Guile v1 and v2.

> Mark describes another implementation strategy.
>
>> It does not help because it requires _advance_ knowledge of when you are
>> going to want to fish for environments.  You can call Lilypond's
>> #{ ... #} construct in the normal REPL.  You can call it in any function
>> definition.  It is pervasive.
>
> I was suggesting to evaluate all lilypond "scheme" code with the
> lilypond "scheme" interpreter.

Which means exactly that we can't use the repl anymore, and likely also
not the Guile debugger.  And get worse performance than with Guile v1.

> I still think making your #{}# parser expand to lexically-scoped
> Scheme is the best option.

If using Scheme as one humongous block is the best (and pretty much
only) option, Guile is no longer an extension language but a platform.
And that means letting down the admittedly few people who bought into
Guile's previous agenda.

In any case, I don't see what is supposed to make Guile v2 conceptually
distinct from any old Scheme interpreter if its closures are closed and
shut.

> Another option is to use the reflective facilities to implement a form
> of procedure-environment.  If you compile your Scheme procedures, with
> partial evaluation disabled, you should be able to use
> program-bindings to get this information.

program-bindings does not appear present in Guile 1.8, so that's shelved
at the current point of time.  And the documentation in the manual about
"Compiled Procedures" states

    Compiled procedures, also known as programs, respond all procedures
    that operate on procedures. In addition, there are a few more
    accessors for low-level details on programs.

which likely could be phrased a bit more clearly if one wanted to find
out how to make use of it.  It then goes on to state:

    — Scheme Procedure: program-bindings program
    — Scheme Procedure: make-binding name boxed? index start end
    — Scheme Procedure: binding:name binding
    — Scheme Procedure: binding:boxed? binding
    — Scheme Procedure: binding:index binding
    — Scheme Procedure: binding:start binding
    — Scheme Procedure: binding:end binding

        Bindings annotations for programs, along with their accessors.

        Bindings declare names and liveness extents for block-local
        variables. The best way to see what these are is to play around
        with them at a REPL. See VM Concepts, for more information.

Sorry, but "try out and see what it does" is not exactly a guarantee for
and/or a definition of a stable API.  I was not all that surprised to
find that the chapter "VM Concepts" does indeed contain more
information, unfortunately information that is not in any obvious way
related to program-bindings.

With that kind of documentation, few people will actually be using these
functions and as a result you will likely not feel any compulsion to
keep those around, either.

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

The distinguishing feature for Lisp-like systems is the degree to which
it is self-descriptive and "live".  _That_ (and certainly not its syntax
or performance) is what has made this language family the prime platform
for AI applications.

-- 
David Kastrup