unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Andrea Corallo <acorallo@gnu.org>
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: Fri, 20 Oct 2023 16:51:54 -0400	[thread overview]
Message-ID: <jwv1qdp590y.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <yp1cyx9l2r1.fsf@fencepost.gnu.org> (Andrea Corallo's message of "Fri, 20 Oct 2023 11:42:10 -0400")

> (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`).


        Stefan






  reply	other threads:[~2023-10-20 20:51 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 [this message]
2023-10-22  7:03                     ` Andrea Corallo

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=jwv1qdp590y.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=66615@debbugs.gnu.org \
    --cc=acorallo@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).