This page is part of the web mail archives of SRFI 97 from before July 7th, 2015. The new archives for SRFI 97 contain all messages, not just those from before July 7th, 2015.
It looks pretty good. A couple of comments: Should export levels be specified? I think that would be necessary for the goal stated in the abstract: ...there is a real need to organize these existing SRFI libraries so that they can be portably referenced.I would suggest that the export level be assumed to be 0 for all exported bindings of all SRFIs /except/ SRFI-46: Basic syntax-rules extensions, which should export SYNTAX-RULES for level 1, provided the author agrees. This would allow SRFI-46 to be portably imported and used without a (FOR ...) clause (which, for example, the basic ERR5RS proposal lacks).
Withdrawn SRFIs are not considered here. Should they be? I would vote "no". ERR5RS: My hope is that this SRFI carries over without issue to ERR5RS. But someone who knows more about the library system of ERR5RS will have to evaluate this. I am not aware of any issue. SRFI 9, Defining Record Types, and R6RS Records. What relation should SRFI 9 records have with R6RS records?I do not think any relationship should be assumed. It might not be in harmony with the intent of the author, but even if it is, assuming a relationship would amount to an effective post-finalization modification or extension of SRFI-9 itself, which would defeat the purpose of the actual
original SRFI process. SRFI 42, Eager Comprehensions, defines qualifiers, which are used as macro keyword literals, and some of these conflict with names provided by (rnrs base). Should anything be specified about these keywords (eg, should this library provide bindings?, the same bindings as in (rnrs base)?, etc.)?This is a tricky one. One has no choice but to export some bindings for the conflicting literals (if, not, and, or). If one re-exports the same bindings as (rnrs base) for these conflicting literals, the library will be more convenient to import into most programs. However, one then cannot write a program that uses SRFI-42 but that, at the same time, excludes the (rnrs base) meaning of IF (as for example PLT 4 that excludes one-armed IF). It would really be much cleaner to export different bindings for these literals, but then they would have to be renamed if imported into an (rnrs base) program, which is inconvenient. Perhaps the author can be persuaded to use his colon-based naming convention for keywords uniformly (making it :and, :or, ... for uniformity with :range, ...).