Work in progress, please ignore for now
- Adding Unicode support is too large a change from R5RS.
- It is still possible for a Scheme to provide ASCII-only support; the only constraint is that it must be done in a way that extends smoothly to the rest of the Unicode repertoire.
- Exceptions integrate badly with the rest of the language.
- Perhaps that is because they are pure R6RS. We can't do it all.
- The syntaxes #true and #false are totally gratuitous.
- They add a little extra readability, but are optional. Early versions of the Scheme standard provided them in the forms #!true and #!false.
- The lexical syntax #| ... |# is unsightly.
- A matter of taste. Many Schemes provide it already, including R6RS.
- The lexical syntax #!(no-)fold-case is a bit ugly.
- It is R6RS-compatible and fairly clear. The alternatives #cs (case sensitive) and #ci are less widely standardized and less intuitively clear.
- The read-line procedure can cause a denial of service because it does not provide for a limit on the amount of input read.
- True. However, read has the same problem. It's easy for an implementation that worries about this sort of thing to provide an optional second argument setting a limit.
- The draft should reflect the intersection of high-quality industrial-strength implementations, not the intersection of every toy Scheme ever written.
- Which implementations are those? Schemers disagree.
- The call/cc abstraction is intractable and not useful and should have been excluded.
- The WG did not believe that the very high bar for removing an IEEE Scheme feature was met.
- The draft was forbidden by its charter to remove restrictions that make additional features seem necessary.
- If the restrictions in question were hard-coded into R5RS, and removing them would break backward compatibility, then yes. Restrictions that could be removed without breaking backward compatibility could be and sometimes were removed; for example, the restriction that load loads into the interaction environment only.
- The large language should have been developed before the small language.
- This objection is untimely. In addition, developing a large language and then subsetting it would have a higher overall risk of failure; if the large language was never completed, the small language would not exist.
- The text-handling routines are redundant or inelegant in a Unicode world, but could not be removed or fundamentally altered due to charter restrictions.
- Scheme would probably be better off not treating strings as sequences of characters, but rather treating characters as a special case of strings. Unfortunately, that's too far away from the IEEE model.
- The interaction between exceptions, dynamic-wind, and continuations is missing something orthogonal.
- This objection is too vague to meet head-on.
- The draft made many matters settled by R6RS undefined again.
- Since R6RS support never became pervasive, these matters were in practice not defined in a way that Schemers could rely on, unless they used only R6RS-compatible implementations.
- The order of arguments in the draft's bytevector-copy is fundamentally incompatible with R6RS in an undetectable way, though it is R6RS that is wrong here.
- True and unfortunate, but the draft's approach is consistent with the rest of Scheme.
- The draft should have included delimited continuation support.
- The large language will provide it.
- The draft does not provide procedures that operate on mixed types of sequences (e.g. a map function that accepts a list and a vector and applies a two-argument function element-wise on them).
- True. Unfortunately, no one proposed them during the working life of WG1.
- The draft is too conservative in its changes to R5RS.
- That was a charter requirement.
- #467 should not be reverted.
- The storage model should return to saying "equivalent in the sense of eqv?" rather than "operationally equivalent".