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

Previous Next

Full log

Message #218 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, 08 May 2025 17:31:57 -0400

Now that it's in `master`, you can think of the next steps:

- Make it more efficient.  By following the `parents` you can collect
  the set of built-in type in its ancestry and from that compute the set
  of types that `cl-type-of` might return for which there's a change
  that the current type applies.  Basically: walk up the `parents` chain
  until the first built-in type.  And from there, walk *down* from that
  "parent built-in type" to collect all its descendants: if `cl-type-of`
  returns a type which is not among those collected types, then we know
  the value is not in our type.
  E.g. `natnum` would have `integer` as parent, so we'd collect
  `integer`, `fixnum`, and `bignum` as the possible types.
  We could then have a hash-table indexed by built-in type giving the
  set of possible derived types, and we'd add `natnum` to all
  three entries (we may be able to skip `integer`, tho currently we
  don't keep track of which built-in types are abstract like `integer`
  and which ones are concrete (meaning that `cl-type-of` may return
  it)).
  So `cl-types-of` could start by indexing in the hash-table and then
  only test the possibly relevant derived types.

- Make it more automatic: we should be able to guess the `parents`
  automatically in many cases.  Just look for `(and TYPE1 TYPE2 ...)`
  and you immediately know that TYPE1 and TYPE2 are parents.

- Make it better behaved: E.g. if after defining `natnum` I define
  `my-foo` as `(or natnum symbol)`, then `my-foo` is less specific
  than `natnum` but it will appear first in the list, because I defined
  it afterwards.
  To resolve this, I think we need to support a `children` declaration,
  in addition to the `parents` declaration.  Then again maybe we don't
  need a declaration for that and we can extract that info by looking
  for types of the form `(or TYPE1 TYPE2 ...)`.  But we still then need
  to make use of that information to properly order the types.
  Another way to look at this is to try and implement `cl-subtypep`.


        Stefan

Previous Next

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