Recent questions about CLOS

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

    Date: Wed, 19 Sep 1990 11:12-0400
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	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.  

I understand, but I disagree.  In this instance at
least, you don't seem to have a good grasp of what
the real issues are for porting.  Us writers and
porters of code are not at all phazed by this kind
of thing, since #+/#- and macros & such work so
well.

			       Please don't misunderstand me as saying that
    one should not use CLOS or should not write portable code.

I never interpreted you as saying that; rather that porting is
the only "real" reason to want to use CLOS.  That's what my list
of points was in rebuttal to.

	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.

But that would not be the effect of the kind of thing we're talking
about.  It would *NOT* lock people into using your CLOS exclusively.
It would merely allow them to use your CLOS more effectively.  The
difference is very important.

It's important to realize that we're talking about optimizations,
not new semantic features, and that we're talking about additions,
not differences or missing pieces.

Your reply here indicates that your heart is in the right place,
but you seem to substitute the dogma "just the standard, ma'am,
just the standard", instead of "do the standard, very well,
supported with the best tools."

	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.  

Thanks for the info; I'm sure many people are very
glad to hear this.  Communicating stuff like this
helps us all; thanks!

			 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.
Yes, indeed.  Again, thanks for the preview.

    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.
Thanks!

	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.

It seems that CLOS moves less stuff from load time
to compile time than Flavors did, and I felt that
Flavors often did not do as much as it should in
this regard.

I certainly do prefer doing things at load time to
doing them at run time; don't get me wrong.  I just
view it as an intermediate step; it's better for
loading to be fast, too, and I'll pay compilation
time to get it.

This is much less important than the run-time stuff,
and I'm glad to see you've focused primarily on the
runtime performance for 8.1.

	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.
Ah, we agree, good.  Too bad the point's moot
now!

    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 didn't mean to imply that the formal CLOS committee should
be brought back from the dead.  I just meant that the members
of the committee have necessary expertise.

						       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.
I would, except I just don't know enough of what the issues
with the meta-protocol are that you refer to.  I know they
exist, but not the specifics.