Miscellanea

[AndrevanTonder <andre@xxxxxxxxxxxxx>]

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

Andre