[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in t
From: |
Andrea Corallo |
Subject: |
bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery |
Date: |
Fri, 20 Oct 2023 05:05:47 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I've to question now the following entry introduced in
>> `cl--typeof-types' for correctness:
>>
>> (integer number integer-or-marker number-or-marker atom)
>>
>> The doc says :
>> Each element has the form (TYPE . SUPERTYPES) where TYPE is one of
>> the symbols returned by ‘type-of’, and SUPERTYPES is the list of its
>> supertypes from the most specific to least specific.
>>
>> And indeed not every 'number' is an 'integer-or-marker'.
>
> The subtype relation doesn't derive from a tree but a DAG so the
> SUPERTYPES represents *a* linearization of the parents but just because
> `number` appears before `integer-or-marker` doesn't mean that it's
> a subtype of it. It just means I judged that it should be considered
> "more specific".
>
> The same effect is in play for:
>
> (null symbol list sequence atom)
>
> where clearly `symbol` is a subtype of neither `list` nor `sequence`.
Hi Stefan,
I understand now thanks, the trouble is that the hierarchy is not a tree
but a DAG and these are just single linearizations.
I think we should improve this part of the docstring as doesn't sound
complete to me.
Also shouldn't we add (null boolean symbol atom) to cover this other
path as well?
>> I suspect that's the reason why this commit introduces few failures in
>> the native-comp testsuite.
>
> If you need to know the list of supertypes of `number`, we could add
> that info explicitly, or you could "guess" it as the intersection of all
> the types that appear after `number` in `cl--typeof-types`:
>
> (integer number integer-or-marker number-or-marker atom)
> [...]
> (float number number-or-marker atom)
> [...]
>
> i.e. the intersection of (integer-or-marker number-or-marker atom)
> and (number-or-marker atom).
I think I understand how to do it, OTOH might be better to have the
hierarchy made explicit somewhere? Still have to think to make an
opinion on this.
Thanks
Andrea
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Andrea Corallo, 2023/10/18
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Stefan Monnier, 2023/10/18
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Andrea Corallo, 2023/10/19
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Andrea Corallo, 2023/10/19
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Stefan Monnier, 2023/10/19
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Andrea Corallo, 2023/10/19
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Stefan Monnier, 2023/10/19
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery,
Andrea Corallo <=
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Stefan Monnier, 2023/10/20
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Andrea Corallo, 2023/10/20
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Stefan Monnier, 2023/10/20
- bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery, Andrea Corallo, 2023/10/22