Re: CLOS and the condition system in the CLHS

Barry Margolin <barmar@xxxxxxxxxxxx> writes:
In article <87ljw5j559.fsf@xxxxxxxxx>,
Richard M Kreuter <kreuter@xxxxxxxxx> wrote:

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

The glossary entry reads:

| initialization argument list n.
| a property list of initialization argument names and values used
| in the protocol for initializing and reinitializing instances of
| classes. See Section 7.1 (Object Creation and Initialization).

By my reading, this might mean that the difference between a property
list (definition 1) in general and an initialization argument list is
that the latter is actually used in the initialization protocol, which
is a distinct concept in CLOS (see below).

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

First, the standard does specify the consequences of supplying
unrecognized keyword arguments in safe code in 3.5.1.4: a PROGRAM-ERROR
must be signaled. However, the initialization argument list to CLOS
initialization protocol functions are handled according to rules
different from those for function keyword arguments. In particular:

* all the CLOS initialization protocol functions' lambda lists include
&ALLOW-OTHER-KEYS, and so keyword argument checking per se doesn't
apply to these arguments.

* 7.1 specifies the processing of initialization argument lists in
detail, and it's different from the rules for keyword argument lists.
For example, whereas 3.5.1.4 says the consequences are undefined when
an unrecognized keyword is supplied to a function and that in unsafe
code, the CLOS initialization functions make no distinction between
safe and unsafe code, suggesting that signaling an error is always
mandatory.

While I recognize that section 7.1 was concocted so that initialization
arguments to MAKE-INSTANCE et al. looked as though they worked like
function keyword arguments, it isn't formally correct to suppose a
priori that the two must or may be handled identically.

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

While this is false for initialization argument lists supplied to CLOS
initialization protocol (where the spec defines the consequences in all
cases), it could be true of the SLOT-INITITIALIZTIONS to MAKE-CONDITION,
unless you interpret the dictionary entry to mean that the
SLOT-INITIALIZATIONS must be processed according to CLOS rules, which is
the point I'm asking about.

--
Richard
.

Relevant Pages

  • Ctor initialization lists: three details beyond the FAQ-lite
    ... 'calling' the base constructor from there, ... Does this mean that it's a small advantage of the initialization ... to use the values of BASE class members to initialize DERIVED ... I know the initialization lists do not support the syntax ...
    (comp.lang.cpp)
  • Re: Frame buffers and early i2c
    ... I wanted to get i2c developers plus frame buffer and other i2c client ... Crossposting to more then 2 lists seemed wrong. ... and avery maintainer has different preferences. ... available during driver initialization. ...
    (Linux-Kernel)
  • Re: Frame buffers and early i2c
    ... And have two seperate threads of communication??? ... and avery maintainer has different preferences. ... We have a hundred of dedicated mailing lists for a reason. ... available during driver initialization. ...
    (Linux-Kernel)
  • overriding setting
    ... contained lists to the same lenght. ... initialization, typebecomes, and so I get the ... A possible solution could be to create a container class, ... In this case I should refer to Container.myFirstList, ...
    (comp.lang.python)
  • Re: warn about implicit SAVE?
    ... ...How would a new keyword make us repeat a 25 year old battle? ... it by using the initialization according to the rules of the language, ... values in a loop. ... If you initialize it in the declarations to be ...
    (comp.lang.fortran)