Before I make a bug report, I thought I would see if as so often happens
I am missing some nuance in the spec in re valid initargs to make-instance.
This fails as expected:
(defclass just-yy ()
((yy :initarg :yy :initform nil)))
(describe (make-instance 'just-yy :xx 'fail))
;;;Error: :XX are invalid initargs to make-instance of class
;;; #<STANDARD-CLASS JUST-YY>. The valid initargs are :YY.
But it now succeeds in AllegroCL 6.2 for Windows after:
(defmethod shared-initialize :after ((self just-yy) slot-names &rest iargs)
(print `(init ,self ,slot-names ,iargs)))
(describe (make-instance 'just-yy :xx 'fail)))
;;;(INIT #<JUST-YY @ #x21d824aa> T (:XX FAIL))
;;;#<JUST-YY @ #x21d824aa> is an instance of #<STANDARD-CLASS JUST-YY>:
;;; The following slots have :INSTANCE allocation:
;;; YY NIL
It still fails under Lispworks Trial.
The spec says the default for &allow-other-keys is nil, so I think we
have a live one. Yes? No?
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
> The spec says the default for &allow-other-keys is nil, so I think we
> have a live one. Yes? No?
Yes, I think Allegro's behavior is non-conformant.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Kenny Tilton <·······@nyc.rr.com> writes:
> Before I make a bug report, I thought I would see if as so often
> happens I am missing some nuance in the spec in re valid initargs to
> make-instance.
>
> This fails as expected:
>
> (defclass just-yy ()
> ((yy :initarg :yy :initform nil)))
> (describe (make-instance 'just-yy :xx 'fail))
>
> ;;;Error: :XX are invalid initargs to make-instance of class
> ;;; #<STANDARD-CLASS JUST-YY>. The valid initargs are :YY.
>
>
> But it now succeeds in AllegroCL 6.2 for Windows after:
>
> (defmethod shared-initialize :after ((self just-yy) slot-names &rest iargs)
> (print `(init ,self ,slot-names ,iargs)))
> (describe (make-instance 'just-yy :xx 'fail)))
>
> ;;;(INIT #<JUST-YY @ #x21d824aa> T (:XX FAIL))
> ;;;#<JUST-YY @ #x21d824aa> is an instance of #<STANDARD-CLASS JUST-YY>:
> ;;; The following slots have :INSTANCE allocation:
> ;;; YY NIL
>
> It still fails under Lispworks Trial.
>
> The spec says the default for &allow-other-keys is nil, so I think we
> have a live one. Yes? No?
No, I think. SHARED-INITIALIZE GF declares &allow-other-keys, and per
7.6.5:
"If the lambda list of any applicable method or of the generic
function definition contains &allow-other-keys, all keyword
arguments are accepted by the generic function."
That, combined with your &rest, argument makes the :xx argument okay.
But I didn't get a lot of sleep last night--dogs jumping in and out of
bed until the wee ours; long story--so I may be confused.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Before I make a bug report, I thought I would see if as so often
>>happens I am missing some nuance in the spec in re valid initargs to
>>make-instance.
>>
>>This fails as expected:
>>
>>(defclass just-yy ()
>> ((yy :initarg :yy :initform nil)))
>>(describe (make-instance 'just-yy :xx 'fail))
>>
>>;;;Error: :XX are invalid initargs to make-instance of class
>>;;; #<STANDARD-CLASS JUST-YY>. The valid initargs are :YY.
>>
>>
>>But it now succeeds in AllegroCL 6.2 for Windows after:
>>
>>(defmethod shared-initialize :after ((self just-yy) slot-names &rest iargs)
>> (print `(init ,self ,slot-names ,iargs)))
>> (describe (make-instance 'just-yy :xx 'fail)))
>>
>>;;;(INIT #<JUST-YY @ #x21d824aa> T (:XX FAIL))
>>;;;#<JUST-YY @ #x21d824aa> is an instance of #<STANDARD-CLASS JUST-YY>:
>>;;; The following slots have :INSTANCE allocation:
>>;;; YY NIL
>>
>>It still fails under Lispworks Trial.
>>
>>The spec says the default for &allow-other-keys is nil, so I think we
>>have a live one. Yes? No?
>
>
> No, I think. SHARED-INITIALIZE GF declares &allow-other-keys
Where?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Peter Seibel wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>Before I make a bug report, I thought I would see if as so often
>>>happens I am missing some nuance in the spec in re valid initargs to
>>>make-instance.
>>>
>>>This fails as expected:
>>>
>>>(defclass just-yy ()
>>> ((yy :initarg :yy :initform nil)))
>>>(describe (make-instance 'just-yy :xx 'fail))
>>>
>>>;;;Error: :XX are invalid initargs to make-instance of class
>>>;;; #<STANDARD-CLASS JUST-YY>. The valid initargs are :YY.
>>>
>>>
>>>But it now succeeds in AllegroCL 6.2 for Windows after:
>>>
>>>(defmethod shared-initialize :after ((self just-yy) slot-names &rest iargs)
>>> (print `(init ,self ,slot-names ,iargs)))
>>> (describe (make-instance 'just-yy :xx 'fail)))
>>>
>>>;;;(INIT #<JUST-YY @ #x21d824aa> T (:XX FAIL))
>>>;;;#<JUST-YY @ #x21d824aa> is an instance of #<STANDARD-CLASS JUST-YY>:
>>>;;; The following slots have :INSTANCE allocation:
>>>;;; YY NIL
>>>
>>>It still fails under Lispworks Trial.
>>>
>>>The spec says the default for &allow-other-keys is nil, so I think we
>>>have a live one. Yes? No?
>> No, I think. SHARED-INITIALIZE GF declares &allow-other-keys
>
> Where?
From the dictionary entry:
Standard Generic Function SHARED-INITIALIZE
Syntax:
shared-initialize instance slot-names &rest initargs &key
&allow-other-keys => instance
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> From the dictionary entry:
>
> Standard Generic Function SHARED-INITIALIZE
>
> Syntax:
>
> shared-initialize instance slot-names &rest initargs &key
> &allow-other-keys => instance
If the declaration of the generic function would count for disabling
validity checks then there would never be any validity checks since the
generic function is always defined.
Section 7.1.2 says this:
"The presence of &allow-other-keys in the lambda list of an applicable
method disables validity checking of initialization arguments. Thus
method inheritance controls the set of valid initialization arguments
that supply arguments to methods."
It only talks about methods here, and the method provided for
standard-object doesn't say &allow-other-keys.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Peter Seibel wrote:
>
>> From the dictionary entry:
>> Standard Generic Function SHARED-INITIALIZE
>> Syntax:
>> shared-initialize instance slot-names &rest initargs &key
>> &allow-other-keys => instance
>
> If the declaration of the generic function would count for disabling
> validity checks then there would never be any validity checks since
> the generic function is always defined.
You're probably right. I was thinking of regular method
invocation--7.1.2 seems to be describing some extra machinery used by
MAKE-INSTANCE, et al. to determine what arguments can be used there.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>The spec says the default for &allow-other-keys is nil, so I think we
>>have a live one. Yes? No?
>
>
> No, I think. SHARED-INITIALIZE GF declares &allow-other-keys, and per
> 7.6.5:
>
> "If the lambda list of any applicable method or of the generic
> function definition contains &allow-other-keys, all keyword
> arguments are accepted by the generic function."
>
> That, combined with your &rest, argument makes the :xx argument okay.
> But I didn't get a lot of sleep last night--dogs jumping in and out of
> bed until the wee ours; long story--so I may be confused.
I do not think the dictionary definition you mentioned later in response
to Pascal amounts to "this is the defgeneric for s/i", based on the fact
that normally make-instance /does/ squawk about bogus initargs and the
spec says elsewhere that &a-o-k specified on a defgeneric form would
rule. It seems to be saying "you can throw this in if you like". And
then the assertion (in the discussion of s/i) that &aok defaults to nil
makes sense.
I'll send this in to Franz, see what they have to say.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film