Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?

From: David Ponce <[email-masked]>
Date: Tue, 29 Apr 2025 12:50:27 +0200

On 2025-04-28 23:44, Stefan Monnier wrote:

[...]
> I pushed your new code to the `scratch/cl-types` branch in `emacs.git`.
> I haven't integrated it into the other CL-Lib files yet.
> See patch below for comments on your code.

Merci!

Please find attached a new version of cl-types.el with some updates
following your comments.

Regarding this FIXME, in `cl--type-deftype', about the global setting
of `cl--type-list':

;; FIXME: This global operation is a bit worrisome, because it
;; scales poorly with the number of types.  I guess it's OK
;; for now because `cl-deftype' is not very popular, but it'll
;; probably need to be replaced at some point.  Maybe we
;; should simply require that the parents be defined already,
;; then we can just `push' the new type, knowing it's in
;; topological order by construction.

It's not clear to me how "simply require that the parents be defined
already", makes the new type "in topological order by construction".
Also, as all this is done only at type (re)definition, which should
not happen so often, I am curious to know why you think "this global
operation is a bit worrisome"?

In `cl-types-of', I liked your idea to avoid calls to
`cl--type-parents' and `merge-ordered-list' before we do the
`gethash'.  I've gone a bit further in this direction (hopefully not
too far!) by doing all the type list computation just before creating
a new entry in the hash table. There's a slight overhead to determine
the types of objects not yet processed, but determining the types of
similar objects should be faster, which should be the most common case
(or at least the one to favor) when using types to dispatch methods.

WDYT?

Thanks!
David