r7rs-dpk-response.md

Response to dpk's comments on R7RS-large dockets:

3. Orange

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

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

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

6. Lime

6.1 Strings

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.

6.3. JSON.

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.

6.6. Maybe/Either

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.

johnwcowan/r7rs-dpk-response.md