Re: RFC: Extending method specializers

Slava Akhmechet wrote:
Pascal Costanza <pc@xxxxxxxxx> writes:

You could start by restricting the predicates to the kinds of
predicates that describe strict subset relationships, and for example,
reject a method on oddp when a method on primep already exists, or
vice versa. But this requires you to (a) either analyze the predicate
to find out what it does, or (b) restrict the predicates to a fixed
set of predefined ones.
That's a false dilemma. For situations where priority cannot be
clearly determined you could keep track of the method definition order
and evaluate the predicates in that order, selecting the first one
that passes (ML-style). You could add a protocol step and require the
programmer to specify the priority explicitly. You could even pick a
predicate based on the alphabetical order of its name :)

With a little thought, I'm sure it's possible to come up with a
practical and theoretically sound solution. This doesn't have to be
reduced to the halting problem :)

Maybe. But in general, the order in which methods are added to a generic function is not well defined, except for the methods which are part of a defgeneric form itself.

An important benefit of CLOS-style generic functions is that you can define methods for generic functions in several places of your program, and they all become potentially applicable. Applicability remains stable, no matter in which order the various parts of the program are loaded. (To a certain degree, that's even true for class definitions, thanks to forward-referenced classes.)

Among other things, this enables you to integrate different methods from different parties. Now, if you want to specify priorities by, say, specifying numbers (which is relatively straightforward to do in method combinations), the problem is that in the general case, you don't know what numbers the other parties (other programmer teams, other library extensions, etc.) have used. Same for alphabetical order or, I'm pretty sure, any other scheme you may come up with. That's again a consequence that you're actually trying to solve the halting problem in disguise: You need some form of global knowledge (by knowing all program parts, or by restricting what the different program parts can say).

If you insist on having global knowledge, you might as well use simple cond or typecase forms, because there would be no real benefit in terms of independent extensibility anymore anyway.

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/
.