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

[John Cowan <cowan@ccil.org>]

[-- Attachment #1: Type: text/plain, Size: 4576 bytes --]

On Mon, Aug 3, 2020 at 3:41 PM Marc Nieper-Wißkirchen <marc.nieper@gmail.com>
wrote:

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


It certainly should not.  But it can happen when one person writes the spec
and another the implementation, and communication is less than perfect.
Process improvements since then should make this less likely, but
arse [sic] longa, vita brevis.


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


That can and shall be fixed.  The spec is stabilized, short of a
post-finalization note (which is never mandatory), but the implementation,
like any other program, must be presumed to have bugs, which is why
its behavior is *not* part of the spec (and why we don't use the term
"reference implementation" any more).


> > and the specifications themselves are self-contradictory (see above).


I'll look into that further.


> > At this point, I don't see how the problems can be fixed without
> > breaking some users' assumptions, and therefore breaking existing code.
>

*All* bug fixes, even those to bring an implementation into compliance with
its spec, risk breaking existing code.  Some people may have inserted
workarounds that are unavoidably not idempotent.

My favorite example of this is a stock-ticker service that transmitted
incorrect stock prices for stocks with 4-letter ticker symbols like AAPL.
The bug was easy to work around, and many people did.  When the bug was
eventually fixed, many clients were extremely annoyed, and insisted that
correct prices only be made available when using a versioning flag.  I
don't know the final outcome.  I hope the people responsible for the server
stood their ground.

 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.


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


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


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

- Formal semantics are almost always missing.
>

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


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


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

I stand behind my final reply in that thread as well as Shiro's.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
A mosquito cried out in his pain,
"A chemist has poisoned my brain!"
The cause of his sorrow / Was para-dichloro-
Diphenyltrichloroethane.                                (aka DDT)

[-- Attachment #2: Type: text/html, Size: 7292 bytes --]