R7RS Dockets

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.

3. Combinators

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

4. Continuations

SRFI 226. Accept. Threading should be optional.

5. Date and time library

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.

6. Eager syntax-rules

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

7. Enumerations

SRFI 209. Reject. We have symbols.

8. Finalizers

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.

9. Flexvectors

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

10. Format strings

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.

11. Generators

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

12. Hooks

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.

15. I18n/L14n

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

17. JSON

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.

18. Matching

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.

19. Networking

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.

20. Parsing

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

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

23. Threads

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.

25. UUIDs

Doesn’t belong in R7RS Large; should be in a third-party package library.