> 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
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
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
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 RRS) 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:
I stand behind my final reply in that thread as well as Shiro's.
John Cowan http://vrici.lojban.org/~cowan email@example.com
A mosquito cried out in his pain,
"A chemist has poisoned my brain!"
The cause of his sorrow / Was para-dichloro-
Diphenyltrichloroethane. (aka DDT)