Many, many thanks for the heroic proofreading. I've applied
basically all of your suggestions. I only mention exceptions here:
> * In <9.22. Declarations>, a sentence says "...the
> implementation... may terminate the computation in an unpleasant
> fashion...." This is an amusing way to describe it. It makes me
> imagine high-voltage electricity through the keyboard, etc. Would it
> be accurate to leave out "in an unpleasant fashion," leaving just "may
> terminate the computation?"
I think the unpleasantness was very much intentional, and meant to
wake up the reader to the almost certainly undesirable outcome here.
In a computer-related context, "terminate" sounds almost benign, and
would more likely to be ignored. (And who knows about the high
voltage?)
> * In <13.2. Explicit-naming syntactic layer>, in the examples after
> the description of record-constructor-descriptor, some protocol
> expressions use the variable p and some use the variable new. Isn't
> this inconsistent?
No, the distinction is explained:
> * In <13.2. Explicit-naming syntactic layer>, in the final
> define-record-type example after the description of
> record-constructor-descriptor, there is extra whitespace on the three
> lines of the call to new. Remove them for consistency.
I can't find this one. What's the name of the record type?
> * In <14.2.1. Condition objects>, the Semantics description for
> define-condition-type uses the verb "defines... to" repeatedly, e.g.:
>
> The define-condition-type form also defines <predicate> to a
> predicate that identifies conditions associated with that type, or
> with any of its subtypes.
>
> This is awkward. It would be better either to use "binds" instead of
> "defines" or to use "defines... to be" throughout.
Could you explain why this is awkward? To my mind, this "defines" is
exactly right as it refers to the underlying semantics, which (as far
as binding is concerned) acts precisely like `define'. "Binding" is
more general, and thus more vague in this context.
> * In <14.2.1. Condition objects>, after the header line for
> condition, the example of make-compound-condition should be
> re-indented.
I can't find that one. Which example is this exactly?
> * In <14.3. Standard condition types>, the paragraph after the header
> line for &non-continuable reads:
>
> This type denotes that an exception handler invoked via
> raise returned.
>
> The word "is" should appear before "returned."
No. :-)
> * The index is missing entries for define-condition-type and
> &eval-definition. Add these and check for other missing entries. Now
> that the document is longer, a complete index makes a big difference.
`&eval-definition' is actually a mistake; it's meant to be `&syntax'.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Mon Nov 20 2006 - 07:47:52 UTC