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

[Andrea Corallo]

Stefan Monnier <monnier@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