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

[Marc Nieper-Wißkirchen]

Am Mo., 3. Aug. 2020 um 18:00 Uhr schrieb <guile-devel-request@gnu.org>:

> Message: 1
> Date: Sun, 02 Aug 2020 18:39:32 -0400
> From: Mark H Weaver <mhw@netris.org>
> To: John Cowan <cowan@ccil.org>
> Cc: guile-devel@gnu.org
> Subject: Re: [PATCH] add SRFI: srfi-121; generators
> Message-ID: <87v9i0zn7k.fsf@netris.org>
> Content-Type: text/plain

> It didn't occur to me that the reference implementation of a finalized
> SRFI would include comments like "the spec would have me return #f, but
> I think it must simply be wrong".  However, I see now that I was
> mistaken.  Indeed, those buggy implementations and confused comments are
> in both the SRFI-121 and SRFI-158 reference implementations.

To be fair, one should remark that the reference (or, rather, sample)
implementations do not belong to the SRFIs proper. That said, it is
surprising why the questions raised in the sample implementation
haven't been resolved during the draft period of the SRFI.

> I'm sorry to say it, but in my opinion SRFI-121 and SRFI-158 should be
> deprecated and avoided.  The reference implementations do not match the
> specifications, and the specifications themselves are self-contradictory
> (see above).  Therefore, it's entirely possible that users of these
> SRFIs may have contradictory expectations about how these procedures
> behave.  Some may have read the spec one way, some may have read the
> spec in a contradictory way, some may have learned from how the buggy
> reference implementation behaves, and others may have learned from the
> behavior of a different SRFI-121 implementation that doesn't have those
> bugs.  At this point, I don't see how the problems can be fixed without
> breaking some users' assumptions, and therefore breaking existing code.

There are a number of SRFIs with post-finalization notes, most of
which alter some behavior of their respective SRFIs. 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.

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. Of course, one can circumvent any problems by importing the
libraries through their SRFI names and not using the scheme namespace
before R7RS-large has been finalized.

> I sincerely hope that these two SRFIs are an aberration, and not
> representative of the quality of the R7RS-large effort.

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. This is especially true in the following
areas:

- Questions of tail context are often ignored.
- Higher-order procedures are often silent with respect to call/cc,
exceptions or side effects.
- Formal syntax is often missing.
- Formal semantics are almost always missing.

In particular, the ignorance of call/cc in most SRFIs dealing with
higher-order procedures make this defining feature of Scheme hard to
use in a portable way.

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.

Of course, all this can be fixed, but by the sheer size of R7RS-large,
I doubt that it ever will.

Marc

PS: One of my own issues with SRFI 158 is that accumulators are not
that well-designed from a logical point of view. I summarized it here:
https://srfi-email.schemers.org/srfi-158/msg/6219505/. A follow-up
thread begins here:
https://srfi-email.schemers.org/srfi-158/msg/6557831/.