Well, I'll risk the stake: we need MI and its ilk. So it's hard in
places - just get over it: the world is hard in places too.  Epicycles
can't hack it, in case you hadn't noticed, *however* complex you make
them.

Now that I've found

4.3.5 Determining the Class Precedence List
http://www.lisp.org/HyperSpec/Body/sec_4-3-5.html

I think that the real thing is pretty straight
forward.  Basically, the programmer lays down the
law about the order of the classes, and CLOS does
as its bloody well told.

So, (defclass bottom (a b c)) says that

bottom < a < b < c

while (defclass a (c d)) and (defclass b (c d)) say
that

a < c < d and b < c < d

There is only one way to stitch these three together

bottom < a < b < c
         a <     c < d
             b < c < d
so

bottom < a < b < c < d

I thought it would be fun to try and write some
Lisp to do this calculation.

A least element is an element such that there
is no smaller one. Since we are going to be
working with partial ordering, there could be
several such elements, so the first job is to
write a version of MIN that returns a complete
list of least elements.

;;;; Take a set, represented by a list,
;;;; and a partial order, represented by
;;;; a function, and return the list of
;;;; least elements
;;;;
;;;; (po a b) returns true when a precedes b
;;;;
(defun least-elements (set po); po = Partial Order
  (let (accumulator)
    (dolist (candidate set)
            (when (notany (lambda (other)
                            (funcall po other candidate))
                          (remove candidate set))
              (push candidate accumulator)))
    (reverse accumulator)))

The hyper-spec atomises (defclass bottom (a b c))
into { bottom<a, a<b, b<c }. I don't need to go so
far. It is enough to represent the total order on
the classes as a list (bottom a b c). The data
defining the partial order is conveniently just a
list of lists, with one list per defclass, giving
the total order it specifies on the classes it
mentions, so I extract the ordering information
from

(defclass bottom (a b c))
(defclass a (c d))
(defclass b (c d))

and store it thus

(setq ascending-chains
 '((bottom a b c)
         (a c d)
         (b c d)))

Next I need a function to compute the partial order
from the data.

;;;; The partial order is computed by searching
;;;; a list of ascending chains
(defun po (smaller larger )
  (some (lambda(ascending-chain)
          (member larger
                  (member smaller ascending-chain)))
        ascending-chains))

Notice my exploitation of the clever definition of
member whereby

(member 3 '(1 2 3 4 5 6 7)) => (3 4 5 6 7)

This is enough to hand crank Jeremy Brown's first
example

(least-elements '(bottom a b c d ) #'po) => (BOTTOM)
(least-elements '(b c d a ) #'po) => (A)
(least-elements '(b c d ) #'po) => (B)
(least-elements '(c d ) #'po) => (C)
(least-elements '(d ) #'po) => (D)

We can try this on Jeremy's second example

(setq ascending-chains '((bottom a b c)
         (a c e)
         (b c d)))

but we get stuck at the end
(least-elements '(d e) #'po) => (D E)

This is what the hyper-spec is talking about when it
says

    When the topological sort must select a class from
    a set of two or more classes, none of which are
    preceded by other classes with respect to R, the
    class selected is chosen deterministically, as
    described below.

There is a little bit more to computing class
precedence lists than just doing what the programmer
said. Sometimes there is a tie for which class comes
next and we need a tie-breaker.

First a little predicate to detect a tie:

(defun just-one-p (list)
  (if (null list)(error "Inconsistant")
    (null (cdr list))))

Then we can cons up a precedence list. The loop
start with the list of classes, and moves them,
one by one to the precedence list. It is straight
forward, unless there is a tie.

(defun precedence-list ()
  (do ((classes (reduce #'union ascending-chains)
                (remove next-one classes))
       (precedence-list () (cons next-one
                                 precedence-list))
       next-one)
      ((null classes)(reverse precedence-list))
      (let ((least-elements
             (least-elements classes
                             #'po)))
        (setf next-one
              (if (just-one-p least-elements)
                  (car least-elements)
                (tie-break least-elements
                           precedence-list))))))

First a couple of comment-functions

(defun direct-super-class-list(sub-class)
  (cdr (assoc sub-class ascending-chains)))

(defun direct-super-class-p(super-class sub-class)
  (member super-class
          (direct-super-class-list sub-class)))

I like using comments as function names. The calling
code doesn't get cluttered with comments, because it
is not cluttered with stuff requiring comments; a
double benefit.

Then the tie-break itself. The hyper-spec says

    Sometimes there are several classes from SC with
    no predecessors. In this case select the one that
    has a direct subclass rightmost in the class
    precedence list computed so far.

To find the rightmost subclass, we pass in the
reverse of the precedence list. So the formal
parameter gets named "rev-prec-list", and the
call

(tie-break least-elements precedence-list)

is correct, because the do-loop in "precedence-list"
is consing it up in reverse order.

(defun tie-break (super-classes rev-prec-list)
  (dolist (sub-class rev-prec-list)
    (dolist (super-class super-classes)
      (if (direct-super-class-p super-class sub-class)
          (return-from tie-break super-class))))
  (error "Not a partial ordering"))

Now we can do example 1

(let ((ascending-chains
       '((bottom a b c)
         (a c d)
         (b c d))))
      (precedence-list)) => (BOTTOM A B C D)

and example 2

(let ((ascending-chains
       '((bottom a b c)
         (a c e)
         (b c d))))
      (precedence-list)) => (BOTTOM A B C D E)

The hyper-spec has

Examples of Class Precedence List Determination
http://www.lisp.org/HyperSpec/Body/sec_4-3-5-2.html

(defclass pie (apple cinnamon) ())
(defclass apple (fruit) ())
(defclass cinnamon (spice) ())
(defclass fruit (food) ())
(defclass spice (food) ())
(defclass food () ())

Which we can also do

(let ((ascending-chains
       '((pie apple cinnamon)
         (apple fruit)
         (cinnamon spice)
         (fruit food)
         (spice food)
         (food))))
  (precedence-list))
=> (PIE APPLE FRUIT CINNAMON SPICE FOOD)

If your answer is "the more sophisticated tool" [and below I see perhaps it
is an open question to you], consider for a moment what it is like to tackle
an interesting problem with a tool /insufficent/ to the complexity of the
application. Hell on wheels, yes? And the deeper you get into the problem,
and as the application gets extended to satisfy requirements, you simply
reach deeper levels of hell, yes?

Now we know you have not taken the trouble to learn CLOS, but you might
concede that that would be a finite task, and one requiring not a descent
into hell, but rather a little perserverance and practice (as opposed to
pure spec reading). The effort of learning a tool has an upper bound, the
pain of using an insufficient tool does not.

So maybe we are back at /your/ limitations: inexperienced, uninformed,
unread. Funny thing is, if you had had the decency to say upfront that you
were clueless and /ask questions/, your "feel the love" remark would have
been heartfelt and not sarcasm; folks would have just helped you.

    1. A class always has precedence over its superclasses.
    2. Each class definition set the precedence order of its
       direct superclasses.

So you write your code with these simple rules in mind. I think
worrying too much about CPL before coding is not productive.
Actually, whether you define a class foo such that:

    (defclass foo (a b) ...) or
    (defclass foo (b a) ...)

I am quite busy at the moment, so I only throw a few thoughts into the
discussion.

Pascal

Michael, I like hacking unlambda

CL's reference to "real" is in the "REALPART" function, which does
something 'honest' with complex numbers.

I guess this stuff gets confusing...but I'm not really advocating
Python; I'm advocating the way Jython provided an implementation of
Python, and in doing so, also provided an easier way to get to the JVM
and Java libraries.  That's all.

Incidentally, here's a line of thought as to why I (and others) start
out intimidated by CL/CLOS.  There's two kinds of knowledge: knowing
something, and knowing where to look something up.  (This says nothing
about knowing how to use that knowledge well, of course.)

Between the Hyperspec, widely-available CL/CLOS implementations, etc.,
a bit of familiarization is probably enough to create the second kind
of knowledge pertty quickly.  What some of us have (unfortunately)
come to expect from experience with languages such as C, Scheme, and
Java[*] is that with respect to the core of the language, at least,
the transition from the latter type of knowledge to the former type is
a relatively short, and relatively complete process.  

Those of us with this expectation --- however dumb it may be --- are
then spooked when we realize early on that (a) the language core for
CL is significantly larger than for these other languages, and (b)
CPL, at least, is part of the core that one may never completely move
into the former class of knowledge.  

So, there you have it, a theory of why some of us have an
emotional/visceral reaction: violated/unrealistic expectations.

[*] Actually, if people want to pick on Java for having unknown and
unknowable corners, I would recommend they start with the
threading/synchronization/memory model.  See, for instance,
http://csg.lcs.mit.edu/pubs/memos/Memo-428/memo-428.pdf
I think most Java programmers remain blissfully unaware of this
attrocity.

------

Upon rereading it now, I'm struck by how it contains many statements
likely to frighten newbies away from CL, e.g. "We've seen that the
right thing attitude has brought us a very large,
complex-to-understand, and complex-to-implement Lisp -- Common Lisp
that solves way too many problems," or "In Lisp it is very easy to
write programs that perform very poorly; in C it is almost impossible
to do that."  And this from a master of the language!

I wonder how many university students get their first taste of lisp
with this paper and go off to learn C/C++ and UNIX without ever
looking back.  I imagine this one paper scares away more people than a
dozen newbies like me saying "CL [or CLOS] is hard, let's go shopping."

Gabriel himself seems to have wandered back and forth a lot as to
where he actually stands on the matter; the whole, fascinating saga,
-- including debating himself in papers written under assumed names! --
is described at http://www.dreamsongs.com/WorseIsBetter.html

------

------

------

------

 o it runs on just about every platform...probably even more portable
   than CLISP (it basically runs wherever there's a working gcc).

This was the last item in your list of advantages of Python over CL.
All the other advantages were common to both the Java-based version
(Jython) and the C-based version, but as written the above is specific
to the C-based version.  If you had never mentioned the above
advantage and written Jython everywhere (i.e. ignored the original
C-based version of Python completely) then I would not have commented
on this point at all.

I am curious as to whether my posting my code helped anyone
else. I hope to write some intermediate level tutorials to
help other persons learn Common Lisp. If it is the case that
writing code oneself helps, but reading other persons code
doesn't help, then I have an alternative way of presenting
the subtleties of precedence list computation. It uses lots
of single inheritance classes to create a striking visual
pattern and give the account some narrative drive. Here is
my first draft of the end of my tutorial:

######## start of draft of end of tutorial ############

CLOS goes all the way up, before it goes right

(progn
  (defclass fs5()())
  (defclass fs4(fs5)())
  (defclass fs3(fs4)())
  (defclass fs2(fs3)())
  (defclass fs1(fs2)())
  (defclass first-stack(fs1)())
  (defclass ss5()())
  (defclass ss4(ss5)())
  (defclass ss3(ss4)())
  (defclass ss2(ss3)())
  (defclass ss1(ss2)())
  (defclass second-stack(ss1)())
  (defclass stack-base (first-stack second-stack)())
)

Editing the output of CMUCL to bring out the pattern

(pcl:class-precedence-list (find-class 'stack-base)) =>
(#< STACK-BASE >
 #< FIRST-STACK >
 #< FS1 >
 #< FS2 >
 #< FS3 >
 #< FS4 >
 #< FS5 >
 #< SECOND-STACK >
 #< SS1 >
 #< SS2 >
 #< SS3 >
 #< SS4 >
 #< SS5 >
 #< STANDARD-OBJECT >)

See, it has gone all the way up the first stack of
classes, and only then moved onto the second.

But it will not violate local precedence, so ...

(progn
  (defclass fs5()())
  (defclass fs4(fs5)())
  (defclass fs3(fs4)())
  (defclass fs2(fs3)())
  (defclass fs1(fs2)())
  (defclass first-stack(fs1)())
  (defclass ss5()())
  (defclass ss4(ss5)())
  (defclass ss3(ss4)())
  (defclass ss2(ss3)())
  (defclass ss1(ss2)())
  (defclass second-stack(ss1)())
  (defclass nuisance(fs3)())
  (defclass stack-base (first-stack
                        second-stack
                        nuisance)())
)
(pcl:class-precedence-list (find-class 'stack-base)) =>

(#< STACK-BASE >
 #< FIRST-STACK >
 #< FS1 >
 #< FS2 >
 #< SECOND-STACK >
 #< SS1 >
 #< SS2 >
 #< SS3 >
 #< SS4 >
 #< SS5 >
 #< NUISANCE >
 #< FS3 >
 #< FS4 >
 #< FS5 >
 #< STANDARD-OBJECT >)

... it is blocked on `fs3' by `nuisance', and moves
on to doing the second stack of classes, before
coming back and finishing the first stack.

Now we can make mischief. I've taken the `nuisance'
class out of `stack-base', and moved it so that
it annoys `main', a class that inherits from
`stack-base'

(progn
  (defclass fs5()())
  (defclass fs4(fs5)())
  (defclass fs3(fs4)())
  (defclass fs2(fs3)())
  (defclass fs1(fs2)())
  (defclass first-stack(fs1)())
  (defclass ss5()())
  (defclass ss4(ss5)())
  (defclass ss3(ss4)())
  (defclass ss2(ss3)())
  (defclass ss1(ss2)())
  (defclass second-stack(ss1)())
  (defclass stack-base (first-stack second-stack)())
  (defclass nuisance(fs3)())
  (defclass main(stack-base nuisance)())
)

Now, as you see from

(pcl:class-precedence-list (find-class 'stack-base)) =>
(#< STACK-BASE >
 #< FIRST-STACK >
 #< FS1 >
 #< FS2 >
 #< FS3 >
 #< FS4 >
 #< FS5 >
 #< SECOND-STACK >
 #< SS1 >
 #< SS2 >
 #< SS3 >
 #< SS4 >
 #< SS5 >
 #< STANDARD-OBJECT >)

the precedence list for `stack-base' does all of the
first stack, followed by all of the second stack.

Meanwhile

(pcl:class-precedence-list (find-class 'main)) =>
(#< MAIN >
 #< STACK-BASE >
 #< FIRST-STACK >
 #< FS1 >
 #< FS2 >
 #< SECOND-STACK >
 #< SS1 >
 #< SS2 >
 #< SS3 >
 #< SS4 >
 #< SS5 >
 #< NUISANCE >
 #< FS3 >
 #< FS4 >
 #< FS5 >
 #< STANDARD-OBJECT >)

shows that `main' has been affliced by `nuisance'.
Its class precedence list has to break off from
enumerating the first stack of classes, do the second
stack of classes and finish off `fs3', `fs4',
and `fs5' after `nuisance'. The classes in the
second stack have jumped into the middle of the
enumeration of the first stack of classes. This could
be a major shock to the programmer who wrote
`stack-base', and stop the class working when it
is subclassed in this way.

########## end of draft of end of tutorial ############

My main qualification for writing tutorials is that I am
learning Lisp myself. Thus I an intimately acquainted with
the confusions that assail and distress newbies. Although
this is a valuable qualification, it is has
disadvantages. In particular I will be depending on the
members of this list to catch my technical errors. This
worries me. There is plenty of enthusiasm for spotting
technical errors in short postings put directly on
comp.lang.lisp. However, if I write some lengthy tutorials,
etiquette will require that I put them on my website and
post the URL to the list. Are there enough folk willing to
follow a link, read a long tutorial and then point out the
technical errors?

  Excellent example.

| My main qualification for writing tutorials is that I am learning Lisp
| myself.  Thus I an intimately acquainted with the confusions that assail
| and distress newbies.

  The problem with this is that you meet these things in a totally random
  order.  The point of a tutorial is to make order of the chaos.  I am
  fairly strongly convinced that the best way to make that order is to be
  very knowledgeable and very observant when you try to teach a lot of
  people the same material and have time to follow up on them to see how
  they do and to correct your own mistakes.  Hence I am extremely doubtful
  of teaching material that has been written by other than teachers and
  much prefer to fight my way through reference works when I have enough
  glimpses of the order to at least not get lost in the chaos.  However, as
  a shining example of an excellent instruction on CLOS that helped me sort
  out the order of the dense specification, Sonya Keene's book only gets
  higher commendations from me as time goes on while the misnamed «ANSI
  Common Lisp» by Paul Graham gets lower.

| There is plenty of enthusiasm for spotting technical errors in short
| postings put directly on comp.lang.lisp.  However, if I write some
| lengthy tutorials, etiquette will require that I put them on my website
| and post the URL to the list.  Are there enough folk willing to follow a
| link, read a long tutorial and then point out the technical errors?

  People who did you this kind of service deserve to be co-authors at the
  very least.  But when you do this, you implicitly argue that none of the
  existing material is good enough and ask people who may think it is
  better than yours to help make yours better than everything else.  This
  may be a tall order.  I doubt that you want to make this argument
  explicitly, however, so I instead wonder what tutorials and other works
  on CLOS you have read before you decided to write your own tutorial.

--
Erik Naggum, Oslo, Norway

I have programmed CL for about seven years now and twice developed GUI
frameworks in which I beat on multiple-inheritance like I was its daddy, and
until this silly thread came up (1) i did not know the algorithm and (2) i
never got surprised by how a class's CPL panned out (in generic function
dispatch and other manifestations of the CPL). Mind you, I regularly get
myself into a knot with a god-forsaken hierarchy and /then/ I get surprises,
but by then I have been aware for a while that I needed to refactor the
whole mess and the surprise just pushes me over the edge (unless I kludge a
workaround).

When I look at published examples which manifest CPL surprises, they are
thoroughly unconvincing semantically. As in, screw the CPL, lose that
hierarchy! That's OK for those papers since they just want to show that
surprises are avoidable, so all that matters is that they show a corner case
which a beter algorithm can handle without surprises. But such stuff does
not impact real-world development, and being able to intuit the CPL over the
keyboard is a real-world development concern, so as far as me being able to
/intuit/ the CPL over the board -- why?

As has been my experience, I wager any real world surprise will appear only
in a class hierarchy needing fixing anyway, which will eliminate the
surprise. (Yes, this is a Challenge.)

As for /intuiting/  how (defclass a (b c)()) will pan out, that is not going
to happen anyway. Any case hairy enough to produce a surprise will require
some scratch paper and a pencil to work out, even with a surpriseless
algorithm. For one thing, the source for the defclass forms of b and c
likely will not be at hand.

Bottom line: this is not a newbie concern, this is not even a concern for a
seasoned CLOS developer. it's just a curiosity.

(defclass c (d e)())

and ended by computing the class precedence list for his
most specific class as ...e...d...

That just had to be wrong, because CLOS always respects the
local ordering; d will always come before e, whenever c is
amongst the superclasses.This felt to me like a bug in the
book the poster had been studying.

Part I: Bring out the importance of the local order implied
by the list of superclasses.

Ia Typically the set of superclasses is only partially
ordered by the local orderings of the direct superclasses.

Ib Typically each generic function is defined on a proper
subset of the set of superclasses.

Ic Typically a generic function is defined on a subset of
the superclasses that /is/ totally ordered by the local
orderings. So for each generic function, one can work out
the applicable method, without needing a total ordering on
the superclasses.

Teach the skill of using the local orderings to find
applicable methods on a generic function by generic function
basis.

Part II: Sometimes a generic function is defined on a subset
of the superclasses that is only partially ordered by the
local orderings.

Teach suspicion. Why is the code getting so complicated?
Does the application push the programmer to write such
subtle code, or is the programmer letting the code get in a
tangle, with complications not inherent in the application?

Perhaps there is a conceptual error in the design of the
program and there are really two generic functions. Give
them different names, and watch the problem vanish.

Part III: Sometimes one really does need to know CPL.

But not often, so go away and write some code, and come back
if you need to.

Grandparents before uncles

That covers most cases, so go away and write some more code,
and come back again if you need to.

Finish half done classes before going on to new ones

How the algorithm accomplishes this

Non-monotonicity.

  Standard book practice is for the most knowledgeable people to write the
  book and for reviewers to be at approximately the same level of general
  expertise, but not vastly superior to the author in specific expertise.

  I have reviewed books that were published and manuscripts for books that
  I recommended against publishing.  I have reviewed graduate and doctorate
  theses and advised students at both levels in specific areas.  People
  have called on my expertise in this fashion for more than 10 years.  I
  have worked with and in the publishing industry and have written four
  chapters on a book on SGML (with an incredibly helpful copy-editor that
  taught me more about English than years of study) that was not published
  because writing it caused me to decide to leave the field because it was
  impossible for me to work with such an inferior technical solution --
  something I had glossed over while I only helped people understand its
  more complicated points.  I am still credited in several books on SGML
  for having helped the authors both understand points better and for
  suggesting improvements to their writing.  Never have I seen a book
  published by a novice for novices, nor heard of such a thing, but that
  does not mean it does not exist -- the likelihood that I would purchase
  it or read it is zero, as it would undoubtedly have an off-putting title
  and cover, probably including the target audience "dummies" or "the
  complete idiot".  I recently reviewed a book in which the author could
  only be understood to apologize for his lack of mastery of the subject
  when he chatted endlessly about how hard it was to linearize the material
  and where he used more promises of what was to come and repetitions of
  what he had discussed than actual new information in each paragraph, how
  this and that feature in the topic he discussed "is not easy" to use and
  understand.  It was torture to read and try to lift it to some readable
  level.  I was quite handsomely rewarded for my effort but the book may
  never be published.  I think I speak with some authority on how reviewers
  are treated.

  When the reviewer has done much of the writing, or coaching, or even
  education of the author, the reviewers deserve to be named co-authors.  I
  quite firmly stand by this.  I know book publishing, and your tutorial
  is, with all due respect a tutorial on the Net, not a published book.

| >   But when you do this, you implicitly argue that none of the
| >   existing material is good enough
|
| This inference is invalid.

  No, it most certainly is a valid inference.  Such terminology belongs to
  the realm of logic, and logic is concerned with structure of the argument,
  not with the truth of its premises.  An inference does not become invalid
  simply because you disagree with parts of it.  Acquire precision!

| The merit of a tutorial is a function of the student.

  What a odd statement.

| There is no uncontroversial ordering.  The strongest inference to be
| drawn directly from my desire to write my own tutorials is that I do not
| believe that all tastes are fully catered for.

  Which even more strongly suggests that you enumerate what you have
  already read and, with no small amount of irony, explain why you are
  still a "newbie" in your own eyes.

--
Erik Naggum, Oslo, Norway

Now, 24 years later, I have a prompt to type at, for the
first time. I find that I am no better at herding brackets
than the distressed teenage newbies who sometimes post on
this list, but I am learning much faster, because I have
overcome analogous difficulties many times before. I should
write about taming the paren panther, the fierce funcall,
and the dangerous defvar now, while the wounds are
healing. In a year's time, the scars will have faded, and I
will no longer remember what made it seem so hard at the
time.

I find "The Little Lisper" a pretty tedious for a beginner, even
though it's short.

Maybe one of the reasons that C has been so successful is K&R: not too
long, but complete and very readable.

I had a chance to work with an older gentleman who had never used a
computer.  In less than six months he progressed (with minimal
coaching from me -- I can't claim success  :) to installing Debian
Testing on his machine.  It was interesting to see the things that
were causing him trouble.

What's the best raw beginner book on Common Lisp?  Or maybe its not a
suitable beginner's language?