Re: [Scheme-reports] More editorial comments

[John Cowan <cowan@x>]

Alan Watson scripsit:

> §1.3.1 "Every identifier defined in this report appears in one of
> several libraries." Should be "one or more of several libraries".

Done.

> §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".

Done.

> §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".

These are not uses, but a (re)definition and a mention respectively.
I did switch 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".

Done.

> §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.

Weakened to "the same", since the point here is to explain -> rather than
to be technical about different notions of sameness.

> §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,

Any other identifier than itself.  "A" is likewise different from any
other identifier (except itself).

> §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? 

Removed the reference to `eqv?`.

> §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 ...".

Done.

> §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".

What you say is true, but definitions are not called binding constructs.
This is not meant to imply there are no other ways to bind identifiers
(`guard` binds an identifier, e.g.)

> §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.

Again, this is about binding constructs (expressions) as defined above.

> §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.)

I see no reason why quote can't be used on implementation-dependent
external representations if the implementation allows it (as most if
not all do).  A standard shouldn't try to prescribe the behavior of
non-standard features of implementations.

> §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?

Already fixed to use operational equivalence instead.

> §3.4 Enumerates immutable objects. However, it fails to mention the
> bindings exported by libraries.

Bindings are not, or at least need not, be objects in that sense.
They may well vanish before runtime.


> §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.

Again, I don't see any problem.

> §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".

Done.

> §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.

Eh?  (define-syntax cond-expand ...) does appear 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"?

It's a constraint on the implementation, not the programmer.

> §4.2.2 In the definition of letrec*, should it also be an error to
> invoke the continuation of an <init> more than once?

I think so -- I'll put it in as a separate change so it gets fuller review.

> §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>.

"Command" would be misleading.

> §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.

It's part of the definition of <derived-expression>.

> §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.

This language is being changed, but NaN can't be `eqv?` to anything but
a NaN, and the case of (eqv? nan1 nan2) is undefined.

-- 
I suggest you solicit aid of my followers       John Cowan
or learn the difficult art of mud-breathing.    cowan@x
        --Great-Souled Sam                      http://www.ccil.org/~cowan

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports