Am Sa., 18. Juli 2020 um 07:22 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:

> I'm sorry if it was too early.  We did what amounted to three "last call" periods, each time waiting until the discussion had appeared to quiesce and all issues had been addressed, only to have new issues discovered at the last minute.  This time, as always, I tracked every discussion thread, trying to make sure that no feedback went unanswered.  As far as I could tell, there were no open issues remaining at the point when the authors finalized this SRFI.  As luck would have it, the problem under discussion here was found after that.

I had the impression that the assert/assume thing hadn't been
resolved. We have discussed how to extend SRFI 145 in a new SRFI to
cover the needs for 'maybe-if' and so on. Now, it is a bit of a moot
point unless we change SRFI 189 retroactively when a new assert/assume
SRFI is done.

> Still, I want to figure out how we can do better.  I plan to encourage authors to extend last-call periods at least a week beyond any substantial discussion and/or any substantial revision.  If substantial revisions are made, a new draft should be published and announced and the clock should be reset.

> In the end, though, I will point out that last-call periods are not a formal part of the SRFI process.  While they are an excellent way to determine whether discussion really is complete, and to encourage feedback by setting a deadline, they're not required, and it is up to the author to decide when to finalize or withdraw the SRFI.

I didn't want to blame you nor did I want to blame the authors. As the
SRFI process is codified, the final document is up to the authors and
they have the final say. This is perfectly fine for a single SRFI and
helps to finish SRFIs in a rather short amount of time. Every SRFI
will reflect its authors' style and thinking about Scheme as a
language.

What I wanted and want to say is that due to the way SRFIs are handled
(which, again, is fine for each individual SRFI), I fear that
R7RS-large will become a ball of mud or a C++-mess in the Scheme world
when all we do for R7RS-large is to vote individual SRFIs into it. So
my thesis is that the SRFI process may not be the best process to end
up with a coherent language standard. For example, we may vote SRFI 2
and SRFI 189 into R7RS-large. In "and-let*" an "empty body" is
allowed; in "maybe-let*" (that is supposed to do the same for the
Maybe protocol) an "empty body" is disallowed. Having both is just bad
language design. (That's just an example.)

R7RS-small actually defines (most of) the semantics of the language. A
lot of care has been taken to specify the interaction of higher-order
procedures with non-local control flow or the definition of tail
contexts. We do not see this level of sophistication in many SRFIs and
so we won't in R7RS-large. And I doubt that everyone who votes for or
against a SRFI for inclusion in R7RS-large is always taking a thorough
look at it (I cannot exclude myself here.) Just to pick one, SRFI 116
is an example where the semantics have been unclear long after
inclusion in R7RS-large (and where the discussion is not yet over).
When asked, do you want to see immutable lists in R7RS-large, a common
answer is probably: "Why not? Sounds like a good idea.". So people
vote for it. But what it actually means and what the benefits are is
still not settled.

Marc