Recent questions about CLOS

[Moon@STONY-BROOK.SCRC.Symbolics.COM (David A. Moon)]

    Date: Wed, 19 Sep 1990 10:13 EDT
    From: Robert W. Kerns <RWK@fuji.ila.com>

	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.

My point was not that people shouldn't switch to CLOS, but that if
Symbolics puts nonstandard extensions into our CLOS, few customers will
find that useful to them.  Please don't misunderstand me as saying that
one should not use CLOS or should not write portable code.

    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!

This is precisely why I feel that there is little point in Symbolics
making a CLOS which is different from the standard and would lock people
into using our CLOS exclusively.  Evidently I wasn't very articulate
yesterday since you thought I was saying the exact opposite of what I
thought I was saying.

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

One thing that I didn't manage to make clear is that this is already
fixed in Symbolics CLOS.  I was confused because from my point of view
it was fixed long ago, but from your point of view it's not fixed, since
it's not fixed in Genera 8.0.  It's fixed in Cloe 3.0 but it didn't
quite make it into Genera 8.0.1.  So from your point of view it will be
fixed in Genera 8.1.  Of course there's still some encaching work at
startup, and in relatively rare cases some compilation, but it's much
better than in 8.0.  I think this is another example of us responding
to user feedback on the first release of a product by making the second
release better.

By the way there are a couple of workarounds that help in 8.0 that I'm
sure Software Support will be happy to tell you about if you ask nicely.

    Loading is painfully slow.

It's not easy to have your cake and eat it too.  If you want running to
be fast you have to accept some overhead in loading.  That's inherent in
moving work back from run time to load time.  Of course maybe you're
complaining about something else entirely, I really can't tell.

    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.  

Exactly my point at the beginning of this conversation.

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

Well, a number of other decisions were made in CLOS and in the
metaobject protocol that make it difficult to do this at compile time.
And it doesn't really take any language extensions to do it at load
time, at least to some extent, as we do in the latest versions of
Symbolics CLOS.

    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.

The CLOS committee has finished its work and been disbanded for
a couple of years.  I think if you want something proposed it would
be best if you made a specific proposal yourself.  I'm willing to help
(let's take this conversation off the mailing lists if we do that) but
I cannot take the lead in formulating a proposal.  Propose something and
I'll help you polish it.