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

[Mark H Weaver]

Hi John,

John Cowan <cowan@ccil.org> wrote:
> Mark Weaver wrote in July 2019:
> 
>> Also, the provided implementations of 'generator-find', 'generator-any'
>> and 'generator-every' are incorrect:
> 
> 
> I appreciate your finding these bugs.  I wish, however, that you had also
> sent them to <srfi-121@srfi.schemers.org>.

Sorry about that.  As I recall, I didn't send those bug reports to the
SRFI-121 mailing list because I had assumed that the bugs were not in
the reference implementation.  I made that assumption because the buggy
procedures included comments that expressed uncertainty about what the
specification intended, e.g. "the spec would have me return #f, but I
think it must simply be wrong" and "a literal interpretation might say
it only terminates on #eof if (pred #eof) but I think this makes more
sense."

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.

I *did* send bug reports to the SRFI-121 and SRFI-158 mailing lists
about inconsistencies in those specifications.  See:

  https://srfi-email.schemers.org/srfi-158/msg/11780787/
  https://srfi-email.schemers.org/srfi-158/msg/11781931/
  https://srfi-email.schemers.org/srfi-121/threads/2019/07/

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.

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

      Mark