[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clarification Comments (long)
- To: firstname.lastname@example.org
- Subject: Re: Clarification Comments (long)
- From: email@example.com (Stanley Shebs)
- Date: Fri, 13 Dec 85 15:00:55 MST
- Cc: firstname.lastname@example.org
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 ()))
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 ())
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 ())))
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
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
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.