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

Previous Next

Full log

View this message in rfc822 format

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: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Date: Fri, 18 Apr 2025 17:02:58 +0200

[Message part 1 (text/plain, inline)]

Hi Stefan,

>> (merge-ordered-lists '((test test)))
>> => (test test)
> 
> Ah, right, `merge-ordered-lists` presumes the arg lists are already sane.
>

So, I kept the test to ensure `name' is not in `parents'.

>>> The converse is that if we have already decided that the value is *not*
>>> for type BAR, then it can't be of type FOO either, so there's no point
>>> testing FOO.
>> Wouldn't this involve calculating the parents of all the types traversed,
>> instead of just the matching ones?
> 
> I wasn't describing an algorithm, just a principle that can be used
> within an algorithm.  Depending on the algorithm you use it can be used
> in different ways.  With your current loop, I don't think you can make
> much use of it.
> 
> But I think what we could do fairly easily is the following:
> 
> - based on the PARENTS declaration, create a map from builtin-type to
>    the set of cl-types that have that builtin-type among their parents.
>    That presumes some PARENTS include some builtin-types, obviously
>    otherwise the map will be trivial with all cl-types associated with
>    the `t` "dummy parent".
>    [ We could even go crazy and try and guess PARENTS when not provided,
>      by analyzing the type's definition.  ]
> - in `cl-types-of` start by calling `cl-type-of`, then use the map to
>    find which cl-types may need to be checked.
> 
> But let's keep this for later.

I was thinking about the exact same idea not long ago :-) I totally
agree with your analysis.  I noted this point in a FIXME.

Please, find attached a new version of cl-types.el:

- I've divided the code more logically between the `cl-deftype2' macro
  and the `cl--type-generalize' function.

- In `cl-types-of', I implemented the idea of ​​not testing a type
  already selected as a parent of a type already selected :-)

- I tried to add some comments to the not so obvious code.

I also wrote a first try at a test file, cl-types-tests.el, also
attached:

- It includes your proposed tests with multiples-of...
  All tests pass for me :-)

Please let me know if something is not correct, need more work, etc.

Regarding a possible merge in cl-lib, should cl-types.el be copied at
the end of cl-lib, after cl-macs is loaded?  If I correctly understand
the logic of loading these libs ;-)

Thank you!
David

[cl-types-tests.el (text/x-emacs-lisp, attachment)]

[cl-types.el (text/x-emacs-lisp, attachment)]

Previous Next

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