I have been working on a formal R7RS-Large Red document, which is
intended to be a precise specification of the libraries included in
the Red Edition. I have taken the various SRFIs, converted them to
LaTeX, and am in the process of trying to make everything consistent.

For the reason stated in the first bullet point below, I am not
posting the draft just yet, but if we can get the copyright issue
resolved, I would hope to have a draft up soon for comment. However,
there are a number of unresolved issues that I'd like comment
on. Addressing all these issues will take time, but I wanted to get
people thinking about them.

   * UNRESOLVED: the original SRFIs each contain a copyright notice of
     the form “Copyright © 20xx, YYY. All rights reserved.” This notice
     technically makes the distribution of this document illegal!
     Ideally, I believe that R$^7$RS-Large should be placed essentially
     in the public domain, as was R$^7$RS-Small (which makes the
     statement “We intend this report to belong to the entire Scheme
     community, and so we grant permission to copy it in whole or in
     part without fee.”)

     - We need to get written permission of the SRFI authors to use
       their work in this way.
     - Future SRFIs intended for incorporation into R7RS-Large
       should probably bear a different copyright (or permission
       notice).
     - I intend to move all the copyright notices from the SRFIs
       onto a copyright page at the beginning. The existing copyright
       notice (found in all the SRFIs) seems to be about “Software”,
       and thus might not be relevant to this Report.

     IANAL, so there may be other copyright issues I don't know about.

   * UNRESOLVED: I  have only removed the administrivia (SRFI
     status) and local tables of contents, and have left the Rationales
     unchanged. In some cases, there is material that belongs here
     (e.g., the definition of “linear update” from SRFI~1), but much of
     the Rationale material is about why things are done a certain
     way. Nothing like that appears in R7RS-Small, so I'm not sure
     it's a good idea to include it here. Possible courses of action:

     - delete it all, with the exception of material needed for
       understanding the specifications, and refer readers to the
       original SRFI.
     - delete it all, with the above exception, and extract the
       remainder to a separate Rationale document (as was done with
       R$^6$RS).
     - retain it, perhaps with some editorial compression.

     I'm pretty neutral on these alternatives, but would note my
     preferences for clarity and concision.

   * UNRESOLVED: Some of the SRFIs contain “Procedure Indexes”. I have
     commented these out (though left them in the LaTeX source); we can
     decide whether just to leave them out or to reformat/replace them,
     or perhaps use a mini-TOC or an overview paragraph in each
     section.

   * UNRESOLVED: there is wide inconsistency in the notation of
     individual entries, in particular in type signatures. Some
     sections use the conventions of the Scheme reports in using
     specific kinds of names for specific types, while others use a
     notation reminiscent of ML/Haskell type signatures. Presumably, we
     should use a consistent notation, but what should that be? Also,
     authors of future SRFIs should be encouraged to use the same
     signature notation.

   * UNRESOLVED: The SRFIs have “Issues” sections, many of which
     are empty. Any remaining issues should be addressed in the body of
     the specification, and the Issues sections themselves removed.

   * UNRESOLVED Should the Implementation sections be removed, or
extracted to
     a separate document?

   * UNRESOLVED: What about References and Bibliography?  Preserve?
     Remove? Bibliography at end?

   * UNRESOLVED: Do we want to publish the final report in the “ALGOL
     60” format used in R7RS? I'm OK with that, but I'd probably
     arrange to do that after fixing everything else. (Argument for:
     consistency with the Scheme reports, argument against: this report
     doesn't really have much to do with ALGOL 60.) Some type signature
     notations would really be difficult in a two-column format, so the
     two decisions aren't independent.

-- vincent