Re: Proof of CLOS Document

[kempf%hplabsz@hplabs.HP.COM]

New page numbers refer to the draft on SAIL as of Oct. 22, which
may be out of date with the current draft, since I've not had
a chance to update.

>     pg. 1-17: Last Paragraph. It is not clear from this what should happen
>     if (TYPE-OF <obj>) returns a type speciifer which is a list. Should an
>     error be signalled or should the CAR of the list be used? On pg. 42 of
>     CLtL, the description of type specifiers which are lists suggests
>     that the CAR should work.

> Is this the page that has figure 1-1 on it?  I can't find anything on that
> page that looks like what you're referring to.  I suspect you've uncovered
> a problem here, but I can't find the problem.  Note however that the
> second paragraph on page 1-16, where it says (type-of I) is S if S is
> the proper name of C, else C, should say that this only applies when C
> is an instance of STANDARD-CLASS.

Yes, this is the page with Fig. 1-1. I think what I'm trying to anticipate
is implementation problems. Re-reading the second paragraph on page 1-16,
the specification seems to be clear on this. If TYPE-OF returns a list,
then it's up to the implementation to make sure the first element is
used in SYMBOL-CLASS.

>     Overall: When referring to SETF functions, the list specifying a
>     SETF function name is often not quoted. Example: (fboundp (setf <name>)).
>     If the argument had been a function symbol name, however, it would have
>     been quoted, since FBOUNDP is a function and therefore the arguments
>     are evaluated. Shouldn't this be so for SETF function names as well,
>     or is the assumption that (SETF <name>) is a macro which returns the
>     actual name of the function (e.g. expands into something like '<actual na
me>)?

> It's just missing quote marks; no hairy macro like that was intended.
> Do you have page references for these typos?  I think I noticed one or two,
> but they're easy to overlook and you probably saw some that I missed.

I marked some of them down. Here they are:

pg. 2-24, 4th paragraph; pg. 2-36, 4th paragraph; pg. 2-40 2nd bullet item;
pg 2-42, 1st paragraph under ARGUMENTS

>     pg. 2-30: Top of page. I'm curious if the form generated is expected to
>     be executable. That is, if <operator> can be a keyword symbol, then the
>     implicit assumption is that the function cell of keywords can be 
>     bound. I know this is possible in Symbolics CL and not in ours, also
>     I don't think CLtL says anything either way. Is there a Cleanup proposal
>     on this?

> This moved to 2-29 in the latest draft (if things are getting shorter, that's
> a good sign!).  I don't see anything that implies here that an implementation
> has to allow <operator> to be a keyword symbol.  Certainly that was not
> intended.  On the other hand, I don't know of anything in CLtL that allows
> implementations to forbid defining keyword symbols as functions.  Anyway,
> the intent here is that <operator> is the name of a function, macro, or
> special form and can appear in the car of a form; precisely what objects
> satisfy that criterion is defined by CL rather than CLOS.

As mentioned, CLtL says nothing either way about whether keyword symbols
can be defined as functions. The only reason I asked about this was because
the last sentence in that paragraph states that <operator> can be specified
by a keyword option. If there are any other implementations besides ours
which have chosen to forbid binding the function cell of a keyword symbol
to a function, this might be a problem.