Re: pcase defuns

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Oh dear, my head becomes dizzy when reading their dispatch behavior
>> at (info "(elisp) Generic Functions").  Well, I mean, the typical
>> uses can be pretty easy to understand but if you mix and match
>> different kinds of specifiers, it becomes unwieldy, like what happens
>> when you have two methods where one specifies the first argument must
>> be an integer and the other says it applies if the first argument is
>> (eql 42) [where 42 is obviously an integer]?  I can't read a priority
>> order between different kinds of specifiers...
>
> When the specializers are "naturally nested" (i.e. if you take them as
> sets, one set is a subset of the other), then the desired precedence
> is pretty clear and cl-generic *should* obey that order

A quick test with types such as integer and float and eql picking
specific elements in the sets specified by those types suggest it works
well.

> (if it doesn't, it should be considered as a bug, tho I wouldn't be
> surprised if someone comes up with examples which we may decide not to
> fix).

At least I cannot easily come up with some counter-example.  Maybe usage
of the subr type specializer could result in unexpected results with
native-comp given that every function will become a subr there at some
point.

Bye,
Tassilo