From: Jim Newton
Subject: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483eadc7$1@news.cadence.com>
Does anyone know what the behavior should be if a generic function has
an around method which does NOT call call-next-method, but there is
no primary method?
It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
signals an error, but allegro calls the around method
(defgeneric foo (x))
(defmethod foo :around (x) 1)
(foo 1)
This returns 1 in allegro, and errors in sbcl. Any opinions
about which is correct behavior?
-jim
From: Ken Tilton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483ebe1e$0$11612$607ed4bc@cv.net>
Jim Newton wrote:
> Does anyone know what the behavior should be if a generic function has
> an around method which does NOT call call-next-method, but there is
> no primary method?
>
> It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
> signals an error, but allegro calls the around method
>
> (defgeneric foo (x))
> (defmethod foo :around (x) 1)
> (foo 1)
>
> This returns 1 in allegro, and errors in sbcl. Any opinions
> about which is correct behavior?
This is Lisp. If I do not call X, I better not get an error about X
being undefined.
my2. kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Daniel Weinreb
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <48429150.9050903@alum.mit.edu>
Ken Tilton wrote:
>
>
> Jim Newton wrote:
>> Does anyone know what the behavior should be if a generic function has
>> an around method which does NOT call call-next-method, but there is
>> no primary method?
>>
>> It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
>> signals an error, but allegro calls the around method
>>
>> (defgeneric foo (x))
>> (defmethod foo :around (x) 1)
>> (foo 1)
>>
>> This returns 1 in allegro, and errors in sbcl. Any opinions
>> about which is correct behavior?
>
> This is Lisp. If I do not call X, I better not get an error about X
> being undefined.
>
> my2. kt
>
But you did call X. You called the generic function foo.
foo is defined. The problem is that the definition is
incomplete/invalid. So this does not break the invariant
that if you do not call X then it's OK for X to be undefined.
From: Ken Tilton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <48429369$0$25022$607ed4bc@cv.net>
Daniel Weinreb wrote:
> Ken Tilton wrote:
>
>>
>>
>> Jim Newton wrote:
>>
>>> Does anyone know what the behavior should be if a generic function has
>>> an around method which does NOT call call-next-method, but there is
>>> no primary method?
>>>
>>> It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
>>> signals an error, but allegro calls the around method
>>>
>>> (defgeneric foo (x))
>>> (defmethod foo :around (x) 1)
>>> (foo 1)
>>>
>>> This returns 1 in allegro, and errors in sbcl. Any opinions
>>> about which is correct behavior?
>>
>>
>> This is Lisp. If I do not call X, I better not get an error about X
>> being undefined.
>>
>> my2. kt
>>
>
> But you did call X. You called the generic function foo.
> foo is defined. The problem is that the definition is
> incomplete/invalid. So this does not break the invariant
> that if you do not call X then it's OK for X to be undefined.
That's like saying I ignored the advice to stay out of the men's room in
New York City's Port Authority bus station because I took a bus from
Port Authority.
:)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Jun 1, 2:17 pm, Ken Tilton <···········@optonline.net> wrote:
> Daniel Weinreb wrote:
> > Ken Tilton wrote:
>
> >> Jim Newton wrote:
>
> >>> Does anyone know what the behavior should be if a generic function has
> >>> an around method which does NOT call call-next-method, but there is
> >>> no primary method?
>
> >>> It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
> >>> signals an error, but allegro calls the around method
>
> >>> (defgeneric foo (x))
> >>> (defmethod foo :around (x) 1)
> >>> (foo 1)
>
> >>> This returns 1 in allegro, and errors in sbcl. Any opinions
> >>> about which is correct behavior?
>
> >> This is Lisp. If I do not call X, I better not get an error about X
> >> being undefined.
>
> >> my2. kt
>
> > But you did call X. You called the generic function foo.
> > foo is defined. The problem is that the definition is
> > incomplete/invalid. So this does not break the invariant
> > that if you do not call X then it's OK for X to be undefined.
>
> That's like saying I ignored the advice to stay out of the men's room in
> New York City's Port Authority bus station because I took a bus from
> Port Authority.
>
> :)
That sounds about right to me. Oh and, yuck.
This aspect of standard-method-combination really sticks out like a
sore thumb in the overall context of CL. The fact that it's a largely
implementor-defined object system bolted on to the language doesn't
normally show through too badly, but here ... wow. From the CLOS
implementor's point of view, where you synthesize the whole effective
method body before starting the invocation, blah blah blah, the error
almost makes sense. But to require this error? For crying out loud,
SBCL signals an error there, as required by the spec, but check out
this behavior, perfectly allowed by the spec:
* (defun foo (x) (if x (list x) (let)))
; in: LAMBDA NIL
; (LET)
;
; caught ERROR:
; error while parsing arguments to special form LET:
; invalid number of elements in
; ()
; to satisfy lambda list
; (SB-C::BINDINGS &BODY SB-C::BODY):
; at least 1 expected, but 0 found
;
; compilation unit finished
; caught 1 ERROR condition
FOO
* (foo t)
(T)
* (foo nil)
debugger invoked on a SB-INT:COMPILED-PROGRAM-ERROR:
Execution of a form compiled with errors.
Form:
(LET)
Compile-time error:
error while parsing arguments to special form LET:
invalid number of elements in
()
to satisfy lambda list
(SB-C::BINDINGS &BODY SB-C::BODY):
at least 1 expected, but 0 found
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
So if my program avoids the erroneous -- even syntactical garbage ! --
branch of this function, I can keep going ; but if I make a "bad" call
to a GF -- even if my around method avoids calling the next-method !
-- I'm required to get an error?
One of these situations reminds me of what I don't like about Haskell
and SML ; the other reminds me of what I like about Smalltalk. I'll
give y'all a hint : it ain't the object system that's making me think
about ST here.
As for why one would want to do either -- do I really need to defend
this in a Lisp newsgroup? No I don't want to move either bit of code
into production. I do want to solve the absolute *minimum* of the
trivial/superficial problems that come up when running my code in an
unexpected environment and still have it run on the paths that it
truly takes. I'll get around to those finally, but in the meantime I'd
like to concentrate on the profound problems. In terms of the overall
philosophy of permitting this sort of work model, *that's* what's
wrong with this bit of the spec.
From: Richard M Kreuter
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <87y75pp4lm.fsf@progn.net>
"Thomas F. Burdick" <········@gmail.com> writes:
>> >> Jim Newton wrote:
>>
>> >>> Does anyone know what the behavior should be if a generic
>> >>> function has an around method which does NOT call
>> >>> call-next-method, but there is no primary method?
> This aspect of standard-method-combination really sticks out like a
> sore thumb in the overall context of CL. The fact that it's a largely
> implementor-defined object system bolted on to the language doesn't
> normally show through too badly, but here ... wow. From the CLOS
> implementor's point of view, where you synthesize the whole effective
> method body before starting the invocation, blah blah blah, the error
> almost makes sense. But to require this error?
I like the requirement that there be at least one applicable primary
method. It can be hard to remember all of what a function does when
the function's definition is distributed around a codebase, and if the
(entire) function will have side-effects or take locks or whathaveyou,
ISTM that an error before any methods are executed means that you
don't need to concern yourself with undoing the consequences of any
already-fired methods. And if you want to risk a NO-NEXT-METHOD
mid-way through generic function exeuction rather than take an error
during effective method computation, you can code your methods as
primary methods that invoke CALL-NEXT-METHOD. (Or, as mentioned,
write a more-forgiving variant of standard method combination.)
--
RmK
From: Thomas A. Russ
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <ymive0wddwf.fsf@blackcat.isi.edu>
Jim Newton <·····@cadence.com> writes:
> Does anyone know what the behavior should be if a generic function has
> an around method which does NOT call call-next-method, but there is
> no primary method?
...
> (defgeneric foo (x))
> (defmethod foo :around (x) 1)
> (foo 1)
>
> This returns 1 in allegro, and errors in sbcl. Any opinions
> about which is correct behavior?
From the other posts, it appears that signaling the error is correct
behavior.
It would be pretty easy to get something like the Allegro behavior, but
in an ANSI-compliant way by just adding a default primary method that
signals an error:
(defmethod foo (x) (error "Shouldn't get here."))
This would allow the around method to work as long as it didn't try to
actually get to the primary method.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Jim Newton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483fa9d0$1@news.cadence.com>
the problem with defining this "stand-in" method would be that now
NEXT-METHOD-P would return TRUE. which would be even more misleading.
-jim
Thomas A. Russ wrote:
> Jim Newton <·····@cadence.com> writes:
>
>
>>Does anyone know what the behavior should be if a generic function has
>>an around method which does NOT call call-next-method, but there is
>>no primary method?
>
> ...
>
>>(defgeneric foo (x))
>>(defmethod foo :around (x) 1)
>>(foo 1)
>>
>>This returns 1 in allegro, and errors in sbcl. Any opinions
>>about which is correct behavior?
>
>
> From the other posts, it appears that signaling the error is correct
> behavior.
>
> It would be pretty easy to get something like the Allegro behavior, but
> in an ANSI-compliant way by just adding a default primary method that
> signals an error:
>
> (defmethod foo (x) (error "Shouldn't get here."))
>
> This would allow the around method to work as long as it didn't try to
> actually get to the primary method.
>
>
--
+------------------------------------------------------------------------+
| Jim E. Newton (·····@cadence.com) desk +49-(0)89-4563-1918 |
| Methodology Services Europe fax +49-(0)89-4563-1819 |
| Cadence Design Systems GmbH Munich Germany |
| |
| If you won't do it in the rain, you won't do it. |
+------------------------------------------------------------------------+
From: Pascal Costanza
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <6a9pi7F2u4ue8U1@mid.individual.net>
Jim Newton wrote:
> the problem with defining this "stand-in" method would be that now
> NEXT-METHOD-P would return TRUE. which would be even more misleading.
The role of :before, :after and :around methods is to augment the
behavior of a generic function, and it is assumed that the primary
methods do the main job. So for example, :before methods may check
preconditions, :after methods may inform other parties that something
important has happened, :around methods may cache results to improve
performance, and so on. [1] If an :around method "takes over" and
doesn't invoke any primary methods anymore, that may not work well with
methods provided by other third-party client code, because you're
essentially "abusing" the role of :around methods.
That's always the main point with generic functions, that several
parties can contribute to the same operation, but in order to make this
work well, the different parties have to rely on some conventions. So I
think it's a reasonable design choice to issue an error if there is no
primary method for an invocation, because this provides a certain level
of guaranty that the method definitions are "sane."
And due to define-method-combination, this is not limiting at all,
because you can always define your own rules for what should happen
under what circumstances. This should even work in simple applications.
If you're the only one contributing to a generic function, then it may
be better to use plain functions, because this gives you more control
over what happens.
Pascal
[1] You could characterize such things as "non-functional concerns," but
I don't like that term too much, so I try to avoid it.
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Edi Weitz
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <uve0xi68b.fsf@agharta.de>
On Thu, 29 May 2008 15:21:10 +0200, Jim Newton <·····@cadence.com> wrote:
> Does anyone know what the behavior should be if a generic function
> has an around method which does NOT call call-next-method, but there
> is no primary method?
>
> It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
> signals an error, but allegro calls the around method
>
> (defgeneric foo (x))
> (defmethod foo :around (x) 1)
> (foo 1)
>
> This returns 1 in allegro, and errors in sbcl. Any opinions about
> which is correct behavior?
7.6.6.2:
"In standard method combination, if there is an applicable method
but no applicable primary method, an error is signaled."
Looks like AllegroCL is wrong. FWIW, LispWorks and ClozureCL also
signal an error here.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Ken Tilton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483ed5ed$0$15189$607ed4bc@cv.net>
Edi Weitz wrote:
> On Thu, 29 May 2008 15:21:10 +0200, Jim Newton <·····@cadence.com> wrote:
>
>
>>Does anyone know what the behavior should be if a generic function
>>has an around method which does NOT call call-next-method, but there
>>is no primary method?
>>
>>It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
>>signals an error, but allegro calls the around method
>>
>>(defgeneric foo (x))
>>(defmethod foo :around (x) 1)
>>(foo 1)
>>
>>This returns 1 in allegro, and errors in sbcl. Any opinions about
>>which is correct behavior?
>
>
> 7.6.6.2:
>
> "In standard method combination, if there is an applicable method
> but no applicable primary method, an error is signaled."
>
> Looks like AllegroCL is wrong. FWIW, LispWorks and ClozureCL also
> signal an error here.
This has been my experience every time in porting from ACL to LW: LW was
compliant, ACL was easier to live with.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Edi Weitz
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <u4p8gj3u3.fsf@agharta.de>
On Thu, 29 May 2008 12:11:53 -0400, Ken Tilton <···········@optonline.net> wrote:
> This has been my experience every time in porting from ACL to LW: LW
> was compliant, ACL was easier to live with.
Yep, let's get rid of the fucking standard once and for all. Who
needs it anyway?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Ken Tilton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483f131a$0$25066$607ed4bc@cv.net>
Edi Weitz wrote:
> On Thu, 29 May 2008 12:11:53 -0400, Ken Tilton <···········@optonline.net> wrote:
>
>
>>This has been my experience every time in porting from ACL to LW: LW
>>was compliant, ACL was easier to live with.
ps. I almost followed up with except in re developing a portable
library. But as I said, a year's worth of kennycode takes only a day or
two to get compiled under LW, and most of that stems from my ignorance
of their astonishingly great IDE.
>
>
> Yep, let's get rid of the fucking standard once and for all. Who
> needs it anyway?
Exactly. Then there would be room for experimentation and different
implementations could add interesting new extensions... whoa. What is
that deja vu feeling I am having?
My understanding from Franz is that they love Mr. Dietz's compliance
test (well, in at least one case they invoked it when asked why) but
neither are they in the mood to break a lot of customer code (having
invoked that at least once, IIRC).
In this case it looks like the standard is just plain wrong if one wants
to follow The One True Lisp Way and trust us to know what we are doing,
so compliance here would be compliance for it's own sake.
I must need a drink, that last word looks like a Japanese malt brew.
kzo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Pascal Costanza
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <6a8is4F36f2glU1@mid.individual.net>
Ken Tilton wrote:
>
>
> Edi Weitz wrote:
>> On Thu, 29 May 2008 12:11:53 -0400, Ken Tilton
>> <···········@optonline.net> wrote:
>>
>>
>>> This has been my experience every time in porting from ACL to LW: LW
>>> was compliant, ACL was easier to live with.
>
> ps. I almost followed up with except in re developing a portable
> library. But as I said, a year's worth of kennycode takes only a day or
> two to get compiled under LW, and most of that stems from my ignorance
> of their astonishingly great IDE.
>
>>
>>
>> Yep, let's get rid of the fucking standard once and for all. Who
>> needs it anyway?
>
> Exactly. Then there would be room for experimentation and different
> implementations could add interesting new extensions... whoa. What is
> that deja vu feeling I am having?
>
> My understanding from Franz is that they love Mr. Dietz's compliance
> test (well, in at least one case they invoked it when asked why) but
> neither are they in the mood to break a lot of customer code (having
> invoked that at least once, IIRC).
>
> In this case it looks like the standard is just plain wrong if one wants
> to follow The One True Lisp Way and trust us to know what we are doing,
> so compliance here would be compliance for it's own sake.
What part of define-method-combination is it that you don't get?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483f377d$0$25043$607ed4bc@cv.net>
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Edi Weitz wrote:
>>
>>> On Thu, 29 May 2008 12:11:53 -0400, Ken Tilton
>>> <···········@optonline.net> wrote:
>>>
>>>
>>>> This has been my experience every time in porting from ACL to LW: LW
>>>> was compliant, ACL was easier to live with.
>>
>>
>> ps. I almost followed up with except in re developing a portable
>> library. But as I said, a year's worth of kennycode takes only a day
>> or two to get compiled under LW, and most of that stems from my
>> ignorance of their astonishingly great IDE.
>>
>>>
>>>
>>> Yep, let's get rid of the fucking standard once and for all. Who
>>> needs it anyway?
>>
>>
>> Exactly. Then there would be room for experimentation and different
>> implementations could add interesting new extensions... whoa. What is
>> that deja vu feeling I am having?
>>
>> My understanding from Franz is that they love Mr. Dietz's compliance
>> test (well, in at least one case they invoked it when asked why) but
>> neither are they in the mood to break a lot of customer code (having
>> invoked that at least once, IIRC).
>>
>> In this case it looks like the standard is just plain wrong if one
>> wants to follow The One True Lisp Way and trust us to know what we are
>> doing, so compliance here would be compliance for it's own sake.
>
>
> What part of define-method-combination is it that you don't get?
Still coming up to speed on Lisp after all these years? Tsk, tsk. Here
is the condensed version: It's like having a missing function: if I do
not call it, it is nobody's business if I coded a call to it.
hth,kzo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Pascal Costanza
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <6a9nfqF35l7dcU1@mid.individual.net>
Ken Tilton wrote:
> Still coming up to speed on Lisp after all these years?
Speak for yourself.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483f3c24$0$15180$607ed4bc@cv.net>
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Edi Weitz wrote:
>>
>>> On Thu, 29 May 2008 12:11:53 -0400, Ken Tilton
>>> <···········@optonline.net> wrote:
>>>
>>>
>>>> This has been my experience every time in porting from ACL to LW: LW
>>>> was compliant, ACL was easier to live with.
>>
>>
>> ps. I almost followed up with except in re developing a portable
>> library. But as I said, a year's worth of kennycode takes only a day
>> or two to get compiled under LW, and most of that stems from my
>> ignorance of their astonishingly great IDE.
>>
>>>
>>>
>>> Yep, let's get rid of the fucking standard once and for all. Who
>>> needs it anyway?
>>
>>
>> Exactly. Then there would be room for experimentation and different
>> implementations could add interesting new extensions... whoa. What is
>> that deja vu feeling I am having?
>>
>> My understanding from Franz is that they love Mr. Dietz's compliance
>> test (well, in at least one case they invoked it when asked why) but
>> neither are they in the mood to break a lot of customer code (having
>> invoked that at least once, IIRC).
>>
>> In this case it looks like the standard is just plain wrong if one
>> wants to follow The One True Lisp Way and trust us to know what we are
>> doing, so compliance here would be compliance for it's own sake.
>
>
> What part of define-method-combination is it that you don't get?
btw, dying is easy, comedy is hard. "...is it that you don't get" is a
comedy killer, way too many words for starters. I was astonished and
delighted to listen to a long craft interview of Jack Benny in which he
talked about his writers and him sitting around trying to eliminate
words from jokes even for his TV sitcom dialogue, never mind his
stand-up jokes.
You could go with "What part...don't you get?", but one is supposed to
practice for years before deviating from the master's example. The
preferred form then must be: "What part...do you not understand?"
"get" is too overloaded and indeed the connotation "understand" is a
less likely usage, way too much work for the listener's cortex to
resolve, a metaphor instead of straight language. We don't want the
listeners cortex bogged down in simply understanding the words, we want
them flowing along smoothly and effortlessly to have them going as fast
as possible when we trip them.
Another thing. The humor comes from asking "what part" but the punch
comes from the word "not". When this line is spoken, likewise that is
where the emphasis falls. You have contracted the punch line. Oops.
hth,kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Pascal Costanza
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <6a9nkcF35l7dcU2@mid.individual.net>
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>
>>>
>>>
>>> Edi Weitz wrote:
>>>
>>>> On Thu, 29 May 2008 12:11:53 -0400, Ken Tilton
>>>> <···········@optonline.net> wrote:
>>>>
>>>>
>>>>> This has been my experience every time in porting from ACL to LW: LW
>>>>> was compliant, ACL was easier to live with.
>>>
>>>
>>> ps. I almost followed up with except in re developing a portable
>>> library. But as I said, a year's worth of kennycode takes only a day
>>> or two to get compiled under LW, and most of that stems from my
>>> ignorance of their astonishingly great IDE.
>>>
>>>>
>>>>
>>>> Yep, let's get rid of the fucking standard once and for all. Who
>>>> needs it anyway?
>>>
>>>
>>> Exactly. Then there would be room for experimentation and different
>>> implementations could add interesting new extensions... whoa. What is
>>> that deja vu feeling I am having?
>>>
>>> My understanding from Franz is that they love Mr. Dietz's compliance
>>> test (well, in at least one case they invoked it when asked why) but
>>> neither are they in the mood to break a lot of customer code (having
>>> invoked that at least once, IIRC).
>>>
>>> In this case it looks like the standard is just plain wrong if one
>>> wants to follow The One True Lisp Way and trust us to know what we
>>> are doing, so compliance here would be compliance for it's own sake.
>>
>>
>> What part of define-method-combination is it that you don't get?
>
> btw, dying is easy, comedy is hard.
You're trying to change topic again. define-method-combination solves
the problem you seem to have.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 30 May, 08:11, Pascal Costanza <····@p-cos.net> wrote:
> You're trying to change topic again. define-method-combination solves
> the problem you seem to have.
If I wanted a language where there was only one solution to any
problem... Well, no. I'd never want a language like that.
From: Pascal Costanza
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <6a9tjvF3678jlU1@mid.individual.net>
···········@c4l.co.uk wrote:
> On 30 May, 08:11, Pascal Costanza <····@p-cos.net> wrote:
>> You're trying to change topic again. define-method-combination solves
>> the problem you seem to have.
>
> If I wanted a language where there was only one solution to any
> problem... Well, no. I'd never want a language like that.
:)
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483fef6e$0$25039$607ed4bc@cv.net>
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>>
>>>>
>>>> Edi Weitz wrote:
>>>>
>>>>> On Thu, 29 May 2008 12:11:53 -0400, Ken Tilton
>>>>> <···········@optonline.net> wrote:
>>>>>
>>>>>
>>>>>> This has been my experience every time in porting from ACL to LW: LW
>>>>>> was compliant, ACL was easier to live with.
>>>>
>>>>
>>>>
>>>> ps. I almost followed up with except in re developing a portable
>>>> library. But as I said, a year's worth of kennycode takes only a day
>>>> or two to get compiled under LW, and most of that stems from my
>>>> ignorance of their astonishingly great IDE.
>>>>
>>>>>
>>>>>
>>>>> Yep, let's get rid of the fucking standard once and for all. Who
>>>>> needs it anyway?
>>>>
>>>>
>>>>
>>>> Exactly. Then there would be room for experimentation and different
>>>> implementations could add interesting new extensions... whoa. What
>>>> is that deja vu feeling I am having?
>>>>
>>>> My understanding from Franz is that they love Mr. Dietz's compliance
>>>> test (well, in at least one case they invoked it when asked why) but
>>>> neither are they in the mood to break a lot of customer code (having
>>>> invoked that at least once, IIRC).
>>>>
>>>> In this case it looks like the standard is just plain wrong if one
>>>> wants to follow The One True Lisp Way and trust us to know what we
>>>> are doing, so compliance here would be compliance for it's own sake.
>>>
>>>
>>>
>>> What part of define-method-combination is it that you don't get?
>>
>>
>> btw, dying is easy, comedy is hard.
>
>
> You're trying to change topic again.
I was just trying to save you from Tfb the Elder complaining about you
doing such a poor imitation of me.
> define-method-combination solves
> the problem you seem to have.
>
I just checked the CLHS on d-m-c and the entry is longer than the Scheme
standard. No thanks.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Pascal Costanza
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <6aa9pjF36d7vtU1@mid.individual.net>
Ken Tilton wrote:
>
> I just checked the CLHS on d-m-c and the entry is longer than the Scheme
> standard. No thanks.
>
I'm not surprised.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jim Newton
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <483ec6d2@news.cadence.com>
7.6.6.2 says that an error is signaled but it does not say WHEN
it is signaled. It clearly should not be signaled at definition
time, because you might define the around method before the primary
method. or am i missing something?
Edi Weitz wrote:
> On Thu, 29 May 2008 15:21:10 +0200, Jim Newton <·····@cadence.com> wrote:
>
>
>>Does anyone know what the behavior should be if a generic function
>>has an around method which does NOT call call-next-method, but there
>>is no primary method?
>>
>>It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
>>signals an error, but allegro calls the around method
>>
>>(defgeneric foo (x))
>>(defmethod foo :around (x) 1)
>>(foo 1)
>>
>>This returns 1 in allegro, and errors in sbcl. Any opinions about
>>which is correct behavior?
>
>
> 7.6.6.2:
>
> "In standard method combination, if there is an applicable method
> but no applicable primary method, an error is signaled."
>
> Looks like AllegroCL is wrong. FWIW, LispWorks and ClozureCL also
> signal an error here.
>
> Edi.
>
From: Pascal Costanza
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <6a80cnF35817jU1@mid.individual.net>
> Edi Weitz wrote:
>> On Thu, 29 May 2008 15:21:10 +0200, Jim Newton <·····@cadence.com>
wrote:
>>
>>
>>> Does anyone know what the behavior should be if a generic function
>>> has an around method which does NOT call call-next-method, but there
>>> is no primary method?
>>>
>>> It seems that sbcl calls SB-PCL::NO-PRIMARY-METHOD which normally
>>> signals an error, but allegro calls the around method
>>>
>>> (defgeneric foo (x))
>>> (defmethod foo :around (x) 1)
>>> (foo 1)
>>>
>>> This returns 1 in allegro, and errors in sbcl. Any opinions about
>>> which is correct behavior?
>>
>>
>> 7.6.6.2:
>>
>> "In standard method combination, if there is an applicable method
>> but no applicable primary method, an error is signaled."
>>
>> Looks like AllegroCL is wrong. FWIW, LispWorks and ClozureCL also
>> signal an error here.
>>
Jim Newton wrote:
> 7.6.6.2 says that an error is signaled but it does not say WHEN
> it is signaled. It clearly should not be signaled at definition
> time, because you might define the around method before the primary
> method. or am i missing something?
7.6.6.2 describes the standard method combination. Method combination is
a well-defined phase of generic function invocation, which consists of
(a) selecting the applicable methods, (b) combining them into an
effective method, and (c) invoking the effective method. This means that
the error is signaled on generic function invocation in step (b).
The error can be avoided by implementing one's own version of the
standard method combination. See the examples section in the
specification for define-method-combination. There, the 'standard method
combination is redefined. Just remove the :required t option, and you
won't get the error. (You are actually not allowed to redefine the
'standard method combination, so you have to choose a different name for
your method combination.)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Edi Weitz
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <u8wxsj3wa.fsf@agharta.de>
On Thu, 29 May 2008 17:08:01 +0200, Jim Newton <·····@cadence.com> wrote:
> 7.6.6.2 says that an error is signaled but it does not say WHEN it
> is signaled. It clearly should not be signaled at definition time,
> because you might define the around method before the primary
> method. or am i missing something?
In your original posting you didn't say that this happens at
definition time. Does it? That would surprise me.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Daniel Weinreb
Subject: Re: Allegro and Sbcl disagree on no-primary-method behavior
Date:
Message-ID: <48429096.8070005@alum.mit.edu>
Edi Weitz wrote:
> On Thu, 29 May 2008 17:08:01 +0200, Jim Newton <·····@cadence.com> wrote:
>
>> 7.6.6.2 says that an error is signaled but it does not say WHEN it
>> is signaled. It clearly should not be signaled at definition time,
>> because you might define the around method before the primary
>> method. or am i missing something?
>
> In your original posting you didn't say that this happens at
> definition time. Does it? That would surprise me.
>
> Edi.
>
I don't see how it could possibly happen at definition time.
The fact that there is no primary method cannot be determined
until runtime; you never know when someone will come along
and define it.