From: Andrea Corallo <acorallo@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Mattias Engdegård" <mattias.engdegard@gmail.com>, 66615@debbugs.gnu.org
Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery
Date: Sun, 22 Oct 2023 03:03:19 -0400 [thread overview]
Message-ID: <yp18r7vkuko.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <jwv1qdp590y.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 20 Oct 2023 16:51:54 -0400")
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
prev parent reply other threads:[~2023-10-22 7:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 17:59 bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Andrea Corallo
2023-10-18 18:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-19 8:56 ` Andrea Corallo
2023-10-19 12:02 ` Andrea Corallo
2023-10-19 14:22 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-19 21:24 ` Andrea Corallo
2023-10-19 22:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-20 9:05 ` Andrea Corallo
2023-10-20 13:45 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-20 15:42 ` Andrea Corallo
2023-10-20 20:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-22 7:03 ` Andrea Corallo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yp18r7vkuko.fsf@fencepost.gnu.org \
--to=acorallo@gnu.org \
--cc=66615@debbugs.gnu.org \
--cc=mattias.engdegard@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).