Response to dpk's comments on R7RS-large dockets:
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.
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.
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.
I'm still groping around on this, but I feel like it should be possible
to revive SRFI 177, without the annoying call/kw
and using 'foo as a keyword rather than :foo or foo:.
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 R[567]RS. 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.
Added to the PortOperationsCowan spec.
Moved to Indigo.