[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] More editorial comments



Thanks Alan, most of these I'll update when I get a chance.

On Mon, Nov 26, 2012 at 5:56 PM, Alan Watson <alan@x> 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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports