Thank you, John.
Didn’t we already just vote to include SRFIs 210 and 219 on the Yellow Docket?
Here are my arguments for and against each proposal apart from those:
SRFI 223 (Binary search): Yes. I am of course the author of this SRFI, so I’m obviously biased. But do note the rationale of this SRFI: vector-binary-search in the (scheme vector) library (SRFI 133) is incompatible with every other Scheme procedure’s idea of what a comparison procedure is — it doesn’t work at all with (scheme comparator), for example. It also can’t be used, for example, to count the number of in elements within a particular range in a sorted vector, because it doesn’t guarantee which index will be returned from the binary search; and it only works on vectors, whereas SRFI 223 also provides a simple plug-in-your-own-procedures way to binary search over any random-access data structure, including one that may be on disk or similar.
SRFI 148 (Eager syntax-rules): No. If we had rejected syntax-case, it would be a yes. The benefit of SRFI 148 is that it can, in theory, be used to write macros in quasi-procedural style in Schemes which only have syntax-rules (including any small implementations which don’t adopt Large, modulo the need for them to support SRFI 147 as well). But I consider this a sufficiently niche use-case, and the SRFI itself is not going away, and you can in theory always bundle its sample implementation into your project if you need it.
SRFI 189 (Maybe/Either): No. We have established patterns for dealing with the problems which these types set out to solve (return #f, or take success/failure thunks as arguments).
(I semi-seriously suggested bundling up Haskellisms like this together into a third-party ‘hl-lib’, comparable to Elisp’s ‘cl-lib’, in #scheme the other day. I still think that would be a reasonable idea.)
SRFI 165 (Environment monad): No. Also a good candidate for hl-lib ;-)
SRFI 175 (ASCII char lib): No. We should *definitely* not be encouraging people to write programs that only work properly on ASCII input. A more minimal solution would be to add e.g. char-set:ascii, char-set:ascii-letter, char-set:ascii-lowercase etc. to (scheme charset) [sic].
[SRFIs 214 (Flexvectors), 161 (Unifiable boxes) elided: I have abstained on them.]
SRFI 166/SRFI 48 (formatting): SRFI 166 should upward-compatibly replace SRFI 158 as (scheme show). SRFI 48 was already voted out once, iirc, when SRFI 158 was adopted; I don’t see why it’s been restored to the ballot.
SRFI 180 (JSON): No, on two grounds. Firstly, JSON is certainly a popular serialization format today, but I don’t know anyone who uses it who doesn’t wish it were better. (Complaints: Not enough data types (no binary string, no set, no date-time); unclear semantics of numbers/no obvious bignum or exact rational type; verbose when records are repeated; you can’t have anything other than strings as keys in a mapping; no circular references; human-readable but frustrating to write by hand due to restrictions on comma placement and similar; no canonicalization form so can’t be hashed/signed/etc.) The number of complaints about it suggest it is ripe for replacement as the Internet’s data serialization format du jour — when considering a language with the longevity of Scheme, I think it a bad idea to jump on this bandwagon. As I said in #scheme: data formats come, data formats go — mostly they go, but Scheme is forever. (If we had designed R7RS Large twenty years ago, everyone who now wants a JSON library would presumably have wanted an XML library. Enough said, I hope.) Secondly, SRFI 180 is badly-designed as JSON APIs go. There is no need for both json-generator and json-fold; the former is a questionable application of generators; the latter takes too many positional arguments; worst, *both* of them make it to difficult to do something simple like say ‘I want objects in a SRFI 146 mapping rather than an alist, but all the other default deserialization options are okay’. There are two security parameters when at most only one is needed (and I note no other language’s JSON library that I’m aware of provides either — JSON is not vulnerable to input explosion attacks like the billion-laughs of XML, for example); one of the names of the security parameters is ungrammatical. If we must have a JSON API, I would prefer something absolutely minimal like Adam Nelson’s (schemepunk json); but in general I’m opposed to including any JSON library in R7RS.
Hooks: No, at least as long as this remains application-specific. If a future R7RS Large library proposal has a use for hooks, I would be okay with putting this back on the ballot. As it is, I think this is better solved at the level of individual applications or third-party libraries.
Daphne