GNU bug report logs - #66615
30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery

Previous Next

Package: emacs;

Reported by: Andrea Corallo <acorallo <at> gnu.org>

Date: Wed, 18 Oct 2023 18:07:02 UTC

Severity: normal

Found in version 30.0.50

Done: Andrea Corallo <acorallo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Andrea Corallo <acorallo <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 66615 <at> debbugs.gnu.org
Subject: Re: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type
 definition in the cl- machinery
Date: Fri, 20 Oct 2023 11:42:10 -0400
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I think we should improve this part of the docstring as doesn't sound
>> complete to me.
>
> Suggestions welcome.
>
>> Also shouldn't we add (null boolean symbol atom) to cover this other
>> path as well?
>
> You mean add `boolean` in there?
> No objection on my side.

Sorry I'm just trying to understand, I'm happy to write patches but I
need to understand first.

IIUC for this sub part of the hierarchy we have:

   ┌─────► t ◄─────┐
   │               │
   │              atom
   │               ▲
   │               │
sequence         symbol
   ▲               ▲
   │               │
   │               │
 list ◄───┐      boolean
   ▲      │        ▲
   │      │        │
   │      │        │
   │      └────────┤
   │               │
  cons            null


now I'm fine with having say (getting the relevant parts from
`cl--typeof-types' and adding boolean in the null's one as you
suggested):

(null boolean symbol list sequence atom)
(cons list sequence)
(symbol atom)

as entries, but how are these sufficient to reconstruct this hierarchy?

(null boolean symbol list sequence atom) is not a linearization of the
DAG, is just (TYPE . SUPERTYPES) where SUPERTYPES have no specific
order.  Am I wrong?

How can current code (say dispatch on builtin types) work if we can't
infer if 'sequence' is higher or lower in the hierarchy respect to
'list'?

I think the original idea (as expressed by the doc) of having "the list
of its supertypes from the most specific to least specific" works for
reconstructing the DAG if we have one entry per path to the top, say:

(null boolean symbol atom)
(null list sequence)
(cons list sequence)

But I might be easyly missing many things here.

Thanks!

(A confused) Andrea




This bug report was last modified 1 year and 213 days ago.

Previous Next


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