Thanks Alan, most of these I'll update when I get a chance. On Mon, Nov 26, 2012 at 5:56 PM, Alan Watson <[email protected]> wrote:
> > §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". > I think we want "variable reference." > §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. > Also procedures. There were a few other cases like this, notably in the storage model section. Thanks for catching them. > §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. > Yes, we definitely do want to describe everything in terms of lambda (and do so in the derived syntax section). Define is a bit of an exception, but this text has been in here forever. I suppose we could clarify "all local variable binding constructs can be explained in terms of lambda." > §3.4 Again, you define locations in terms of eqv?. This has already been fixed. The 8th draft will be slightly delayed pending the results of the 9th ballot. > §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". > There is an initial repl environment but we can probably make this clearer. > §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. > If only one argument is a NaN it's impossible for the fields to be the same. -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
