Recent questions about CLOS

[RWK@fuji.ila.com (Robert W. Kerns)]

    Date: Tue, 18 Sep 1990 18:58-0400
    From: Moon@stony-brook.scrc.symbolics.com (David A. Moon)
	Can I expect to see an equivalent in CLOS in Genera sometime?

    The committee that defined CLOS wasn't interested in putting in
    optimizations like ordered-instance-variables or compile-flavor-methods.
    I don't think we want to put a lot of nonstandard extensions into Genera
    CLOS, after all, there's no real reason to convert from Flavors to CLOS
    if you aren't going to port your code.  And if you are going to port
    your code, nonstandard extensions don't do you any good.  Therefore I
    would think the answer is no; this is not a commitment on the part of
    Symbolics, of course.

I'm disappointed in you.  I think this attitude is
completely off base, in terms of anticipating the
needs of the customers.  There are *many* reasons to
switch to CLOS.  And even non-standard extensions help.

0)  Familiarity.  Future Lisp programmers will be conversant
    with CLOS, not Flavors (old or new).  This means future
    Symbolics customers, including those you'd like to win
    away from other vendors.

1)  Security.  Even if you don't plan on porting, people
    prefer not to be locked into one vendor, just in case.
    By now, you should have gotten this message, (from DW
    if for no other reason), so I'm a bit shocked to see
    your response!

2)  Multi-methods.  At first, I didn't think these were
    important for most real programs.  I was wrong, and I
    use them all the time now.

3)  CLIM.  Even if you don't plan to port, you might want
    to use CLIM, and not have to deal with two object systems.

4)  Future portability.  Most successful code will someday
    be faced with the issue of porting to other platforms.

5)  Current portability.  Even for code that you plan to port
    immediately, Genera-specific optimizations can still have
    great merit.  Just because you're going to port it doesn't
    mean that it's not ALSO going to continue to run on Genera!
    At least, that should be your goal.  Providing enhancements
    to ensure a Genera performance advantage should be a
    critical strategic goal for Symbolics.

    Or has Symbolics completely ceded the delivery market?

Right now, having to compile constructors, etc.
greatly slows down starting up of CLIM applications.
Loading is painfully slow.

I know, the same is true under PCL, but a
COMPILE-FLAVOR-METHODS-style enhancement is in
order.  Actually, this particular bit of
functionality *SHOULD* have been addressed by the
committee; they just didn't have enough experience
with the practical usage of CLOS to know it.  I'd
like to see the CLOS committee propose a portable
enhancement here.  (Lazy or tardy implementations
can always leave these things as NOOP's, so there
shouldn't be a lot of resistance, once a suitable
design is chosen).

Even if different implementations do it differently,
it's still possible to hide the differences with
macrology, so don't let "non-portability" deter you
from providing the feature.