Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

> -(defconst cl--typeof-types
> -  ;; Hand made from the source code of `type-of'.
> -  '((integer number integer-or-marker number-or-marker atom)
> -    (symbol-with-pos symbol atom) (symbol atom) (string array sequence atom)
[...]
> +(defconst cl--type-hierarchy
[...]
> +    (symbol keyword boolean symbol-with-pos)
[...]
> +    (symbol-with-pos keyword))

How did you come up with `cl--type-hierarchy`?
Because, obviously, something changed here.
How is `keyword` a "direct subtype" of `symbol-with-pos`?

> +(defconst cl--direct-supertypes-of-type
> +  (make-hash-table :test #'eq)
> +  "Hash table TYPE -> SUPERTYPES.")
> +
> +(defconst cl--direct-subtypes-of-type
> +  (make-hash-table :test #'eq)
> +  "Hash table TYPE -> SUBTYPES.")
> +
> +(cl-loop for (parent . children) in cl--type-hierarchy
> +         do (cl-loop
> +             for child in children
> +             do (cl-pushnew parent (gethash child cl--direct-supertypes-of-type))
> +             do (cl-pushnew child (gethash parent cl--direct-subtypes-of-type))))

FWIW, I think we should create a "type descriptor" defstruct (from which
`cl--class` would inherit), and generalize the `cl--class` symbol
property to one that holds the type descriptor of the given name.

So you could get the direct parents of `integer` with something like:

    (slot-value (get 'integer 'cl--class) 'parents)

[ And then `C-h o integer RET` should show the corresponding info.  ]

> +(defconst cl--typeof-types nil

This can't make sense.
If you change it later with `push/setq` it should not be a "defconst".
So either arrange to compute its default value directly inside the
`defconst`, or use a `defvar`.

> +(maphash (lambda (type _)
> +           (push (cl--supertypes-for-typeof-types type) cl--typeof-types))
> +         cl--direct-supertypes-of-type)

Did you compare the resulting alist to the one we had before?
Remember that the order of "(direct or not) supertypes" in there is
important.
The current table has errors.  I see for example:

    (fixnum integer integer-or-marker number atom number-or-marker)

where `atom` should come *after* `number-or-marker`.


        Stefan

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

>> -(defconst cl--typeof-types
>> -  ;; Hand made from the source code of `type-of'.
>> -  '((integer number integer-or-marker number-or-marker atom)
>> -    (symbol-with-pos symbol atom) (symbol atom) (string array sequence atom)
> [...]
>> +(defconst cl--type-hierarchy
> [...]
>> +    (symbol keyword boolean symbol-with-pos)
> [...]
>> +    (symbol-with-pos keyword))
>
> How did you come up with `cl--type-hierarchy`?
> Because, obviously, something changed here.
> How is `keyword` a "direct subtype" of `symbol-with-pos`?

Hi Stefan,

Can't we have keyword that is a symbol-with-pos as well?

>> +(defconst cl--direct-supertypes-of-type
>> +  (make-hash-table :test #'eq)
>> +  "Hash table TYPE -> SUPERTYPES.")
>> +
>> +(defconst cl--direct-subtypes-of-type
>> +  (make-hash-table :test #'eq)
>> +  "Hash table TYPE -> SUBTYPES.")
>> +
>> +(cl-loop for (parent . children) in cl--type-hierarchy
>> +         do (cl-loop
>> +             for child in children
>> +             do (cl-pushnew parent (gethash child cl--direct-supertypes-of-type))
>> +             do (cl-pushnew child (gethash parent cl--direct-subtypes-of-type))))
>
> FWIW, I think we should create a "type descriptor" defstruct (from which
> `cl--class` would inherit), and generalize the `cl--class` symbol
> property to one that holds the type descriptor of the given name.
>
> So you could get the direct parents of `integer` with something like:
>
>     (slot-value (get 'integer 'cl--class) 'parents)
>
> [ And then `C-h o integer RET` should show the corresponding info.  ]

SGTM, I'm not very accustomed to this area of the code tho.

>> +(defconst cl--typeof-types nil
>
> This can't make sense.
> If you change it later with `push/setq` it should not be a "defconst".
> So either arrange to compute its default value directly inside the
> `defconst`, or use a `defvar`.

Ops done.

>> +(maphash (lambda (type _)
>> +           (push (cl--supertypes-for-typeof-types type) cl--typeof-types))
>> +         cl--direct-supertypes-of-type)
>
> Did you compare the resulting alist to the one we had before?
> Remember that the order of "(direct or not) supertypes" in there is
> important.
> The current table has errors.  I see for example:
>
>     (fixnum integer integer-or-marker number atom number-or-marker)
>
> where `atom` should come *after* `number-or-marker`.

Yes I did it but I missed this sorry. I wish this was catch-ed in the
two weeks this branch stayed in review.  Okay in my todo list now for
the weekend :)

Thanks

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

>>> +    (symbol-with-pos keyword))
> Can't we have keyword that is a symbol-with-pos as well?

I'm not sure (it depends if we agree that a `symbol-with-pos` is also
a `symbol`.   In practice it presumably depends on the value of
`symbols-with-pos-enabled` 🙁), but I know that not all
`symbol-with-pos`s are `keyword`s.


        Stefan "who thinks he would prefer that `symbols-with-pos-enabled`
                only affects the behavior of `eq`"

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

>>>> +    (symbol-with-pos keyword))
>> Can't we have keyword that is a symbol-with-pos as well?
>
> I'm not sure (it depends if we agree that a `symbol-with-pos` is also
> a `symbol`.   In practice it presumably depends on the value of
> `symbols-with-pos-enabled` 🙁),

I *think* (thought at this point?) symbols-with-pos are symbols 🤷.

> but I know that not all
> `symbol-with-pos`s are `keyword`s.

How do you think this should be expressed in the DAG?  I thought this
was the correct way but I can indeed be wrong.

>
>         Stefan "who thinks he would prefer that `symbols-with-pos-enabled`
>                 only affects the behavior of `eq`"

Could you explain why you think `symbols-with-pos-enabled` should
influence our type hierarchy?

Thanks

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

>>>>> +    (symbol-with-pos keyword))
>>> Can't we have keyword that is a symbol-with-pos as well?
>> I'm not sure (it depends if we agree that a `symbol-with-pos` is also
>> a `symbol`.   In practice it presumably depends on the value of
>> `symbols-with-pos-enabled` 🙁),
> I *think* (thought at this point?) symbols-with-pos are symbols 🤷.

`symbolp` on a sympos will return t or nil depending on
`symbols-with-pos-enabled`, and similarly functions that accept symbols
will usually accept sympos only if that variable is set :-(

>> but I know that not all `symbol-with-pos`s are `keyword`s.
> How do you think this should be expressed in the DAG?
> I thought this was the correct way but I can indeed be wrong.

It's clearly not right, because a subtype means set-inclusion, which
here means that the current table asserts that all keywords are also
`symbol-with-pos`.

AFAIK `symbol-with-pos` just doesn't have any subtypes.  We could
introduce a new type `keyword-with-pos`, which would be a subtype of
`symbol-with-pos` and `keyword`, but I don't see much need for it.

Our DAG is "incomplete" in the sense that some values don't have a "most
specific type".  "keyword with pos" is indeed such a case.  A list of
the form (lambda ...) is another such case,

While I'm here, I also notice you added `class` and `structure` in
there, but I don't think these can be currently considered as "types"
(or at least, I don't know how they would be defined).

Of course, there are more quirks, like the `subrp` which returns t for
special forms, which aren't functions (that's a FIXME you threw away
when you replaced `cl--typeof-types` with `cl--type-hierarchy`).

> Could you explain why you think `symbols-with-pos-enabled` should
> influence our type hierarchy?

AFAIK types are defined by the set of values they can hold and/or by the
set of operations we can apply to those values.  And the set of
operations we can apply on sympos depends on this variable :-(


        Stefan

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

>>>>>> +    (symbol-with-pos keyword))
>>>> Can't we have keyword that is a symbol-with-pos as well?
>>> I'm not sure (it depends if we agree that a `symbol-with-pos` is also
>>> a `symbol`.   In practice it presumably depends on the value of
>>> `symbols-with-pos-enabled` 🙁),
>> I *think* (thought at this point?) symbols-with-pos are symbols 🤷.
>
> `symbolp` on a sympos will return t or nil depending on
> `symbols-with-pos-enabled`, and similarly functions that accept symbols
> will usually accept sympos only if that variable is set :-(
>
>>> but I know that not all `symbol-with-pos`s are `keyword`s.
>> How do you think this should be expressed in the DAG?
>> I thought this was the correct way but I can indeed be wrong.
>
> It's clearly not right, because a subtype means set-inclusion, which
> here means that the current table asserts that all keywords are also
> `symbol-with-pos`.

Right.

> AFAIK `symbol-with-pos` just doesn't have any subtypes.  We could
> introduce a new type `keyword-with-pos`, which would be a subtype of
> `symbol-with-pos` and `keyword`, but I don't see much need for it.

Okay for me even if this sounds a bit arbitrary.

> Our DAG is "incomplete" in the sense that some values don't have a "most
> specific type".  "keyword with pos" is indeed such a case.  A list of
> the form (lambda ...) is another such case,
>
> While I'm here, I also notice you added `class` and `structure` in
> there, but I don't think these can be currently considered as "types"
> (or at least, I don't know how they would be defined).

Mmmh for class and structure I thought because we have 'class-p' and
'cl-struct-p' we had the corresponding types (from which the user
defined ones are derived).  IIRC I've seen also in the past we have the
class type.

Anyway for this and the keyword thing I certainly don't have any strong
feeling/opinion, I've asked feedback on this hierarchy here since about
4 months ago really because it's tricky.  But I think it's really a good
exercise we (finally) spell it out and document it.

Thanks

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

> Mmmh for class and structure I thought because we have 'class-p' and
> 'cl-struct-p' we had the corresponding types (from which the user
> defined ones are derived).  IIRC I've seen also in the past we have the
> class type.

We do have types for them, but they're not built-in.
There's `cl--class`, `cl-structure-object`, `cl-structure-class`, and
some others I can't remember for EIEIO.

> Anyway for this and the keyword thing I certainly don't have any strong
> feeling/opinion, I've asked feedback on this hierarchy here since about
> 4 months ago really because it's tricky.  But I think it's really a good
> exercise we (finally) spell it out and document it.

I think if we want to do it right, we have to introduce a new `type-of`
function which can return `boolean` for `t`, and various other backward
incompatible changes, and make sure the DAG is "complete" (e.g. add
`keyword-sym-pos`, `list-and-function`, `subr-function`, and
`special-form`).

But there hasn't been much concrete need for it, so we may as well keep
it for later if/when we actually need something like that.


        Stefan

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

>> Mmmh for class and structure I thought because we have 'class-p' and
>> 'cl-struct-p' we had the corresponding types (from which the user
>> defined ones are derived).  IIRC I've seen also in the past we have the
>> class type.
>
> We do have types for them, but they're not built-in.
> There's `cl--class`, `cl-structure-object`, `cl-structure-class`, and
> some others I can't remember for EIEIO.

Just to make sure we agree, what's the definition of built-in type?  I
think we should consider everything that comes preloaded in an emacs -Q
no?  I see those types are defined in my emacs -Q.

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

>> We do have types for them, but they're not built-in.
>> There's `cl--class`, `cl-structure-object`, `cl-structure-class`, and
>> some others I can't remember for EIEIO.
> Just to make sure we agree, what's the definition of built-in type?

It's a pragmatic definition: `cl--typeof-types` is there to deal with
those types which aren't properly described by a `cl--class` symbol property.


        Stefan

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

>>> We do have types for them, but they're not built-in.
>>> There's `cl--class`, `cl-structure-object`, `cl-structure-class`, and
>>> some others I can't remember for EIEIO.
>> Just to make sure we agree, what's the definition of built-in type?
>
> It's a pragmatic definition: `cl--typeof-types` is there to deal with
> those types which aren't properly described by a `cl--class` symbol property.

I see, but I'm not thinking to the content of `cl--typeof-types`.  I'm
thinking to the representation we generate for our doc with the type
hierarchy.  I'm wondering if we should include `cl--class`,
`cl-structure-object`, `cl-structure-class` as built-in types.

Bests

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

> I see, but I'm not thinking to the content of `cl--typeof-types`.  I'm
> thinking to the representation we generate for our doc with the type
> hierarchy.  I'm wondering if we should include `cl--class`,
> `cl-structure-object`, `cl-structure-class` as built-in types.

I guess it would make sense to include parts of the
struct/EIEIO/OClosure hierarchy for people to understand how they fit
alongside the "builtin" part, indeed.


        Stefan

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

[...]

> The current table has errors.  I see for example:
>
>     (fixnum integer integer-or-marker number atom number-or-marker)
>
> where `atom` should come *after* `number-or-marker`.

Okay re-reading my code I understood that when I wrote the generator I
miss-understood (again) the intended format of `cl--typeof-types'.

Looks to me better now, this is the content on my Emacs after having
pushed 8d11b7e4275, please have a look:

((subr-primitive subr function atom)
 (subr-native-elisp subr function atom)
 (compiled-function function atom)
 (module-function function atom)
 (subr function atom)
 (byte-code-function compiled-function function atom)
 (cons list sequence)
 (null list sequence boolean symbol atom)
 (string array sequence atom)
 (char-table array sequence atom)
 (bool-vector array sequence atom)
 (vector array sequence atom)
 (symbol-with-pos symbol atom)
 (boolean symbol atom)
 (keyword symbol-with-pos symbol atom)
 (fixnum integer number number-or-marker integer-or-marker atom)
 (bignum integer number number-or-marker integer-or-marker atom)
 (number number-or-marker atom)
 (marker number-or-marker integer-or-marker atom)
 (integer number number-or-marker integer-or-marker atom)
 (float number number-or-marker atom)
 (obarray atom)
 (symbol atom)
 (number-or-marker atom)
 (integer-or-marker atom)
 (overlay atom)
 (window-configuration atom)
 (process atom)
 (window atom)
 (function atom)
 (buffer atom)
 (frame atom)
 (hash-table atom)
 (terminal atom)
 (thread atom)
 (mutex atom)
 (condvar atom)
 (font-spec atom)
 (font-entity atom)
 (font-object atom)
 (user-ptr atom)
 (tree-sitter-parser atom)
 (tree-sitter-node atom)
 (tree-sitter-compiled-query atom)
 (structure atom)
 (class atom)
 (array sequence atom)
 (list sequence)
 (atom)
 (sequence))

Also is not clear to me if 'cl--typeof-types' should include all types
or only leaf ones.  The original was inconsistent on this, this version
evidently includes all types but should be easy to generate only based
on the leaf ones if necessary.

Thanks

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

> Looks to me better now, this is the content on my Emacs after having
> pushed 8d11b7e4275, please have a look:

looks OK, thanks (modulo structure/class because I don't know what these mean).

> Also is not clear to me if 'cl--typeof-types' should include all types
> or only leaf ones.

The intention was to include only leaf types, i.e. the types that
`type-of` can return, since the main purpose was to find the (ordered)
list of parents in:

    (cl-generic-define-generalizer cl--generic-typeof-generalizer
      ;; FIXME: We could also change `type-of' to return `null' for nil.
      10 (lambda (name &rest _) `(if ,name (type-of ,name) 'null))
      (lambda (tag &rest _)
        (and (symbolp tag) (assq tag cl--typeof-types))))

> The original was inconsistent on this,

Maybe that was an oversight.
Do you remember which inconsistency you had noticed in this respect?

> this version evidently includes all types but should be easy to
> generate only based on the leaf ones if necessary.

Having extra types doesn't bring any benefit that I can see but is
fairly harmless (it may just slow down ever so slightly a few method
dispatches, when we have a miss in the method cache).


        Stefan

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

>> Looks to me better now, this is the content on my Emacs after having
>> pushed 8d11b7e4275, please have a look:
>
> looks OK, thanks (modulo structure/class because I don't know what these mean).

Cool, I'll comeback on the structure/class subject.

>> Also is not clear to me if 'cl--typeof-types' should include all types
>> or only leaf ones.
>
> The intention was to include only leaf types, i.e. the types that
> `type-of` can return, since the main purpose was to find the (ordered)
> list of parents in:
>
>     (cl-generic-define-generalizer cl--generic-typeof-generalizer
>       ;; FIXME: We could also change `type-of' to return `null' for nil.
>       10 (lambda (name &rest _) `(if ,name (type-of ,name) 'null))
>       (lambda (tag &rest _)
>         (and (symbolp tag) (assq tag cl--typeof-types))))
>
>> The original was inconsistent on this,
>
> Maybe that was an oversight.
> Do you remember which inconsistency you had noticed in this respect?

I remember (symbol-with-pos symbol atom) (symbol atom), there might have
been others.

>> this version evidently includes all types but should be easy to
>> generate only based on the leaf ones if necessary.
>
> Having extra types doesn't bring any benefit that I can see but is
> fairly harmless (it may just slow down ever so slightly a few method
> dispatches, when we have a miss in the method cache).

Mmmmh, I tried:

=======
--- a/lisp/emacs-lisp/cl-preloaded.el
+++ b/lisp/emacs-lisp/cl-preloaded.el
@@ -117,8 +117,12 @@ cl--supertypes-for-typeof-types
     (cl--supertypes-for-typeof-types-rec type)
     (merge-ordered-lists cl--supertypes-lanes-res)))

+(defun cl--type-leaf-p (type)
+  (null (assq type cl--type-hierarchy)))
+
 (maphash (lambda (type _)
-           (push (cl--supertypes-for-typeof-types type) cl--typeof-types))
+           (when (cl--type-leaf-p type)
+             (push (cl--supertypes-for-typeof-types type) cl--typeof-types)))
          cl--direct-supertypes-of-type)

 (defconst cl--all-builtin-types
======

This generates as 'cl--typeof-types':

((subr-primitive subr function atom)
 (subr-native-elisp subr function atom)
 (module-function function atom)
 (byte-code-function compiled-function function atom)
 (cons list sequence)
 (null list sequence boolean symbol atom)
 (string array sequence atom)
 (char-table array sequence atom)
 (bool-vector array sequence atom)
 (vector array sequence atom)
 (keyword symbol-with-pos symbol atom)
 (fixnum integer number number-or-marker integer-or-marker atom)
 (bignum integer number number-or-marker integer-or-marker atom)
 (marker number-or-marker integer-or-marker atom)
 (float number number-or-marker atom)
 (obarray atom)
 (overlay atom)
 (window-configuration atom)
 (process atom)
 (window atom)
 (buffer atom)
 (frame atom)
 (hash-table atom)
 (terminal atom)
 (thread atom)
 (mutex atom)
 (condvar atom)
 (font-spec atom)
 (font-entity atom)
 (font-object atom)
 (user-ptr atom)
 (tree-sitter-parser atom)
 (tree-sitter-node atom)
 (tree-sitter-compiled-query atom)
 (structure atom)
 (class atom))

Which looks okay to me at a first glance, but make check explodes 🤷...
I might be doing something wrong.

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

>>> The original was inconsistent on this,
>> Maybe that was an oversight.
>> Do you remember which inconsistency you had noticed in this respect?
> I remember (symbol-with-pos symbol atom) (symbol atom), there might have
> been others.

I think I see.  By "leaf" I really meant "non abstract": both `symbol`
and `symbol-with-pos` describe *the* type of some objects (IOW `type-of`
can return that symbol), as opposed to things like `sequence`, `list`,
atom`, `number-or-marker`, ...

> This generates as 'cl--typeof-types':
>
> ((subr-primitive subr function atom)
>  (subr-native-elisp subr function atom)
>  (module-function function atom)
>  (byte-code-function compiled-function function atom)
>  (cons list sequence)
>  (null list sequence boolean symbol atom)
>  (string array sequence atom)
>  (char-table array sequence atom)
>  (bool-vector array sequence atom)
>  (vector array sequence atom)
>  (keyword symbol-with-pos symbol atom)
>  (fixnum integer number number-or-marker integer-or-marker atom)
>  (bignum integer number number-or-marker integer-or-marker atom)
>  (marker number-or-marker integer-or-marker atom)
>  (float number number-or-marker atom)
>  (obarray atom)
>  (overlay atom)
>  (window-configuration atom)
>  (process atom)
>  (window atom)
>  (buffer atom)
>  (frame atom)
>  (hash-table atom)
>  (terminal atom)
>  (thread atom)
>  (mutex atom)
>  (condvar atom)
>  (font-spec atom)
>  (font-entity atom)
>  (font-object atom)
>  (user-ptr atom)
>  (tree-sitter-parser atom)
>  (tree-sitter-node atom)
>  (tree-sitter-compiled-query atom)
>  (structure atom)
>  (class atom))
>
> Which looks okay to me at a first glance, but make check explodes 🤷...

I see that `symbol` is missing there.  Don't know if that's why it
explodes, OTOH.

Better keep a few extra useless entries in there.


        Stefan

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

>>>> The original was inconsistent on this,
>>> Maybe that was an oversight.
>>> Do you remember which inconsistency you had noticed in this respect?
>> I remember (symbol-with-pos symbol atom) (symbol atom), there might have
>> been others.
>
> I think I see.  By "leaf" I really meant "non abstract": both `symbol`
> and `symbol-with-pos` describe *the* type of some objects (IOW `type-of`
> can return that symbol), as opposed to things like `sequence`, `list`,
> atom`, `number-or-marker`, ...

Ah!  Mmmh then is not so simple...

>> This generates as 'cl--typeof-types':
>>
>> ((subr-primitive subr function atom)
>>  (subr-native-elisp subr function atom)
>>  (module-function function atom)
>>  (byte-code-function compiled-function function atom)
>>  (cons list sequence)
>>  (null list sequence boolean symbol atom)
>>  (string array sequence atom)
>>  (char-table array sequence atom)
>>  (bool-vector array sequence atom)
>>  (vector array sequence atom)
>>  (keyword symbol-with-pos symbol atom)
>>  (fixnum integer number number-or-marker integer-or-marker atom)
>>  (bignum integer number number-or-marker integer-or-marker atom)
>>  (marker number-or-marker integer-or-marker atom)
>>  (float number number-or-marker atom)
>>  (obarray atom)
>>  (overlay atom)
>>  (window-configuration atom)
>>  (process atom)
>>  (window atom)
>>  (buffer atom)
>>  (frame atom)
>>  (hash-table atom)
>>  (terminal atom)
>>  (thread atom)
>>  (mutex atom)
>>  (condvar atom)
>>  (font-spec atom)
>>  (font-entity atom)
>>  (font-object atom)
>>  (user-ptr atom)
>>  (tree-sitter-parser atom)
>>  (tree-sitter-node atom)
>>  (tree-sitter-compiled-query atom)
>>  (structure atom)
>>  (class atom))
>>
>> Which looks okay to me at a first glance, but make check explodes 🤷...
>
> I see that `symbol` is missing there.  Don't know if that's why it
> explodes, OTOH.
>
> Better keep a few extra useless entries in there.

Ok agree

Thanks

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

>>>>> The original was inconsistent on this,
>>>> Maybe that was an oversight.
>>>> Do you remember which inconsistency you had noticed in this respect?
>>> I remember (symbol-with-pos symbol atom) (symbol atom), there might have
>>> been others.
>> I think I see.  By "leaf" I really meant "non abstract": both `symbol`
>> and `symbol-with-pos` describe *the* type of some objects (IOW `type-of`
>> can return that symbol), as opposed to things like `sequence`, `list`,
>> atom`, `number-or-marker`, ...
> Ah!  Mmmh then is not so simple...

It's not complicated either, but I guess what you mean is that the DAG
doesn't have enough info, and there I can I agree (which is why in the
previous code we generated the DAG from `cl--typeof-types` instead of
the reverse 🙂).


        Stefan

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Andrea Corallo]

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

>>>>>> The original was inconsistent on this,
>>>>> Maybe that was an oversight.
>>>>> Do you remember which inconsistency you had noticed in this respect?
>>>> I remember (symbol-with-pos symbol atom) (symbol atom), there might have
>>>> been others.
>>> I think I see.  By "leaf" I really meant "non abstract": both `symbol`
>>> and `symbol-with-pos` describe *the* type of some objects (IOW `type-of`
>>> can return that symbol), as opposed to things like `sequence`, `list`,
>>> atom`, `number-or-marker`, ...
>> Ah!  Mmmh then is not so simple...
>
> It's not complicated either, but I guess what you mean is that the DAG
> doesn't have enough info, and there I can I agree (which is why in the
> previous code we generated the DAG from `cl--typeof-types` instead of
> the reverse 🙂).

My 2 cents.  I see `cl--typeof-types` for the nature of its non trivial
format and caveats as an internal representation that was layout-ed like
it is for some specific internal machinery.  I find more convenient how
we can express the DAG now (and generate `cl--typeof-types`
automatically from it).

  Andrea

Re: feature/type-hierarchy 8a63e50036f 1/5: * Define 'cl--type-hierarchy' and compute 'cl--typeof-types' from it

[Stefan Monnier]

>> It's not complicated either, but I guess what you mean is that the DAG
>> doesn't have enough info, and there I can I agree (which is why in the
>> previous code we generated the DAG from `cl--typeof-types` instead of
>> the reverse 🙂).
>
> My 2 cents.  I see `cl--typeof-types` for the nature of its non trivial
> format and caveats as an internal representation that was layout-ed like
> it is for some specific internal machinery.  I find more convenient how
> we can express the DAG now (and generate `cl--typeof-types`
> automatically from it).

FWIW, the old `cl--typeof-types` representation did not have all the
info necessary to generate the DAG either (at least in theory, I haven't
checked if the blind spots made a difference in practice),

I'm pretty happy with your change, if that's what you were asking :-)


        Stefan