[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proof of CLOS Document

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

>     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

> 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.