R7RS Dockets

SRFI 175. Reject. We should not have libraries that encourage people to pretend Unicode doesn’t exist, implicitly or explicitly.

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.

CombinatorsCowan. Yes, possibly in the same library as SRFI 210.

SRFI 226. Accept. Threading should be optional.

I think one may need to be designed from scratch. I would take a good long look at the prior art in other languages, especially recent developments in JavaScript and Ruby.

SRFI 148. Reject: though they’re nifty for what they are, they’re made redundant by syntax-case.

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.

SRFI 214. Accept. Note the naming issues on the Ultraviolet docket.

We have SRFI 159, which should be updated to SRFI 166. We don’t need Common Lisp/printf-style formatters: they’re uglier and less flexible.

SRFI 158. Remove from the standard as unfit for purpose. The same applies to lseqs (SRFI 127), which depend on them.

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.

Reject.

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

PortOperationsCowan is a handy-looking utility library (I have already implemented it), although I think it needs a procedure (read-line*? 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.

Reject SRFI 106 as being too thin a layer on top of POSIX/BSD sockets and have only the high-level NetworkPortsCowan and DatagramChannelsCowan APIs.

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

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.

SRFI 27 plus SRFI 194. Accept, but there should be an (optional) library exporting the same identifiers that guarantees the randomness is cryptographically acceptable.

See the section on continuations. Mailboxes for Erlang-style message-passing would be very handy.

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.