Mlynarik's comments

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

First I'll address the general grammatical comments. As far as I can tell
by reading the OED, ``congruent with'' is standard British English.  Using
Webster's Second Unabridged - the most prescriptive American English
dictionary - I find ``congruent with'' used in general contexts and in
most mathematical contexts.  My perusal of math texts seems to indicate
``congruent to'' is acceptable when discussing number theory. I cannot
find explicit grammatical justification for ``congruent to'' in any
context. Because we are not talking about number theory, I don't believe
any changes are necessary.

It is currently correct to use the following rules for ``different'':  The
phrase ``different from'' is used when introducing a phrase while
``different than'' is used when introducing a clause. My references claim
``different from'' and ``different than'' have both appeared for the
last 300 years. British usage admits ``different to.''

Note there is no use of ``different than'' (or ``different from'')
in chapter 1.

To comment further on the grammar in chapters 1 and 2. Linda and I are
both relatively careful writers in terms of grammar, and I can assure you
that we have not dashed off this piece.  Furthermore, we have engaged copy
editors to proofread major drafts of these chapters before they are sent
out. The style of writing might be academic, but I believe it corresponds
to acceptable Amercian English in all cases, and even the editors of the
OED now accept American usage as standard.

The remainder of this message is a response to Richard's comments. I have left
out specific comments to which Moon responded with remarks with which I
agree.

Richard writes:

``1-22 2nd PP in `Intro to methods':  The first and second sentences
seem to be too directly contradictory.  I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.'' ''

The sentences in question are:

``A method object is not a function and cannot be invoked as a function.  An
implementation may extend the \OS\ so that method objects are functions.''

The reason it is stated this way is that no one writing portable code can
take them to be functions, but we do not require them to not be functions
in all implementations.  If we wrote it your way then someone could
legitimately understand that within a single implementation a particular
method object may or may not be a function. 

The style we use consistently throughout is to state a constraint
and then allow extensions.

Richard writes:

``1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.''  Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs?  If
so, this should be made a lot clearer.''

Moon's remark is correct and the passage has been repaired.

Richard writes:

``1-31 2nd PP.  ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.''  The uppercase text seems redundant.''

It is redundant and intentionally so: You cannot possibly misread
the current version. A misreading would be

``To specify that a generic function is to use one of these method
combination types, the name of the method combination type is given as the
argument ... to any of the other forms that specify generic function
options.''

Richard writes:

``1-31 5th PP.  I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...'' ''

``Could have been'' but weren't? Your rewrite talks about an implementation
choice that may or may not be relevant, whereas the current language
discusses semantics.

Richard writes:

``1-32 <foo>''

I agree with Richard on the weirdness of this description, but
I could not (and still cannot) think of a more precise approach to
describing this. I have spent weeks on the bulleted item over the
last 2 years.

Richard writes:

``1-39 Last PP.  I would write ``The second argument to shared-initialize
may be one of the following:''  ''

Right.

Richard writes:

``1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated.  Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods.  Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.''

Right. I added such an introduction to shared-initialize early
in the section.

Richard writes:

``1-40 4th bulleted PP.  It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.''  or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg.  I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.''

Right.

Richard writes:

``1-41 Last PP.  What ``certain optimizations are permitted.''  Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize.  The Chapter 2
description of shared-initialize explains this -- there should be some
xref.''

I thought it already cross-references to shared-initialize.

Richard writes:

``1-42 Last PP.  I found this hard to read.  Suggestion....''

This paragraph has been rewritten based on the newthink on the
check-initargs problem.

Richard writes:

``     My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document.  I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.''

Yes, I would like to hear your ideas.

Richard writes:

``1-43 6th PP.  The aside ``This two-step process ...'' disrupts the
description of what the process is.  Is should be moved below, after the
sentence ``... and other user-defined actions.'' ''

This paragraph is now different enough that this comment isn't as valid.
In particular, other circumstances have been added in which the process
can start up, and the discussion of when it can happen is the current
focus of the paragraph.

Richard writes:

``1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed.  For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
....''

Good idea. I've so modified the sections.

			-rpg-