Am Do., 30. Juli 2020 um 01:18 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Sat, Jul 18, 2020 at 8:32 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> 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.
>
>
> I have just written a pre-SRFI for `assert` and `warn`, modeling them on both `error` and `assume`: <https://github.com/johnwcowan/r7rs-work/blob/master/AssertionsWarnings.md>.  It points out the differences between `assert` and `assume`, and recommends that `assume` be treated as `assert` in debug mode, but doesn't suggest any particular method of indicating debug mode, since existing systems differ greatly on this point.

They could still flag that they are in debug mode through the feature
identifier "debug". This should be easy to implement in any system
that implements feature identifiers, so, in particular, in every R7RS
system.

But, more importantly, would you then add a PFN so that it uses
"assume" instead of "assert" for "maybe-if" and "maybe-and" and so on?
The way it is currently specified is neither helpful nor in the spirit
of R7RS.

> Alas, we really cannot put any more SRFIs into the pipeline until some of the existing 18 drafts are out of it.  As Arthur says, it overloads both reviewers and himself.  Of course comments on it are welcome anyway.

Personally, I think that the number of SRFIs in the pipeline is not a
problem. It may even be a good thing to have a lot of SRFIs in the
pipeline so that they can evolve together. It only becomes a problem
for reviewers if too many SRFIs are in the finalization stage.

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

> The process is certainly not ideal, though I think it's SRFI 2 that is wrong and should perhaps have another PFN.

No, Oleg was quite right in this regard. "and-let*" is supposed to be
a common multiple of both "and" and "let*". The former has no body and
the natural mechanical transformation from "and" to "and-let*" will
produce no body. This is particularly obvious in the edge case of
"(and)", which translates to "(and-let* ())".

SRFI 189 makes a mistake here; unfortunately, it can only be corrected by a PFN.

> But in building something so large within our lifetimes (or mine, anyhow) requires attempting to reduce inconsistencies in light of the plain fact that we will not be able to eliminate them.  All the Lisps have grown by accretion; Scheme underwent a systematic renaming, and some informal principles have been observed during the creation of SRFIs that help reduce inconsistency.  But it would be laughable to say that Lisp was *designed*.  Even the formal semantics were written very much after the fact.

Sure, inconsistencies and plain errors will always remain. But we
should try hard to make inconsistencies easy to spot and act
accordingly.

I see one more problem with the current process, at least until
R7RS-large will be finished. Consider SRFI 159/166, for example. It is
SRFI 159 that is in the current (tangerine) edition of R7RS-large
under the name "(scheme show)". Assuming that the much improved but
slightly incompatible SRFI 166 will be voted into a future edition of
R7RS-large, the bindings in "(scheme show)" won't be stable. And we
don't have library versioning as in R6RS.

>>
>> 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.
>
>
> And in my opinion don't need to be.  It's true that it is *conformant* to SRFI 116 for ipairs to be mutable, but that is what the C Rationale calls a quality of implementation issue.  An implementation that purports to support SRFI 116 and hands out data structures for which mutation is allowed is simply a low-quality implementation that nobody will want to use, no matter how conformant it is.

That's only a minor point. The much bigger problem is that the API to
ipairs is thoroughly impoverished. For example, you put "range->list"
or "range-map->list" into SRFI 196, which is great. But there is no
"range->ilist" or "range-map->ilist", etc. From an economical point of
view, we cannot double or triple all APIs, of course. But it shows us
that this attempt to find a better solution than R6RS to immutable
pairs has probably the same share of problems. Don't get me wrong, I
would have probably written SRFI 116 initially as is as it looks very
plausible. But on second or third thought, the proposal doesn't seem
to be helpful at all. Please see my last two posts of May 23rd on SRFI
116's mailing list where I have been thinking aloud of a better way. I
hope we can discuss it someday. The root problem, as I currently see
it, is that it is observable (through ipair? and pair?) at runtime
whether a pair is immutable or not.

Thanks for reading,

Marc