I got up to the §4.2.3 before my flight landed. Regards,
Alan §1.3.1 "Every identifier defined in this report appears in one of several libraries." Should be "one or more of several libraries". §1.3.1 "The full list all the standard libraries and the features they provide is given in Appendix A." The word "features" now has a technical meaning in R7RS; I would suggest "the identifiers they export" instead of "features they provide". §1.3.3 "If category is “auxiliary syntax,” then the entry describes a syntax binding that occurs only as part of specific surrounding expressions. Any use as an independent syntactic construct or identifier is an error." So the following definition, at the top level, is an error: (define else #t) As is the following expression anywhere: (quote else) I'm not sure if the first is supposed to be an error. If it is not, I don't have a suggestion for a correct wording. If the first is intended to be an error but the second is not, then change "identifier" to "variable name". §1.3.3 "It is an error for an operation to be presented with an argument that it is not specified to handle." I suggest replacing "operation" with "procedure". §1.3.5 The discussion of the -> convention in procedure names says that list->vector produces a vector whose elements are eqv? to the those of the list. This is not generally true. For example, if any of the members of the list are NaNs, there is no guarantee that the corresponding elements of the vector will be eqv? to them. §2.1 "Note that || is a valid identifier that is different from any other identifier." Surely || is not different to ||? Saying it is different from any other identifier makes it seem like gensym, §2.4 Again, the standard uses eqv? to define the association between a labelled datum and a reference to a labelled datum. Again, is this the case even for NaNs? Am I to take it that the following must evaluate to #t? (let ((x (read (open-input-string "(#0=+nan.0 . #0#)")))) (eqv? (car x) (cdr x))) §3.1 "An identifier names either a type of syntax or a location where a value can be stored." There are unbound identifiers that neither name syntax or locations. I suggest "An identifier can name ...". §3.1 "Certain expression types are used to create new kinds of syntax and to bind syntactic keywords to those new syntaxes, while other expression types create new locations and bind variables to those locations. These expression types are called binding constructs." Formally, bindings for global syntactic keywords and variables are created by definition types and not expression types. I suggest in all three instances replacing "expression types" by "definition and expression types". §3.1 "The most fundamental of the variable binding constructs is the lambda expression, because all other variable binding constructs can be explained in terms of lambda expressions." Uh, do you really want to go down the route of expression global definitions in terms of lambda? It can be done, but perhaps it's not appropriate for the introduction. If you don't want to go down that route, I suggest referencing outermost define here too. §3.3 "Many objects have standard external representations, but some, such as procedures, do not have standard representations (although particular implementations may define representations for them)." then "An external representation can be written in a program to obtain the corresponding object (see quote, section 4.1.2)." One might think that quote can be used on any external representation, even non-standard ones. Do you want to change the second paragraph to say "A standard external representation can be written ..." or remove "(although particular implementations may define representations for them)"? (See also my comment on §4.1.2 below.) §3.4 Again, you define locations in terms of eqv?. Does this imply that if I store a NaN in a location and then compare the value stored there using eqv?, the comparison must yield #t? For example, must (let ((x +nan.0)) (eqv? x x)) return #t? §3.4 Enumerates immutable objects. However, it fails to mention the bindings exported by libraries. §4.1.2 "<Datum> can be any external representation of a Scheme object." Again, perhaps "standard external representation", unless you avoid mentioning non-standard external representations in §3.4. §4.1.3 "A number of procedures are available as the values of variables in the initial environment. For example, the addition and multiplication procedures in the above examples are the values of the variables + and *." There is no longer an "initial environment"; I suggest "exported by the standard libraries" and "the values of the variables + and * exported by the (scheme base) library". §4.2.1 cond-expand is defined as a derived expression here (and then a variant is defined as a library declaration in §5.6.1), but no corresponding definition appears in the formal syntax of derived expression in §7.1.3. §4.2.2 In the definition of letrec, the standard says "Another restriction is that the continuation of a <init> should not be invoked more than once." Would it be clearer and more uniform to say that this "is an error"? §4.2.2 In the definition of letrec*, should it also be an error to invoke the continuation of an <init> more than once? §4.2.3, §5.1, and §6.12 The top-level and "definition splicing" forms of begin and eval are defined in terms of <expr-or-def>. This is not defined in the formal syntax in §7.1. I believe the definition of begin should be replaced by two definitions, one with a sequence of <commands or definitions> and another with a sequence of <definitions>. The definition of eval should just use <command or definition>. §4.2.3 begin is defined as a derived expression here, but it does not appear in the list of derived expressions in §7.1. §6.1 Is the language in eqv? about IEEE inexacts being eqv? or not according to their radix, precision, etc., meant to include cases in which one argument is a NaN? That is, for IEEE inexacts, is is guaranteed that (eqv? 0.0 +nan.0) => #f? If so, perhaps it would be worth adding an example to remind the reader of this. _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
