Re: Progress is Our Most Important Problem

[Danny Bobrow <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 tiebreaker.

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
status. 

    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
specifiers (ugh).

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
    works.

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.



  danny