[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: [PATCH] pcase.el: Add type pattern
Date: Mon, 09 Mar 2020 17:00:23 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]