Comments, suggestions, and other reactions will be most gratefully
received and acted upon.
Here's my feedback to your notes,which so far is all I have read (so some of what I say may be nonsense). I've left out everything on which I either approve or have nothing to say about.
• Final proofreading against the original SRFIs.
Of course, the SRFIs have plenty of typos too that should not be preserved.
• Copyright notices have been moved from the end of each SRFI to a centralized copyright page at the beginning of the document. All the text (apart from some timestamps) has been preserved.
The copyright notice should say that the license *does* apply, not that it might. "Might" does not impress lawyers.
• The Rationales have been preserved, with no change, from the original SRFIs. Some of the material is repetitive, and might well be centralized in the Introduction (for example, multiple definitions of “linear update”).
Only do this when it is easy.
• Some SRFIs use the word “object” where others say “value”. R7RS is unhelpful here, saying (in §1.1) “values (also called objects)”. I don’t like using two different words for the same referent. But maybe that’s just me.
I would say "leave that alone". My tendency would be to use "object" for something mutable and "value" for something mutable, but I am sure I am not consistent about that. R7RS-small says they are the same, so we can use either.
• What about References and Bibliography? Preserve? Remove? Bibliography at end? I’ve just left
them in., I have prefaced each Acknowledgements section in the document with “XXX writes”, where
XXX is the SRFI author’s name.
I don't feel strongly about this. Bibliographies are important for scientific papers, but standards usually only have them when some other standard (like Unicode, say) is "incorporated by reference", which means that the MUSTs in the referenced standard also apply to the referencing standard.
Moving all the acknowledgements into a single section in the back would be a good thing, I think.
• Some features are described as “optional” or “deprecated”. What does that mean in the context of this
report? Clearly no portable program can use these.
Optional features should be left in for the guidance of implementers.
Deprecated features *must* be left in, as no decision has been taken to remove them. Calling them deprecated is just an advisory to users that they might be removed in the next standard, and to future standardizers that they should consider removing them.
• Do we want to publish the final report in the “ALGOL 60” format used in R7RS? Or what?
I'd say no. Two-column PDFs are very irritating to read on landscape-style monitors, and I don't think many people will print a 235-page document nowadays.
Anyhow, great work!