I've been looking over the CLOS stuff in the standard, and have been
extremely aggravated, not being able to figure out how to easily get a
method combination object given its name (symbol).
I'd like (and even expect) to be able to say:
(find-method-combination 'my-method-combination)
and have it return a method combination object. I *don't* want to
have to specify a GF, since that goes exactly against what I'm trying
to do, which is to define one:
(define-method-combination ...)
and then use it in a macro which expands into an
ensure-generic-function form:
(ensure-generic-function 'my-gf
:method-combination (find-method-combination 'my-method-combination)
...)
Of course, if ensure-generic-function simply allowed for a symbol,
then that would work too, but that's not what the standard says.
I don't see how the standard holds together here, since while
defgeneric nicely handles the issue of supplying a method combination
and its arguments using standard stuff, ensure-generic-function
doesn't seem to.
thanks,
dave
* David Bakhash wrote:
> I've been looking over the CLOS stuff in the standard, and have been
> extremely aggravated, not being able to figure out how to easily get a
> method combination object given its name (symbol).
> I'd like (and even expect) to be able to say:
> (find-method-combination 'my-method-combination)
As far as I can see you can say
(find-method-combination <any-gf> name nil)
and it works -- I use #'print-object as the GF because I know it
exists. AMOP does look a bit deficient here.
> I don't see how the standard holds together here, since while
> defgeneric nicely handles the issue of supplying a method combination
> and its arguments using standard stuff, ensure-generic-function
> doesn't seem to.
I'm not sure what you mean by `the standard' here: none of this stuff
is specified in the ANSI standard, and the AMOP protocol definition is
not, I think, ready for standardisation as it stands (and I don't
think was intended to be, though I could be wrong).
--tim
Tim Bradshaw <···@cley.com> writes:
I'm extremely confused by this reply. Let me try again.
> * David Bakhash wrote:
> > I've been looking over the CLOS stuff in the standard, and have been
> > extremely aggravated, not being able to figure out how to easily get a
> > method combination object given its name (symbol).
>
> > I'd like (and even expect) to be able to say:
>
> > (find-method-combination 'my-method-combination)
>
> As far as I can see you can say
>
> (find-method-combination <any-gf> name nil)
the function mop:find-method-combination seems to be an ACL thing.
Also, it's not what I want because I want to find the method
combination based on its name, irrespective of any GF. In addition,
the whole point of what I wanted was to find a method combination that
was defined _by me_, with DEFINE-METHOD-COMBINATION and currently not
(yet) used in any GF.
> > I don't see how the standard holds together here, since while
> > defgeneric nicely handles the issue of supplying a method combination
> > and its arguments using standard stuff, ensure-generic-function
> > doesn't seem to.
>
> I'm not sure what you mean by `the standard' here: none of this stuff
> is specified in the ANSI standard, and the AMOP protocol definition is
> not, I think, ready for standardisation as it stands (and I don't
> think was intended to be, though I could be wrong).
I disagree completely. DEFINE-METHOD-COMBINATION is part of the
standard; ENSURE-GENERIC-FUNCTION is part of the standard. for
ENSURE-GENERIC-FUNCTION the CLHS says:
Syntax:
ensure-generic-function function-name &key
argument-precedence-order declare documentation environment
generic-function-class lambda-list method-class
method-combination
generic-function
Arguments and Values:
function-name - a function name.
The keyword arguments correspond to the option arguments of
defgeneric, except that the :method-class and
:generic-function-class arguments can be class objects as well
as names.
Method-combination -- method combination object. !!! SEE HERE !!!
Description:
The function ensure-generic-function is used to define a
globally named generic function with no methods or to specify
or modify options and declarations that pertain to a globally
named generic function as a whole.
<snip>
If function-name is a list, it must be of the form (setf
symbol). If function-name specifies a generic function that
has a different value for any of the following arguments, the
generic function is modified to have the new value:
:argument-precedence-order, :declare, :documentation,
:method-combination.
Are you implying that even though ENSURE-GENERIC-FUNCTION is part of
the standard, that it wasn't intended to be used except when doing MOP
stuff? I don't see a single place where my question has anything to
do with the MOP at all, and everything I'm asking is directly based on
ANSI CL.
dave
* David Bakhash wrote:
> the function mop:find-method-combination seems to be an ACL thing.
> Also, it's not what I want because I want to find the method
> combination based on its name, irrespective of any GF. In addition,
> the whole point of what I wanted was to find a method combination that
> was defined _by me_, with DEFINE-METHOD-COMBINATION and currently not
> (yet) used in any GF.
It's part of what is defined by AMOP. If you'd try it you'd find it
does what you want:
In Allegro:
CL-USER(4): (define-method-combination foo :operator +)
#<standard-method aclmop:find-method-combination
(generic-function (eql foo) t)>
CL-USER(5): (mop:find-method-combination #'print-object 'foo nil)
#<excl::short-method-combination @ #x4597b0a>
And in CMUCL:
* (define-method-combination foo :operator +)
#<Standard-Method find-method-combination (generic-function (eql foo)
t) {70CEA85}>
* (find-method-combination #'print-object 'foo nil)
#<Method-Combination foo (:most-specific-first) {70D712D}>
And even in Genera:
> (define-method-combination foo :operator +)
#<clos-internals::short-form-method-combination-definition foo 401315343>
> (clos-internals::find-method-combination #'print-object 'foo nil)
#<clos-internals::standard-method-combination (foo) 1000404>
> Are you implying that even though ENSURE-GENERIC-FUNCTION is part of
> the standard, that it wasn't intended to be used except when doing MOP
> stuff? I don't see a single place where my question has anything to
> do with the MOP at all, and everything I'm asking is directly based on
> ANSI CL.
Oops. I always forget that ENSURE-GENERIC-FUNCTION is in there. I
think there is some reason you need it though it might be just a bug
that it's there (perhaps someone who was involved in deciding what to
put in or leave out can say?) but I don't think you are expected to be
able to use the method combination stuff without the rest of the MOP.
The standard probably documents the possibility of the argument so
that any later inclusion of a MOP doesn't have to go back and rewrite
things that are already in the standard, which is quite an important
thing to avoid.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>* David Bakhash wrote:
>> Are you implying that even though ENSURE-GENERIC-FUNCTION is part of
>> the standard, that it wasn't intended to be used except when doing MOP
>> stuff? I don't see a single place where my question has anything to
>> do with the MOP at all, and everything I'm asking is directly based on
>> ANSI CL.
>
>Oops. I always forget that ENSURE-GENERIC-FUNCTION is in there. I
>think there is some reason you need it though it might be just a bug
>that it's there
I think it was a bug. A few MOPpish things were put into the original CLOS
spec, with the expectation that more of the MOP would be added. When the
latter didn't happen, the ones that were originally included were not all
cleaned out.
--
Barry Margolin, ······@genuity.net
Genuity, 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 <······@genuity.net> writes:
>
> I think it was a bug. A few MOPpish things were put into the original CLOS
> spec, with the expectation that more of the MOP would be added. When the
> latter didn't happen, the ones that were originally included were not all
> cleaned out.
That's interesting because I suspected it was like that! I always
thought that FIND-METHOD was like this too, and probably some others.
I also wondered about ALLOCATE-INSTANCE for ages till I realised you
need it for MAKE-LOAD-FORM and felt a bit foolish...
--tom
Barry Margolin <······@genuity.net> writes:
> I think it was a bug. A few MOPpish things were put into the
> original CLOS spec, with the expectation that more of the MOP would
> be added. When the latter didn't happen, the ones that were
> originally included were not all cleaned out.
method combination is completely supported by ANSI CL. In my opinion,
they merely forgot to define a function called
FIND-METHOD-COMBINATION, which takes a symbol which is a method
combination specifier.
dave
David Bakhash <·····@alum.mit.edu> writes:
> method combination is completely supported by ANSI CL. In my opinion,
> they merely forgot to define a function called
> FIND-METHOD-COMBINATION, which takes a symbol which is a method
> combination specifier.
>
No, it's not. The macro layer is supported, but (as with the rest of
CLOS) the underlying functional layer is almost entirely missing.
--tim
Barry Margolin <······@genuity.net> writes:
> I think it was a bug. A few MOPpish things were put into the original CLOS
> spec, with the expectation that more of the MOP would be added. When the
> latter didn't happen, the ones that were originally included were not all
> cleaned out.
Again, while method combination sounds like something MOPish, it's in
the ANSI spec, and so the fact that there's no good way to use
ENSURE-GENERIC-FUNCTION is annoying, to say the least.
The macro layer works; that's nice. But it's the functional layer
that you kinda wanna use when _writing_ macros.
In my case, it's because I wanted to change the method combination of
INITIALIZE-INSTANCE in a backwards-compatible way. It would have been
cool to be able to do this with standard CLOS, using
ENSURE-GENERIC-FUNCTION.
dave
David Bakhash <·····@alum.mit.edu> writes:
> Again, while method combination sounds like something MOPish, it's in
> the ANSI spec, and so the fact that there's no good way to use
> ENSURE-GENERIC-FUNCTION is annoying, to say the least.
>
Yes, but as Barry said, the spec's border is ragged and not completely
consistent -- there are things that got left in that probably
shouldn't have been.
> The macro layer works; that's nice. But it's the functional layer
> that you kinda wanna use when _writing_ macros.
>
Yes. In order to do that you need the (or a) MOP, because that's one
of the things that a MOP is. Fortunately, many (most? all?)
implementations are pretty close to the AMOP MOP, so you can use that,
modulo some implementation-specific USE-PACKAGEs. I've done `mild'
MOP-based code which runs with very slight changed (things like
VALIDATE-SUPERCLASS methods being needed in some implementations but
not others) across CMUCL, ACL, Liquid and Genera.
In fact not even the AMOP MOP specifies much about method combinations
-- there's no ENSURE-METHOD-COMBINATION or anything like that.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> In fact not even the AMOP MOP specifies much about method
> combinations -- there's no ENSURE-METHOD-COMBINATION or anything
> like that.
Yeah. I guess all these problems would just go away if a symbol could
be used as a method combination specifier, much the same way symbols
can be used to specify packages in just about every CL function and
macro.
dave
David Bakhash <·····@alum.mit.edu> writes:
> I've been looking over the CLOS stuff in the standard, and have been
> extremely aggravated, not being able to figure out how to easily get a
> method combination object given its name (symbol).
I'm pretty sure that no such function exists, portably. I had the
same search several months ago. I had to delve into
implementation-specific details to get to it.
- Pat