Just looked at an alternative to CLOS class linearization to determine the
class precedence list, link provided by Bruce Hoult:
http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
i grok the difference (i think), and at first glance Dylan's seemed better
because it avoids (pardon a non-professional's butchering) a subclass having
a precedence in which A precedes B though for some superclass B precedes A.
Working with the Pedalo example as my template, I came up with:
(defclass bottom (zero one)...
(defclass zero (a b) ....
(defclass one (a)...
[a and b: no declared superclass]
I think CLOS comes out to : bottom < zero < b < one < a. Notice that the cpl
for bottom reverses
the order of a and b in that of zero, from which bottom inherits. I am
curious
what the motivation for that might be (whether or not it was considered by
the designers.)
Dylan comes out to: bottom < zero < one < a < b. A design goal was
monotonicity, a word I still dont understand except that it /might/ have
something to do with always only either increasing or decreasing. Anyway,
they wanted to stamp out class-specific precedence relationships (my
reading).
I like the Dylan clean-up, but does it have a cost or flaw or something?
I tried to think up a decent interpretation of the CLOS "cp flip", to coin a
name.
How's this: A precedes B in their embodiment of zero, but in the overall
constitution of bottom, A is tainted by association with one, which is
preceded by zero, whereas B's role in bottom is unconfused by any
association with some lower precedence ancestor between it and bottom.
I need a beer.
Well, do I have the issues right? What do other folks think about the
Dylan/CLOS cpl difference?
kenny
clinisys
Tim Bradshaw wrote in message ...
>* Kenny Tilton wrote:
>
>> I like the Dylan clean-up, but does it have a cost or flaw or something?
>
>I *think* that it's a pure win.
OK, thx.
btw, it has been pointed out to me that my attempted reduction of the pedalo
example ended up removing the cp-flip anomaly (gotta go back and look at the
algorithm again to see how it goes "wrong"). This is the full pedalo
example, abbreviated:
> (defclass boat ()())
> (defclass db (boat)())
> (defclass wb (boat)())
> (defclass el (db)())
> (defclass sm (db)())
> (defclass pwb (el wb)())
> (defclass sc (sm)())
> (defclass ped (pwb sc)())
> (finalize-inheritance (find-class 'ped))
> (find-class 'ped)
> (clos:class-precedence-list *)
(#<STANDARD-CLASS PED> #<STANDARD-CLASS PWB> #<STANDARD-CLASS EL>
#<STANDARD-CLASS WB> #<STANDARD-CLASS SC> #<STANDARD-CLASS SM>
#<STANDARD-CLASS DB> #<STANDARD-CLASS BOAT>
#<STANDARD-CLASS STANDARD-OBJECT> #<BUILT-IN-CLASS T>)
>
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * Kenny Tilton wrote:
>
> > I like the Dylan clean-up, but does it have a cost or flaw or something?
>
> I *think* that it's a pure win.
As far as I can see. CLOS doesn't use it because CLOS has been around
for longer and by now there is no doubt far too much software that
relies on it to change.
-- Bruce
From: Tim Bradshaw
Subject: Re: Dylan vs CLOS class-precedence-list linearization
Date:
Message-ID: <ey365w45b3q.fsf@cley.com>
* Bruce Hoult wrote:
> As far as I can see. CLOS doesn't use it because CLOS has been around
> for longer and by now there is no doubt far too much software that
> relies on it to change.
I think it's worse than that. I heard (from someone who was on J13,
and who is still *very* strongly anti-Dylan, so this isn't some kind
of CL/Dylan propaganda thing) that it was known that there were issues
with CLOS's linearization before CLOS was standardized, and thus
before there was much CLOS code around, but nothing was done for
reasons which are obscure to me. It may be that it wanted to be
compatible with Flavors - for which there obviously was a lot of code
- although I'm not sure if it actually is. This is all repeating what
I was told at 2nd hand, for which I apologise (I could check the
original source if anyone cares, although there are enough people here
(Barry Margolin?, Kent Pitman?) who were also there that I probably
don't need to).
Incidentally, although I think that CLOS's linearization is not as
good as Dylan's, I think the times when it matters are fairly
obscure. In particular it clearly wouldn't be enough of a win to
change it now (although opening up enough MOP so that users could
change it if they wanted would be a win...).
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> Incidentally, although I think that CLOS's linearization is not as
> good as Dylan's, I think the times when it matters are fairly
> obscure.
I think that's probably true.
Actually, if people wanted to change it might not affect all *that* much
code, and it's the sort of thing where you could easily hack the new
algorithm into compilers, not actually use the result, but (optionally)
print out warning messages if the new and old linearizations differ.
We've got a related problem in the Dylan world: multiple argument method
linearization. The Dylan spec says that in deciding which of two
methods is more specific argument order doesn't matter and ambiguous
situations are an error. In the same situation I understand that CLOS
gives more weight to more leftmost arguments. Harlequin Dylan in fact
implements the CLOS rule. Mostly I think because they based quite a lot
of code on CLOS code that depended on this -- certainly DUIM (derived
from CLIM) does. Gwydion Dylan implements the Dylan rule and spits out
a lot of warning messages at compile time when compiling DUIM.
-- Bruce
From: Tim Bradshaw
Subject: Re: Dylan vs CLOS class-precedence-list linearization
Date:
Message-ID: <ey3wuok3ufw.fsf@cley.com>
* Bruce Hoult wrote:
> We've got a related problem in the Dylan world: multiple argument method
> linearization. The Dylan spec says that in deciding which of two
> methods is more specific argument order doesn't matter and ambiguous
> situations are an error. In the same situation I understand that CLOS
> gives more weight to more leftmost arguments.
Actually, CLOS has user-definable argument precedence order, with the
default being left to right. I quite often define `MAPCAR-like' GFs
like:
(defgeneric map-x (fn ob &key ...)
(:argument-precedence-order ob fn)
...)
since OB is the thing I really want to dispatch on. Of course, since
I never specialise on FN at all this really makes no difference, but
...
--tim
In article <···························@copper.ipg.tsnz.net>, Bruce
Hoult <·····@hoult.org> wrote:
>In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
>wrote:
>
>> Incidentally, although I think that CLOS's linearization is not as
>> good as Dylan's, I think the times when it matters are fairly
>> obscure.
>
>I think that's probably true.
And it's impossible to be intuitive for all hierarchy graphs
because some graphs have no intuitive solution, i.e., one that
preserves all the precedences. Of course, there can always be a
well-defined solution.
If anyone is interested, I tried to summarize these issues
as I understood them a few years ago, in the context of an AI
class where inheritance hierarchies are also important, at
http://www.cs.nwu.edu/academics/courses/c25/readings/inheritance.html
"Kenny Tilton" <·······@nyc.rr.com> writes:
> (defclass bottom (zero one)...
> (defclass zero (a b) ....
> (defclass one (a)...
> [a and b: no declared superclass]
>
> I think CLOS comes out to : bottom < zero < b < one < a. Notice that the cpl
> for bottom reverses
Is that so? 4.3.5 says
| The defclass form for a class provides a total ordering on that class
| and its direct superclasses. This ordering is called the local
| precedence order. It is an ordered list of the class and its direct
| superclasses. The class precedence list for a class C is a total
| ordering on C and its superclasses that is consistent with the local
| precedence orders for each of C and its superclasses.
|
| A class precedes its direct superclasses, and a direct superclass
| precedes all other direct superclasses specified to its right in the
| superclasses list of the defclass form.
If the second quoted paragraph is about the local precedence order, a
must precede b in the CPL of bottom, in order for it to be consistent
with the local precedence order of zero.
Andras
Simon Andr�s wrote in message ...
>"Kenny Tilton" <·······@nyc.rr.com> writes:
>
>
>> (defclass bottom (zero one)...
>> (defclass zero (a b) ....
>> (defclass one (a)...
>> [a and b: no declared superclass]
>>
>> I think CLOS comes out to : bottom < zero < b < one < a. Notice that the
cpl
>> for bottom reverses
>
>Is that so? 4.3.5 says
>
>| The defclass form for a class provides a total ordering on that class
>| and its direct superclasses. This ordering is called the local
>| precedence order. It is an ordered list of the class and its direct
>| superclasses. The class precedence list for a class C is a total
>| ordering on C and its superclasses that is consistent with the local
>| precedence orders for each of C and its superclasses.
>|
>| A class precedes its direct superclasses, and a direct superclass
>| precedes all other direct superclasses specified to its right in the
>| superclasses list of the defclass form.
>
>If the second quoted paragraph is about the local precedence order, a
>must precede b in the CPL of bottom, in order for it to be consistent
>with the local precedence order of zero.
That might be where I screwed up. I left out a seemingly unnecessary layer
(shoulda known it was there for a reason) and got tripped up. I'll stare at
this some more, but I believe from my reading of the Dylan algorithm that
the key is that the linearization in CLOS is not applied recursively. ie, it
is not the linearizations of the direct superclasses that get sort-merged,
it is an algorithm that works from the local precedence orders of the
superclasses, and hence the surprising results. I'll know better once I work
out the full Pedalo example in detail.
Sorry for the screwup.
kenny
clinisys
"Kenny Tilton" <·······@nyc.rr.com> writes:
> Just looked at an alternative to CLOS class linearization to determine the
> class precedence list, link provided by Bruce Hoult:
>
> http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
>
> i grok the difference (i think), and at first glance Dylan's seemed better
> because it avoids (pardon a non-professional's butchering) a subclass having
> a precedence in which A precedes B though for some superclass B precedes A.
>
> Working with the Pedalo example as my template, I came up with:
>
> (defclass bottom (zero one)...
> (defclass zero (a b) ....
> (defclass one (a)...
> [a and b: no declared superclass]
>
> I think CLOS comes out to : bottom < zero < b < one < a. Notice that the cpl
> for bottom reverses
> the order of a and b in that of zero, from which bottom inherits. I am
> curious
> what the motivation for that might be (whether or not it was considered by
> the designers.)
Which CL did you try this on?
On Allegro CL:
CL-USER(1): (defclass a () ())
#<STANDARD-CLASS A>
CL-USER(2): (defclass b () ())
#<STANDARD-CLASS B>
CL-USER(3): (defclass zero (a b) ())
#<STANDARD-CLASS ZERO>
CL-USER(4): (defclass one (a) ())
#<STANDARD-CLASS ONE>
CL-USER(5): (defclass bottom (zero one) ())
#<STANDARD-CLASS BOTTOM>
CL-USER(6): (make-instance 'bottom)
#<BOTTOM @ #x7148c66a>
CL-USER(7): (mop:class-precedence-list (find-class 'bottom))
(#<STANDARD-CLASS BOTTOM> #<STANDARD-CLASS ZERO> #<STANDARD-CLASS ONE>
#<STANDARD-CLASS A> #<STANDARD-CLASS B>
#<STANDARD-CLASS STANDARD-OBJECT> #<BUILT-IN-CLASS T>)
CL-USER(8):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote in message <·············@beta.franz.com>...
>"Kenny Tilton" <·······@nyc.rr.com> writes:
>
>> Just looked at an alternative to CLOS class linearization to determine
the
>> class precedence list, link provided by Bruce Hoult:
>>
>> http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
>>
>> i grok the difference (i think), and at first glance Dylan's seemed
better
>> because it avoids (pardon a non-professional's butchering) a subclass
having
>> a precedence in which A precedes B though for some superclass B precedes
A.
>>
>> Working with the Pedalo example as my template, I came up with:
>>
>> (defclass bottom (zero one)...
>> (defclass zero (a b) ....
>> (defclass one (a)...
>> [a and b: no declared superclass]
>>
>> I think CLOS comes out to : bottom < zero < b < one < a. Notice that the
cpl
>> for bottom reverses
>> the order of a and b in that of zero, from which bottom inherits. I am
>> curious
>> what the motivation for that might be (whether or not it was considered
by
>> the designers.)
>
>Which CL did you try this on?
My neural simulator. But its newly-acquired CPL algorithm was faulty. My
bad.
kenny
clinisys