Re: define-method-combination

[kempf@Sun.COM]

>On the other hand, as long as I've been using lisp machines (up to this
>very day) I've encountered combined methods which weren't caught at
>compile-time.  So I suppose we should say that we would have Flavors as
>existence proof in principle...

Unfortunately, I suspect that you may be right about this. However, I don't
necessarily believe that this makes user defined method combination types
useless. Certainly, for prototype or experimental code, where performance
is not as critical, they should be useful. And CLOS has been designed
with the needs of experimentalists in mind. There may even be some
applications which don't mind having a full evaluator or compiler around.
In fact, how many Lisp applications run today *without* a full evaluator
or compiler around (rhetorical question, very few I suspect).

>I realize that CLOS is only specifying semantics, but why make things
>harder than they need be, so hard they they need a Sufficiently Smart
>Compiler Sufficiently Useful Magic-Unspecified-Declarations/
>Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
>(For years there has been talk about sufficiently smart compilers taking
>all of my troubles away, but I've yet to see evidence of such things.)

When somebody manages to convince a funding agency like DARPA that 
research on advanced Lisp compilers is important, it will happen. 
Until then, forget it. Lots of people have plenty of ideas about 
how to make Lisp compilers Sufficiently Smart, unfortunately, maintenance
of existing compilers, addition of features (like multiprocessing) and
environmental support have taken precedence in the commercial field,
because that is what customers are asking for. The way things are 
currently going, we should be happy if a product quality CLOS is
available within a reasonable amount of time, and I'm not talking about
the technical side of implementing it.

>My overall fear is that this sort of approach will create two classes of
>programs -- those which use the system's predefined method combination
>types and standard method definition (such as defmethod with
>:method-class standard-method) and those which use anything else.  The
>first class of programs can expect a much higher level of support than
>the latter, because the compiler has been taught special tricks.  I like
>to think that one of the aims of CLOS in general (though Chapter 3-style
>specifications) is to expose as much of the underlying works as is
>necessary to allow non-`standard' classes/method-combination/etc to be
>able to expect a level of support which is at least of the same order of
>magnitude as that provided by the system.  This certainly does not seem
>to be the case with user-defined method-combination types.

This is a goal, however, there is a real question of how much the
underlying works can be exposed without constraining the implementation
so much that the standard system defined generic functions and method
combinations can't be compiled efficiently. Unless someone does an
existence proof, it is unlikely that we will really know, because a
paper specification might miss something important. After having tuned
up PCL, I know that the level of metaobject support in PCL can be implemented
very efficiently on stock hardware, however, the version of PCL I used
didn't have method combination, much less user defined method combination.
Of course, any attempt to add additional features invalidates the existence
proof.

>I guess Scheme has gone badly to my brain -- the mere hint of run-time
>evaluation/compilation makes me feel ill (the symptoms are flames coming

More importantly for commercial purposes, C++. That's the competition.
While it is unlikely that we will be able to get performance comparible
to C++ on the first round, given your Sufficiently Smart compiler, it
should be possible to approach it. Whether a Sufficiently Smart CLOS
compiler happens, however, is again a question of priorities. 


		jak