Agreed. The goal here is to find disparities, and then determine the correct text.• Final proofreading against the original SRFIs.
Of course, the SRFIs have plenty of typos too that should not be preserved.
I will make that change.The copyright notice should say that the license *does* apply, not that it might. "Might" does not impress lawyers.
Well, since the current document is far from finished, I think this will have to be done in stages, where it's done at all. Who has signoff on changing text (as opposed to removing it)? The original SRFI author? This list? Or...?• 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.
I'm not sure I know the difference. If I were asked to articulate one, it would be something like “objects are things popularized by Alan Kay, while values have been around since the earliest programming languages.” I'm uncomfortable with the current situation, but in the absence of a consensus, I'll leave it alone.• 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.
I'm inclined to remove them. Again, I'll wait for a consensus.• 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.
That seems feasible. Let's see if anyone else comments on this.Moving all the acknowledgements into a single section in the back would be a good thing, I think.
I think I'll put a sentence or two in the Introduction saying this, and pointing out that an implementation can be Red-compliant [sic] without implementing these features. Thus portable programs should eschew them.• 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.
I agree. The ALGOL 60 format of RnRS was a joke, and there's no need to perpetuate it.• 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!
Many thanks (and thanks also to Arthur Gleckler for his kind
words)!
And now I'm now going to start on the Tangerine Edition.
-- vincent