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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> `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.  :)

The property `cl-deftype-satisfies` is very simple:

   (get <TYPE> 'cl-deftype-satisfies)

gives you the predicate you need to call.

So we could use this property or choose a new property name
(without the `cl-` prefix) which works the same way.  Then we need to
add the corresponding list of

    (put '<TYPE> '<PROP> '<PRED>)

somewhere (probably in `subr.el`, tho if we keep the
`cl-deftype-satisfies` name, then it would also fit in
`cl-preload.el`).

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

Agreed, especially since cl*.el do use `pcase` nowadays, so making
`pcase` use `cl-lib` can introduce some nasty bootstrapping problems.

Another problem of using `cl-typep` as-is is the question whether we
want to include the CL types such as `nil` (the empty type,
traditionally called ⊥ in type theory), `t` (the type of all objects,
traditionally called ⊤ in type theory), `(integer MIN MAX)`, ...

But at the same time, I can't think of a good reason why we should use
a different notion of type than CL's, so I guess it does make sense to
use `cl-typep` (makes the overall system simpler).  To avoid the
circularity, we can simply move the (pcase-defmacro type ...) outside of
`pcase.el` so it can easily depend on both `pcase` and `cl-lib`.
Another option is to do something like

    (pcase-defmacro type (ty)
      (require 'cl-lib)
      `(pred (pcase--flip cl-typep ',ty)))

so `cl-lib` is only required lazily (when we actually expand a `(type
TYPE)` pattern), so the bootstrapping problem shouldn't bite us as long
as neither pcase.el nor cl*.el themselves use such a pattern.

> Seems like a good idea to me, although the scope of those changes seem
> much larger than this patch,

Indeed.  But it's not enormous either (it's only an addition to what we
have, so there's no tricky business with backward compatibility and stuff).

> and I'm not sure I'm the right person for that job.

Based on the fact that it hasn't been done yet, I think we can assume
that noone is "the right person for that job", but you might still be
the closest there is.  I'd be happy to help.


        Stefan