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

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (null boolean symbol list sequence atom) is not a linearization of the
>> DAG,
>
> AFAIK it is.  A linearization can be "depth first" or "breadth" first or
> any mix of it.  It's basically any total order compatible with the
> partial order imposed by the DAG.
>
>> is just (TYPE . SUPERTYPES) where SUPERTYPES have no specific
>> order.  Am I wrong?
>
> The order is from most specific to least specific.  For types which are
> "incomparable", the choice is a judgment call.  The above ordering seems
> acceptable to me since `atom` is arguably a larger type than `sequence`,
> but
>
>     (null boolean symbol atom list sequence)
>
> is acceptable as well.
>
> This said, in general we'd like to avoid situations where type T1
> appears before type T2 in one case and after it in another (it may not
> always be avoidable, sadly).  And `atom` appears after `sequence` in
> cases like `vector` and `string`, so I think we should prefer
>
>     (null boolean symbol list sequence atom)
>
> over
>
>     (null boolean symbol atom list sequence)
>
>> 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'?
>
> The linearization is specific to a given type, so we use the ordering
> provided by `cl--typeof-types` and we never care to know the full DAG.
>
> [ BTW, we should be able to infer that `list` is lower because every
>   time it appears in `cl--typeof-types` it is always followed by
>   `sequence`.  ]
>
>> 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)
>
> Indeed.  But then it doesn't say how to make this into a total order
> when `cl-defmethod` needs to decide which method should come first.
>
> IOW, there is supposedly a DAG, but until now we've never actually
> needed the DAG itself, instead we've needed only a linearization of the
> ancestors of the leaves of that DAG, which is what
> `cl--typeof-types` stores.
>
> If you need the DAG, then maybe we need to store more info (tho I still
> suspect we should be able to extract that info from `cl--typeof-types`).

Yep, I think I'll go for adding the DAG somewhere else, extratcting it
from `cl--typeof-types` doesn't look trivial at all (if even possible)
and its definition is at this point kind of weak IMO for that.

Thanks

  Andrea