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.
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.
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. 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.
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.
Similarly, an implementation of Posix that only permits the root directory and a single file of length 0 to exist, or of C that allows only one function per program, or of R6RS that provides only three inexact numbers (0.0, a positive number, and its negation) are all conformant, but they aren't *useful* because of their low quality of implementation.