Hi,
it may be a quirk of CMUCL, but I have some doubts after reading the
Hyperspec on ENSURE-GENERIC-FUNCTION.
Suppose I do
(defmethod ZUT ((x number) (y string)) (do-stuff x y))
(define-method-combination standard-extended ()
((extra (:extra)))
....)
(ensure-generic-function 'ZUT :method-combination 'standard-extra)
At this point CMUCL barfs on PCL::FIND-METHOD-COMBINATION.
It would almost seem that ENSURE-GENERIC-FUNCTION requires a
method combination object, and not only its (symbol'ic) name.
Is it this the real problem? (Yes! I want to change the method
combination at run time; don't ask me why :) ).
Any help will be appreciated.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>,
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>it may be a quirk of CMUCL, but I have some doubts after reading the
>Hyperspec on ENSURE-GENERIC-FUNCTION.
>
>Suppose I do
>
> (defmethod ZUT ((x number) (y string)) (do-stuff x y))
>
> (define-method-combination standard-extended ()
> ((extra (:extra)))
> ....)
>
> (ensure-generic-function 'ZUT :method-combination 'standard-extra)
>
>At this point CMUCL barfs on PCL::FIND-METHOD-COMBINATION.
You defined STANDARD-EXTENDED, but then said to use STANDARD-EXTRA. Is the
STANDARD-EXTRA method combination really defined?
>It would almost seem that ENSURE-GENERIC-FUNCTION requires a
>method combination object, and not only its (symbol'ic) name.
That's precisely what the Hyperspec says:
Method-combination -- method combination object.
Where do you see it saying that a method combination name can be used?
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@bbnplanet.com> writes:
> In article <··············@copernico.parades.rm.cnr.it>,
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> >it may be a quirk of CMUCL, but I have some doubts after reading the
> >Hyperspec on ENSURE-GENERIC-FUNCTION.
> >
> >Suppose I do
> >
> > (defmethod ZUT ((x number) (y string)) (do-stuff x y))
> >
> > (define-method-combination standard-extended ()
> > ((extra (:extra)))
> > ....)
> >
> > (ensure-generic-function 'ZUT :method-combination 'standard-extra)
> >
> >At this point CMUCL barfs on PCL::FIND-METHOD-COMBINATION.
>
> You defined STANDARD-EXTENDED, but then said to use STANDARD-EXTRA. Is the
> STANDARD-EXTRA method combination really defined?
I was just cut'n'pasting from some more convoluted
code. Sorry. And yes. Everything is defined. Use STANDARD-EXTRA or
STANDARD-EXTENDED as you please.
> >It would almost seem that ENSURE-GENERIC-FUNCTION requires a
> >method combination object, and not only its (symbol'ic) name.
>
> That's precisely what the Hyperspec says:
>
> Method-combination -- method combination object.
>
> Where do you see it saying that a method combination name can be
> >used?
Nowhere. Now, given a method combination name, how do I get to the
method combination object? There is no FIND-METHOD-COMBINATION (alas,
it is there - unexported - in the PCL package). Please note that I am
using CMUCL right now, and so, this may be a quirk/bug of this
implementation. The DEFINE-METHOD-COMBINATION expands into a
PCL::LOAD-LONG-DEFCOMBIN.
If I try to
(find-class 'standard-extra)
I get a "Class not yet defined" error (which I have not figured out
whether it is a PCL or a CMUCL CLOS error).
Please don't tell me I need the MOP. If I do, then the spec of
ENSURE-GENERIC-FUNCTION may be bogus.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* Marco Antoniotti wrote:
> Nowhere. Now, given a method combination name, how do I get to the
> method combination object? There is no FIND-METHOD-COMBINATION (alas,
> it is there - unexported - in the PCL package). Please note that I am
> using CMUCL right now, and so, this may be a quirk/bug of this
> implementation. The DEFINE-METHOD-COMBINATION expands into a
> PCL::LOAD-LONG-DEFCOMBIN.
FIND-METHOD-COMBINATION is in the MOP described in AMOP.
> Please don't tell me I need the MOP. If I do, then the spec of
> ENSURE-GENERIC-FUNCTION may be bogus.
Yes you do. This is one of the places where the border between what
is in the standard and what is not is really ragged. Its `obvious ' I
think that you want to have some of the functional layer that must
things like DEFMETHOD & DEFCLASS, but it's really unclear to me why
this particular bit made it in (or half in, anyway) while others got
left out. Unfortunately, as far as I can see, it's very hard to add
them in without contaging yourself with the (or a) entire MOP.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> * Marco Antoniotti wrote:
>
> > Nowhere. Now, given a method combination name, how do I get to the
> > method combination object? There is no FIND-METHOD-COMBINATION (alas,
> > it is there - unexported - in the PCL package). Please note that I am
> > using CMUCL right now, and so, this may be a quirk/bug of this
> > implementation. The DEFINE-METHOD-COMBINATION expands into a
> > PCL::LOAD-LONG-DEFCOMBIN.
>
> FIND-METHOD-COMBINATION is in the MOP described in AMOP.
I feared so.
>
> > Please don't tell me I need the MOP. If I do, then the spec of
> > ENSURE-GENERIC-FUNCTION may be bogus.
>
> Yes you do. This is one of the places where the border between what
> is in the standard and what is not is really ragged. Its `obvious ' I
> think that you want to have some of the functional layer that must
> things like DEFMETHOD & DEFCLASS, but it's really unclear to me why
> this particular bit made it in (or half in, anyway) while others got
> left out. Unfortunately, as far as I can see, it's very hard to add
> them in without contaging yourself with the (or a) entire MOP.
I will not discuss whether you need to bring in the full MOP or not.
I just want to point out that the Hyperpsec for
ENSURE-GENERIC-FUNCTION requires a METHOD-COMBINATION *object* to be
passes as an argument to the :method-combination keyword.
Now, DEFGENERIC allows a METHOD-COMBINATION *name* to be declared in
its :method-combination option.
Since you do not have a way to retrieve a METHOD-COMBINATION object
in ANSI CL, the spec of ENSURE-GENERIC-FUNCTION seems inconsistent.
A quick solution would be to change the spec of
ENSURE-GENERIC-FUNCTION to take a METHOD-COMBINATION *name* for
the :method-combination argument.
I have not thought what other undesirable consequences this may have.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando Mato Mira
Subject: Re: Changing the Method Combination
Date:
Message-ID: <377CB4FC.5670525@iname.com>
Marco Antoniotti wrote:
> A quick solution would be to change the spec of
> ENSURE-GENERIC-FUNCTION to take a METHOD-COMBINATION *name* for
> the :method-combination argument.
No.
Fernando Mato Mira <········@iname.com> writes:
> Marco Antoniotti wrote:
>
> > A quick solution would be to change the spec of
> > ENSURE-GENERIC-FUNCTION to take a METHOD-COMBINATION *name* for
> > the :method-combination argument.
>
> No.
As a matter of fact I am not sure that his would be a good idea,
however, would you explain why?
BTW. It turns out that DEFINE-METHOD-COMBINATION seems to return the
method object. Though kind of ugly I can now do
(setf the-mc (define-method-combination mc ...))
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando Mato Mira
Subject: Re: Changing the Method Combination
Date:
Message-ID: <3780CA7E.DF47D01D@iname.com>
Marco Antoniotti wrote:
> Fernando Mato Mira <········@iname.com> writes:
>
> > Marco Antoniotti wrote:
> >
> > > A quick solution would be to change the spec of
> > > ENSURE-GENERIC-FUNCTION to take a METHOD-COMBINATION *name* for
> > > the :method-combination argument.
> >
> > No.
>
> As a matter of fact I am not sure that his would be a good idea,
> however, would you explain why?
The True Way of the MOP, it is not ;-)
i.e., if you look at the ENSURE layer below the macros, they take
metaobjects, not names as arguments.
This is good. The MOP should be agnostic of whether you have specialized
namespaces (classes, mt combinations), which are actually pretty ugly,
instead of binding variables (you could define your own FIND-CLASS and
the corresponding define-class on top of DEFCLASS).
As things are now, I don't see any way of GCing classes. And for systems
that evolve
and must never stop running, that is important.
From: Fernando Mato Mira
Subject: Class names (was: Changing the Method Combination)
Date:
Message-ID: <3781FE10.8789B4EE@iname.com>
Fernando Mato Mira wrote:
> i.e., if you look at the ENSURE layer below the macros, they take
> metaobjects, not names as arguments.
Someone may say ENSURE-GENERIC-FUNCTION is not part of
the MOP, as it is in ANSI, but then, why isn't ENSURE-CLASS there, too, for
example?
> As things are now, I don't see any way of GCing classes. And for systems
from FIND-CLASS:
The class associated with a particular symbol can be changed by using setf
with find-class; or, if the new class given to setf is nil, the class
association is removed (but the class object itself is not affected).
What is `not affected' supposed to mean? That it CAN'T be GCed?
More importantly, what about methods specialized using that name? Do they
apply now to the old, the new,
or both classes?
Time to go fishing..
From: Fernando Mato Mira
Subject: Re: Class names (was: Changing the Method Combination)
Date:
Message-ID: <3783566E.9C29ADAA@iname.com>
Fernando Mato Mira wrote:
> from FIND-CLASS:
>
> The class associated with a particular symbol can be changed by using setf
> with find-class; or, if the new class given to setf is nil, the class
> association is removed (but the class object itself is not affected).
> More importantly, what about methods specialized using that name? Do they
> apply now to the old, the new,
> or both classes?
If the old methods apply to the new class, that looks like half of
ENSURE-CLASS' redefinition work,
which might imply that the new class should be of the same metaclass.
Probably they should only apply to the old, and you should just live within the
constraints of ENSURE-CLASS, if you want to preserve your methods. You could
CHANGE-CLASS on
all instances before, if you wanted to keep them around, but not have them
belong to the new class.
Fernando Mato Mira <········@iname.com> writes:
> from [ANS] FIND-CLASS:
> The class associated with a particular symbol can be changed by using setf
> with find-class; or, if the new class given to setf is nil, the class
> association is removed (but the class object itself is not affected).
>
> What is `not affected' supposed to mean? That it CAN'T be GCed?
No, just that CLASS-NAME still returns the old name, although lookup
using FIND-CLASS won't find the class anymore.
> More importantly, what about methods specialized using that name? Do they
> apply now to the old, the new, or both classes?
There's nothing in the standard that describes when the lookup
happens, and the CL default is at run time. Even the compiler can't
rely on the class definition staying the same (section 3.2.2.3) --
although that should probably be fixed. In practice, you'd better
reload the methods, if you want to be sure they apply to the new
class. Even more practical, just don't do that.
--
Pekka P. Pirinen Harlequin Group plc (but not for long)
I have yet to see any problem, however complicated, which,
when you looked at it in the right way, did not become still
more complicated. - Poul Anderson
From: Tim Bradshaw
Subject: Re: Changing the Method Combination
Date:
Message-ID: <nkjr9mr2y5t.fsf@tfeb.org>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> Since you do not have a way to retrieve a METHOD-COMBINATION object
> in ANSI CL, the spec of ENSURE-GENERIC-FUNCTION seems inconsistent.
>
I agree with that.
> A quick solution would be to change the spec of
> ENSURE-GENERIC-FUNCTION to take a METHOD-COMBINATION *name* for
> the :method-combination argument.
>
This would work but I think I'd rather see the border moved to include
more MOP stuff (I know you didn't want to talk about that!). I think
this while area is on 13's (unofficial, nothing is official as far as
I know) list of things-to-consider.
--tim