[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Progress is Our Most Important Problem
- To: RPG@SAIL.STANFORD.EDU
- Subject: Re: Progress is Our Most Important Problem
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 29 Jan 87 09:38 PST
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 28 Jan 87 19:32 PST
- Sender: Bobrow.pa@Xerox.COM
1. We are still arguing over CPL computation. When I asked Ken
Olum to tell me what he thought about the possible algorithms for
it he said he simply tried things in New Flavors until they worked.
He said a good model is that there is some sort of algorithm and
you don't try to understand it. Then he ran out of the room. Now
that I've beaten everyone's brains out on the issue, I think we can
happily settle on topological sort with last-visited preorder as
The differences are now so small I don't care between B-K and this. I
think explainability is paramount. I think my algorithm is explainable
simply (e.g. as a local constraint satisfaction algorithm that modifies
last-visited tree walk). It does not refer to Knuth though, which has
2. I'm inclined to go with Moon's method combination for now,
though some of Danny's simplifications are attractive.
I really don't want to see two define-method-combination forms. Do you
say this because you are tired and don't want to think (argue) through
the issues on this, or what? I would like to see Moon's comments on my
latest suggestions. As I said, the only real issue is the lambda-list.
I don't really care if we have documentation/declarations in the
defmacro way, and don't mind seeing as Moon proposed:
(1) Make it a method-group keyword option. Thus you say
((around (:around) :call-next-method t)
...other method groups...)
What happens if other method-groups have :call-next-method t
We could abbreviate the above as in.
((:around t) ... other method groups...)
thus assuring it can appear only once in the list, implicitly with
:around as the group specifier. It is really short, so users will
probably do it, and get it right. However this mixes syntax for
Let us argue through lambda-list, have a single
define-method-combination and I will edit the rest into the consensus.
3. I don't care about the change-class protocol as long as it
We seem to have agreement here.
4. I'd like to flush :allocation :dynamic and :allocation
:none. If people want :allocation :none, then the inheritance
writeup needs work. (Sonya?)
I still think both are useful, but the one I have had lots of experience
with is :dynamic. I want to keep :dynamic that even if :none goes away.