pattern vs standard specializers

[csrhodes]

I think it would be really nice if class and quote pattern specializers (without any further restrictions or variable bindings) were treated identically to the standard class and eql-specializers. This would allow the brave user to default to using pattern generic functions, and only paying for the cost when a non-trivial pattern specializer is actually included on a generic function.

[scymtym]

At which level should this happen? I can imagine at least three possibilities:

1. At the syntax level, parsing certain pattern specializer forms could just result in the corresponding class or eql specializers being constructed.
2. same-specializer-p and specializer< should already treat corresponding pattern and standard specializers as equivalent (modulo bugs, of course).
3. The equivalence could be in terms of accepted generalizers and object. This should also be the case already.

[csrhodes]

Jan Moringen notifications@github.com writes:

At which level should this happen? I can imagine at least three possibilities:

1. At the syntax level, parsing certain pattern specializer forms could just result in the corresponding class or eql specializers being constructed.
2. same-specializer-p and specializer< should already treat corresponding pattern and standard specializers as equivalent (modulo bugs, of course).

I think both of these are necessary -- point (1) because then the optimization that comes into play when only standard specializers are in existence is most broadly applicable, and point (2) to avoid the confusing situation where you have both a pattern specializer and a standard specializer representing the same semantics (which you could get if you carefully craft specializer objects and put them in defmethod forms or method construction by hand).

As well as these, there's also the issue of constructing specializer clusters; at present the non-pattern specializers are handled separately in generic-function-specializer-clusters -- maybe all that's necessary is not separating them out?

[scymtym]

To summarize

• we want to recognize class and eql specializers at the syntax level, parsing equivalent patterns as the corresponding class and eql specializers
• we want to support class and eql specializers in the specializer ordering and accepts-p protocols

One of the remaining questions is how to compute generalizer[s]-of-using-class when class and/or eql specializers are known to be present. When these specializers only appear as less-than-most-specific specializers in a "cluster", they can just be returned in the generalizer object returned by the optima:match clause corresponding to the most specific specializer of the "cluster". However, if the class or eql specializer is the most specific one in a "cluster" (potentially being the only element), there is no pattern for the optima:match clause. There are two at least two options in this case

1. Currently, the optima:match in the "generalizer maker" function can return nil which causes the next generalizer[s]-of-using-class method to be called. Consequently, excluding "clusters" whose most specific specializer is of the class or eql kind would automatically fall back to the class-of generalizer.
2. Synthesize patterns and optima:match clauses for such clusters.

Independent of this choice, I think the "fall back to the next generalizer[s]-of-using-class method" has to there to support specializers which are neither pattern nor class or eql.