From: Richard M Kreuter
Subject: CLOS and the condition system in the CLHS
Date:
Message-ID: <87ljw5j559.fsf@progn.net>
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:
** 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.
** 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.
(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?
--
RmK
[1] http://xach.livejournal.com/196268.html
[2] http://www.lispworks.com/documentation/HyperSpec/Issues/iss048_w.htm
[3] http://www.lispworks.com/documentation/HyperSpec/Issues/iss102.htm
In article <··············@progn.net>,
Richard M Kreuter <·······@progn.net> 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, ······@alum.mit.edu
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 ***
On Oct 30, 6:32 pm, Barry Margolin <······@alum.mit.edu> wrote:
> I thought there was an errata web page somewhere, but I can't find it.
Do you mean this?
http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
-- Scott
In article
<····································@e38g2000prn.googlegroups.com>,
Scott Burson <········@gmail.com> wrote:
> On Oct 30, 6:32�pm, Barry Margolin <······@alum.mit.edu> wrote:
> > I thought there was an errata web page somewhere, but I can't find it.
>
> Do you mean this?
>
> http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
Yeah. I used "errata" in my google search, but that word doesn't appear
on the page.
--
Barry Margolin, ······@alum.mit.edu
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 ***
Barry Margolin <······@alum.mit.edu> writes:
> In article
> <····································@e38g2000prn.googlegroups.com>,
> Scott Burson <········@gmail.com> wrote:
>
>> On Oct 30, 6:32�pm, Barry Margolin <······@alum.mit.edu> wrote:
>> > I thought there was an errata web page somewhere, but I can't find it.
>>
>> Do you mean this?
>>
>> http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
>
> Yeah. I used "errata" in my google search, but that word doesn't appear
> on the page.
'T's because we don't have errata in the ANS; that's the way you guys
set it up :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450, Oakland, Ca. 94607
From: Richard M Kreuter
Subject: Re: CLOS and the condition system in the CLHS
Date:
Message-ID: <87d4hgiqq2.fsf@progn.net>
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@progn.net>,
> Richard M Kreuter <·······@progn.net> 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