Re: [PATCH] pcase.el: Add type pattern

[Adam Porter]

Stefan Monnier <address@hidden> writes:

>> I wondered if checking for predicates like this was a good way to do
>> so,
>
> `cl-typep` does it but I think it's a mistake.
> We should not rely on such heuristics when we can "do it right",
> e.g. with a property along the lines of `cl-deftype-satisfies`.

Understood, but I'm not sure exactly what you mean, as far as what I
should do in that regard.  I'm not very familiar with cl-lib's
internals.  :)

>> +     (pred (or (intern-soft (concat type "p"))
>> +               (intern-soft (concat type "-p"))
>
> This fails for those cl-defstructs where the `:predicate` was given
> another name (or no name at all).

Good catch, thanks.

> We could circumvent the problem by expanding the (type T) check to
> to a call to `cl-typep`.

That would be fine with me, of course, but I was hesitant to use any
`cl-' functions in pcase.el since it doesn't use any and doesn't already
require `cl-lib'.  Let me know if you want me to do that.

> PS: Arguably, every type symbol should have a corresponding *class*
> (currently stored in the `cl--class` symbol for cl-defstruct and eieio
> objects), so we should then add a bunch of classes for non-structs
> non-eieio types (such as integer, ...) and we could then define a
> generic function which takes such a class and returns the predicate to
> use as a test for this type.

Seems like a good idea to me, although the scope of those changes seem
much larger than this patch, and I'm not sure I'm the right person for
that job.

Thanks for your feedback.