"Arthur A. Gleckler" <arthur_at_zurich.csail.mit.edu> writes:
>>> * 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?
>
> It's the last one: unit-vector.
Got it.
> "Defines... to" is not really English. That preposition isn't used
> with define. I think "defines... to be" would be just fine. In that
> case, "to" isn't a prepoistion, but is the infinitive, which is fine.
Okay, I'll rephrase. Thanks (also to John Cowan) for explaining!
>>> * 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?
>
> About half-way down the left column on p. 76, this appears:
>
> (make-compound-condition
> (make-condition (condition-type) '<field-name> <value> ...)
> . . . )
Right. This is because it's too wide. There are a number of other
examples that are also not indented, for the same reason. ("Examples
for macros and phases" on page 26, for example.)
> Oh, I see. I was looking for "is returned" or "has returned" or
> "returned FOO." You're right that "returned" by itself is correct.
> However, I found it misleading. I suggest "has returned" to make
> this read even more smoothly.
Will do.
> Ah, I see. In any case, if there's something automatic you can do to
> make sure that everything that should be in the index is actually
> there, you should.
Everything that has a header line gets an index. (Which is why
&eval-definition didn't, but &syntax does.) Other than that, I do it
manually. I'm open to suggestions :-)
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Tue Nov 21 2006 - 15:11:47 UTC