Re: CLOS and the condition system in the CLHS

In article <87ljw5j559.fsf@xxxxxxxxx>,
Richard M Kreuter <kreuter@xxxxxxxxx> wrote:

Hello,

Zach Beane recently noticed that implementations differ in the handling
of invalid initialization arguments to MAKE-CONDITION [1]. This has got
me wondering about some nits in the CLHS that are peculiar in light of
the intentions expressed in some issue writeups.

* The issue CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET [2] was intended to
permit a condition system to be implemented with or without CLOS,
possibly even in a subset of CL that lacked CLOS. However, the
readers (and writers maybe, see below) defined by DEFINE-CONDITION are
said to be methods of generic functions, and generic functions are
CLOS concepts. In particuar, would an otherwise CLOS-free CL subset
be required to support a subset of the semantics of generic functions
just for conditions? (The methods that DEFINE-CONDITION can define
are primary methods that never invoke CALL-NEXT-METHOD, and so might
not be much of an imposition on implementors, I suppose.)

* Zach's point: the Arguments and Values section of the MAKE-CONDITION
dictionary entry describes SLOT-INITIALIZATIONS as an initialization
argument list, which is only properly defined in CLOS terms. In
particular:

Did you read the glossary entry for "initialization argument list"?
It's mainly just a syntactic description, it's not really dependent on
CLOS. Any alternating list of names and values is an initialization
argument list.


** if it's conforming for DEFINE-CONDITION to be a wrapper around
DEFCLASS and for MAKE-CONDITION to call INITIALIZE-INSTANCE (perhaps
via MAKE-INSTANCE), then since INITIALIZE-INSTANCE is required to
signal an error if any initialization arguments are invalid,
MAKE-CONDITION might conformingly signal an error.

** However, the MAKE-CONDITION dictionary entry says "Exceptional
Situations: None", and maybe this takes precedence over the previous
point. If so, MAKE-CONDITION could be construed as implicitly
supplying :ALLOW-OTHER-KEYS T to some MAKE-INSTANCE call.

We don't mention in each function's "Exceptional Situations" section
that it can signal an error if it receives unrecognized keyword
arguments. I think that's mentioned somewhere in the general
description of function calling that the consequences are undefined.


** OTOH, if it's conforming for DEFINE-CONDITION and MAKE-CONDITION to
be implemented without reference to DEFCLASS and standard
instantiation protocol functions, then the CLHS doesn't say anything
about what would make an initialization argument valid for
MAKE-CONDITION, and so it would be conforming not to signal any
error.

Since the spec doesn't define the consequences, the consequences are
undefined if you supply invalid initialization arguments.


(Personally, I think these last 3 points just mean that the CLHS
doesn't specify what MAKE-CONDITION does with unrecognized initargs.)

* The issue
DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY
[3] was supposed to remove the :WRITER and :ACCESSOR slot options from
DEFCLASS. In the dictionary entry for DEFINE-CONDITION, the :WRITER
and :ACCESSOR initargs are present in the Syntax and Arguments section
and the Values section, but not the Description section. The TeX
source for dpans3 has a comment indicating that the :WRITER and
:ACCESSOR descriptions were removed from the Description; was it just
an editing error that they weren't removed elsewhere?

* Relatedly, the :ALLOCATION slot option was removed from the
Description section of the DEFINE-CONDITION dictionary entry, but the
option is present in the Syntax and Arguments section and in the
Values section. I can't find an issue that addresses slot allocation
for conditions, though I could imagine that implementors who wanted
their condition system to be orthogonal to CLOS could have objected to
class allocation for condition slots. Was this another editing error?

Anybody have any insights about these points?

I think the latter two are editing errors.

I thought there was an errata web page somewhere, but I can't find it.

--
Barry Margolin, barmar@xxxxxxxxxxxx
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
.

Relevant Pages

  • CLOS and the condition system in the CLHS
    ... of invalid initialization arguments to MAKE-CONDITION. ... permit a condition system to be implemented with or without CLOS, ... defined by DEFINE-CONDITION are ... the Arguments and Values section of the MAKE-CONDITION ...
    (comp.lang.lisp)
  • Re: CLOS and the condition system in the CLHS
    ... which is only properly defined in CLOS terms. ... Did you read the glossary entry for "initialization argument list"? ... unrecognized keyword arguments in safe code in 3.5.1.4: ... all the CLOS initialization protocol functions' lambda lists include ...
    (comp.lang.lisp)