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

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: David Ponce <da_vid <at> orange.fr>
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: Thu, 17 Apr 2025 23:42:48 -0400

> (merge-ordered-lists '((test test)))
> => (test test)

Ah, right, `merge-ordered-lists` presumes the arg lists are already sane.

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


        Stefan

Previous Next

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