See ColorDockets.md for an explanation of what each proposal is.
This page is an evolving work in progress. (TODO: Link each SRFI mentioned diectly from here.)
My view is that everything portable (in John Cowan’s sense of ‘can be implemented in pure R7RS small’) which is accepted for Large should be mandatory for all Large implementations. For things which aren’t portable, I’ve explicitly written whether they should be mandatory or not (in my view).
Since things move around the ballots, I’m now listing issues here in alphabetical order.
1. ASCII character library
SRFI 175. Reject. We should not have libraries that encourage people to pretend Unicode doesn’t exist, implicitly or explicitly.
2. Compound objects
SRFI 222. I am unconvinced that the performance-related objections to this proposal by Marc Nieper-Wißkirchen have been adequately answered. However, it is finding its way into a number of other proposals.
SRFI 226. Accept. Threading should be optional.
5. Date and time library
6. Eager syntax-rules
SRFI 148. Reject: though they’re nifty for what they are, they’re made redundant by
SRFI 209. Reject. We have symbols.
FinalizersCowan. Why only one guaranteed finalizer per object? I’d prefer to adopt Gambit’s wills, but Chicken’s system where one object can have as many finalizers as you like is also better.
10. Format strings
SRFI 173. Yes if and only if we have at least use for these at the language level. Otherwise it’s application-level stuff and should go in an external library.
13. INI files
14. Integer sets
SRFI 217. Accept, but rename everything to
fx instead of
i to be consistent with fxmappings, to make clear that they’re restricted to fixnums, and to avoid confusion with the convention that i- prefixes are for immutable things.
GettestCowan. I don’t think this should be in R7RS Large at all, mostly because gettext is a crappy interface in comparison to newer, more linguistically-sophisticated translation libraries like Fluent (f.k.a. l20n), and I think those are too complex to go in the Large standard library, so they should be external libraries. (Localization in general was reassigned to a possible future WG3, back in the early days of WG2. I think a
(scheme i18n) library, similar in scope to the ECMAScript Internationalization API, would make sense, but agree with the decision made back then to punt out out to a future ‘ER7RS’ or similar.)
16. I/O Utilities
PortOperationsCowan is a handy-looking utility library (I have already implemented it), although I think it needs a procedure (
read-record?) which is like
read-line but lets you specify the line/record ending character/string. (I have also already implemented this.) Lose the generator/accumulator procedures, though (see above).
Reject all proposals. Data formats come, and data formats go: mostly, they go, but Scheme is forever. Also, SRFI 180 is badly designed imo; if we must have a JSON library,
(schemepunk json) is the better option. But I will vote against any option.
SRFI 204. Unenthusiastic accept. I think it’s too complicated and would prefer a stripped-down version, but as it’s
syntax-rules-compatible it’s hard to object to.
I think I would like to see
(chibi parse) in the standard library. But I wouldn’t mind if this were an external library.r
21. Procedural record types
I lean in the direction of SRFI 150, though this is only a sketch at the moment. Once we have e.g.
syntax-case, it will be possible to fill out the details.
22. Random numbers
See the section on continuations. Mailboxes for Erlang-style message-passing would be very handy.
24. Unicode normalization
I think R6RS’s conversion procedures are the best option, although (in contrast to other portable things) perhaps this one should be optional for implementations, if there isn’t a portable implementation available by the time we get to deciding what’s mandatory for Large and what isn’t.
Doesn’t belong in R7RS Large; should be in a third-party package library.