GNU bug report logs - #67008
30.0.50; Multiple major mode parents

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 67008 <at> debbugs.gnu.org, Ikumi Keita <ikumi <at> ikumi.que.jp>, Yuan Fu <casouri <at> gmail.com>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#67008: 30.0.50; Multiple major mode parents
Date: Sun, 12 Nov 2023 11:41:35 -0500

>> Having read a bit further, I'm now not sure that `merge-ordered-lists`
>> implements C3.  I suspect it provides a useful primitive with which to
>> implement C3 but whether it gives the same result as C3 or not depends
>> on how we call it.
> Yes, the output seems very sensitive about the input order:
>
>  (B A) (C A) (D B) (E D C) -> (E D B C A)
>
>  (E D C) (B A) (C A) (D B) -> (E D C B A)

Yes, that's on purpose: when the dependencies expressed by the
(sub)lists don't enforce a unique solution, the order between the
(sub)lists is used to choose between the available options.

> Maybe that's obvious for someone who knows how to use it.

I improved the docstring to try and clarify.

> It could probably be used as a general-purpose topo-sorter but it's not
> a very efficient one (at least quadratic, possibly cubic).

Also it doesn't start from a graph but from a lists of lists (because
for uses in method inheritance it's very desirable that the ordering be
"monotonic": if A comes before B in the linearization of class C's
parents then the same should be true in the linearization of all its
subclasses).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.