Clarification Comments (long)

[Guy Steele <gls@THINK-AQUINAS.ARPA>]

A few comments on the comments from SHEBS:

    47 This is OK, although it feels a little uncomfortable to include the
    name of a local keyword variable in a proclamation that may be in
    another file.  Bye bye alpha conversion...

The example was poorly chosen.  The name of the local keyword variable
can be anything, but is normally the same (but in a different package)
as the name of the keyword that the caller needs to use.  Perhaps the
example should have read
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (:FROM-END T)
			   (:START (INTEGER 0 ())) (:END (INTEGER 0 ()))
			   (:INITIAL-VALUE T))
			  T)
		REDUCE)
Now that I think of it, I was trying to follow the rule that the
declaration should look like the parameter list, but with types
substituted for the variable names and with init forms (and supplied-p
parameters) omitted.  It is tempting to use the flatter syntax
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY :FROM-END T
			   :START (INTEGER 0 ()) :END (INTEGER 0 ())
			   :INITIAL-VALUE T)
			  T)
		REDUCE)
but that confuses call syntax with parameter-list syntax.  Now that I have
enunciated the principle, I now see that the truly consistent syntax
is not either of the two example above; to match parameter-list syntax
exactly another level of parentheses is needed:
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY ((:FROM-END T))
			   ((:START (INTEGER 0 ()))) ((:END (INTEGER 0 ())))
			   ((:INITIAL-VALUE T)))
			  T)
		REDUCE)
These extra parentheses could be unambiguously elided in type specifiers,
but the corresponding parentheses may not be elided in parameter lists.

    130 I didn't realize until now that tagbody does have a restriction
    on body contents.  That seems wrong to me.  Presumably lots of things
    will macroexpand into tagbodies, and every one inherits the same
    restriction.  Worse, one implementation's dolist will macroexpand
    into a tagbody, while in another, it will be a special form.  Why
    not say that integers and symbols are tags, and everything else is
    a form? Or that all non-lists are tags?

But all objects other than symbols and lists are either constants or
erroneous when treated as forms.  Someone has suggested that strings be
permitted in a TAGBODY as comments.  I don't think we want
floating-point tags.

    186 Doesn't seem *wrong*, but not clear why one can't explicitly test
    symbol-package and intern instead.  Sounds like a frob.

INTERN cannot take a symbol, only a string.

    239 This one seems really unmotivated - why the bits and not the
    font anyway?  Perhaps we could add keywords to char comparison
    to tell which parts of the char are to be considered :-)

The book already specifies that the fonts may or may not be
examined, depending on the implementation, and an example is
given to explain why.

    439 This constrains the implementation to save source code somewhere,
    which is more of a nuisance than a hardship.  This is really another
    one of those user convenience things.

Yes, it's "just" a convenience.  Only COMPILE is so constrained; files
produced by COMPILE-FILE are not required to retain the source code
as well for later loading.

    440 Sure, with the same proviso as for inline functions, that a macro
    call may not be traceable because it's been expanded already.

Good point.