GNU bug report logs - #77725
31.0.50; Add support for types accepted by `cl-typep' to cl-generic?

Previous Next

Package: emacs;

Reported by: David Ponce <da_vid <at> orange.fr>

Date: Fri, 11 Apr 2025 07:16:01 UTC

Severity: normal

Found in version 31.0.50

Full log


Message #137 received at 77725 <at> debbugs.gnu.org (full text, mbox):

From: David Ponce <da_vid <at> orange.fr>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep'
 to cl-generic?
Date: Tue, 29 Apr 2025 12:50:27 +0200
[Message part 1 (text/plain, inline)]
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
[cl-types.el (text/x-emacs-lisp, attachment)]

This bug report was last modified 10 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.