[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Class Precedence List
- To: RPG@SAIL.STANFORD.EDU
- Subject: Re: Class Precedence List
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 8 Jan 87 23:41 PST
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 08 Jan 87 20:01 PST
- Sender: Bobrow.pa@Xerox.COM
[Danny's] algorithm gives primacy to the preorder treewalk, and
there is a question about whether the algorithm terminates - though
it's actually easy to prove if the algorithm is stated clearly -
and about how the error condition is computed.
This primacy is good I claim, because in the simple (and usual) case it
describes the result of the sort. It is primary in how people will try
to simulate the algorithm. There is no question about whether the
algorithm terminates, or the error condition (though perhaps it would be
more clearly stated in terms of the partial order). How does the
topological sort algorithm state the error condition about loops?
EXAMPLE 2(not repeated here)
admits a single possibility by his rules, which is
(pie apple fruit cinnamon spice food)
Not by my interpretation of his rules (not including the Flavors extra
rule about superclasses). Why determines the order of fruit and spice?
What determines the order in your algorithm except the preorder.
I also propose that implementations be encouraged to offer a
means of warning or signalling an error every time that appeal is
made to the preorder.
Again this is the usual case where one has independent mixins with
superclasses. So no warning please.
By the way, this DAG is not a lattice in that there is no "meaningful"
lower bound for any two classes. But I believe we have agreed on a top
of T in any event.
So my conclusion is that your description is a good mathematical one,
and should be included. Mine is a good operational one, and should be
included. And both agree with Moon's algorithm with the other Flavors
rule, so we are all right.
danny