Re: [PATCH] add SRFI: srfi-121; generators

["Marc Nieper-Wißkirchen" <marc.nieper@gmail.com>]

Am Di., 4. Aug. 2020 um 17:24 Uhr schrieb John Cowan <cowan@ccil.org>:

>>  At the moment,
>> there is no general programmatic way to know whether a specific
>> implementation is up-to-date with respect to these post-finalization
>> notes or not.
>
>
> How could there be?  The implementations are written in a Turing-complete language.

If we had R6RS's library versions, we could just bump the version
number each time the API is changed due to a PFN. (Note that I am not
saying that R6RS's version numbers are the best tool; my point is more
that there are tools.)

>> A similar problem occurs with libraries that have already been voted
>> into R7RS-large. In the Red Edition, (scheme generator) stood for the
>> interface of SRFI 121; in the Tangerine Edition, it stands for SRFI
>> 158.

>
>
> I only did that because 158 is upward compatible with 121; indeed, bug-for-bug compatible, as it turned out.

SRFI 158 is not upward compatible in the full sense with SRFI 121
because it exports more identifiers. Of course, chances that some code
will break are low.

Likewise, SRFI 166, which will most likely replace SRFI 159, is not
fully upward compatible.

That said, these incompatible changes during the draft period of
R7RS-large are the lesser of two evils. As I said, if one needs a more
stable interface, just import (srfi 121) or (srfi 159) instead of
(scheme generator) or (scheme show).

>> While I have been contributing to R7RS-large, I have to agree with you
>> to some extent. Most of the SRFIs that have been voted into R7RS-large
>> or are to be submitted for it don't have the quality of the R6RS or
>> R7RS(-small) specifications

> Inevitably so.  A large granite boulder cannot be cut like a diamond, but it has uses that a diamond does not (and vice versa, of course).

There's already a large granite boulder called Python. When we want to
advertise R7RS-large, which differences shall we point out (apart from
the Lisp syntax)?

>> - Questions of tail context are often ignored.
>> - Higher-order procedures are often silent with respect to call/cc,
>> exceptions or side effects.
>
>
> Regrettably both true.  Scheme is so often used without effects that it's easy to forget they exist.

>> - Formal syntax is often missing.

> What further syntax do you want?  Procedures have only a single syntax, so all we need to know is what arguments exist and in what order.  Macros are few, but informal explanations (as in R[57]RS) seem sufficient to me.

For procedures, we don't need any formal syntax, of course. If it's
needed, it is for macros. If you take a look at many earlier SRFIs,
grammar production rules extending those of R5RS are given, which help
to understand the syntax.

On the other hand if you take a look at many other SRFIs, let's take
SRFI 204 for example, it's hard to know how to implement them just
from reading the spec and not the implementation.

>> - Formal semantics are almost always missing.

> That requires someone who can write their own Greek, which would not be me.

You don't need to write arcane formulas. Take SRFI 2, for example. The
semantics are pretty well laid out.

>> SRFI 121/158 is incidentally also an example for this. Take 'gappend'
>> from SRFI 158, for example. It doesn't specify when the various
>> generator arguments are being called.

> I don't follow you.  It is quite explicit that each is called until it is exhausted in left to right order.

For example, the current spec allows that "gappend" already calls the
various generators supplied as arguments (and stores their results)
before returning the resulting generator. It is specified, in which
order the values are delivered, but it isn't specified when the
supplied generators are asked for their values. There may be an
obvious order of procedure calls, but it is not in the spec.

Thus, if any of the supplied generators has side effects, we will have
an implementation-dependent result. Moreover, we don't know what
happens when the control flow steps out of or into one of the supplied
generator procedures through exceptions or call/cc.

"gappend" was just an example, though. There are many other examples
in many other SRFIs (my own probably as well) where we are not as
precise as R6RS or R7RS. This is somewhat a pity as R7RS-large should
be able to cover that part of R6RS that is not covered by R7RS-small
due to its, well, small size. So it would be great if the quality of
R7RS-large were at least as good as the quality of R6RS.