Re: Clarification Comments (long)

[shebs%utah-orion@utah-cs.arpa (Stanley Shebs)]

Comments on comments on comments on clarifications:

    Date: Fri, 13 Dec 85 16:19 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>
    
        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.

I like the last solution (without the extra parens!).
    
        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.

After poring over the book, it seems that it is specified as to which things
have tagbodies and which do not.  I have no problem with this clarification
then.

        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.
    
OK, OK, so I left out a step...  I still don't understand why import needs
extra features - is it just to prevent what would otherwise be an error?

        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.

Now that I look at the book, it all makes sense.  Yes, bits should be
considered, in an implementation-dependent manner.

							stan