Response to dpk's comments on R7RS-large dockets:
3.1 Random numbers
The idea of a crypto version of the library sounds fine; I don't think we need another SRFI for it, just a ballot question.
3.6 Linear adjustable strings
This feature is orthogonal to the various string libraries. Non-linear versions are available as part of SRFI 140 and stand-alone as SRFI 118; they are non-portable.
4.2 Eager syntax-rules
This is a framework that lets you write what appear to be low-level macros in a subset of Scheme, but in fact expand into syntax-rules macros. They are called "eager" because they are expanded bottom-up, the same as Scheme evaluation.
5.2 Keyword arguments
I'm still groping around on this, but I feel like it should be possible
to revive SRFI 177, without the annoying
'foo as a keyword rather than
There end up being four kinds of implementations: native interop,
syntax rules, explicit renaming, and run time for those who have
none of the above.
With a few more tweaks, the Sixth String Library (6SL) should subsume most of SRFI 13, SRFI 140, and SRFI 152 while maintaining backward compat with RRS. SRFI 135 can be provided either on top of, or underneath, 6SL, so we don;t have to remove it from the R7RS-large. There will be a deviation for literal strings on Kawa.
The trouble with ECGs is that they change from one release of Unicode to the next. Codepoints grow in number, but they are stable.
I agree that a port that can only read a limited number of characters is much more general. However, it can't be implemented portably.
The SRFI section "Protocol conversion" explains what I think the limitations of the existing approaches are. Maybe/Either have the advantage of being general rather than depending on the data.
6.9. Port Operations
Added to the PortOperationsCowan spec.
Moved to Indigo.