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

Previous Next

Full log

Message #179 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, 6 May 2025 16:57:51 +0200

On 2025-05-06 05:45, Stefan Monnier wrote:
>> As mentioned in a previous message, `cl--type-flag' explored the idea of
>> ​​mapping a set of cl-types to a built-in type (root-type), and its value
>> allowed us to know whether the type is worth checking, i.e. either not
>> yet passed a `cl-typep' in `cl-types-of', or its root-type match the
>> `root-type' of the checked object:
> 
> Oh, duh!  I completely misunderstood this and confused it with a flag
> that indicated the type was signaling errors.
> Thanks for the heads up.
> 
> I the mean time, I pushed the branch another change which smears the
> code over the various `cl-*.el` files.  It's ugly as sin, but that's the
> best I could come up with.

Great! Thank you!
I successfully "make bootstrap" the branch :-)
I run the cl-types-test with success, but one type has been signaled
in error on first run:

 Debugger entered--Lisp error: (void-function kmacro-register-p)
  kmacro-register-p(2)
  cl-typep(2 (satisfies kmacro-register-p))
  cl-typep(2 kmacro-register)
  cl-types-of(2)
  (seq-intersection (cl-types-of 2) types)
  [...]

>> (cl-types-of 'button) => button match `icon' type, so the `cl--type-flag'
>> of `icon' is set to `symbol' (cl-type-of or root-type of `button')
>>
>> (cl-types-of 12) => `root-type' of 12 is `fixnum', so cl-types-of doesn't
>> waste time checking if 12 if of type `icon', because we are sure it cannot
>> match (their root-types are different).  An so on with other types whose
>> root-type is known.
> 
> That makes a lot of sense, indeed.
> But ... does it work for:
> 
>     (cl-deftype my-pair ()
>       `(and number (satisfies ,(lambda (x) (zerop (logand x 1))))))
> 
> (cl-types-of (expt 2 128)) => (expt 2 128) matches `my-pair` type, so
> the `cl--type-flag` of `my-pair` is set to `bignum`.  Now when I try
> (cl-types-of 4) won't it skip `my-pair` because (cl-type-of 4) is not
> `bignum`?  What am I missing?

Good point! The problem is that the type returned by `cl-type-of' is too
specific. If I instead use `type-of' to map a set of cl-types to a
built-in type, your example above works as expected, as do other
categories I've tested, like symbol, cons, string, etc.
Using `type-of' to determine a set of cl-types seems like a good
compromise to me. WDYT?

I am still reviewing your (big) change, and will let you know any remarks
shortly, along with any proposals as a patch.

David

Previous Next

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