Re: Comments on the gray book

[kanderso@DINO.BBN.COM]

  Fake-Sender: gregor@parc.xerox.com
  X-NS-Transport-ID: 08002008D0FD0003E396
  Date:	Mon, 5 Nov 1990 11:05:24 PST
  From:	Gregor Kiczales <Gregor@parc.xerox.com>
  Subject: Re: Comments on the gray book
  To:	Moon@stony-brook.scrc.symbolics.com
  cc:	mop@parc.xerox.com
  
  
  
     Date: 	Mon, 5 Nov 1990 08:25:00 PST
     From: Moon@STONY-BROOK.SCRC.Symbolics.COM
  
     One more specific comment is that although efficient implementability
     is mentioned as a design goal, I don't think the book really touches
     on what is necessary to achieve that, which in my opinion depends
     fundamentally on keeping the programmer at arm's length from the
     implementation through the use of abstraction.
  
  This is a real concern, and one which is fundamental to the value of
  this work.  Can you say a little more about what you would like us to
  say?  Your comments seem to be about both the presention (AMOP) and the
  design (MOP), but I can't distinguish the two sets of comments clearly
  enough to see what you are asking for.

Although i've only read to page 67, let me add a comment about AMOP.
I also got caught short trying to skim things, finding i have to go
back and check things out more carefully.  I don't consider it a flaw
in the manuscript, however.  I had missed the fact that method objects
had body slots.  I just assumed they have functions, i guess.  Then in
section 1.7.3 imaginary functions inside eval get called, and i start
not to feel so good.  Footnote 16 is encouraging, but it almost made we
want to go read the software in Appendix B.

I think it is OK to be a bit vague in this section since things start
to get vague by the last paragraph of page 36 when it is clear that we
are inside the funcalling mechanism when somehow
apply-generic-function gets called.  I'd rather see you defer
discussion about applying a method than see you call eval and
apologize for it.

What will C++ and Self people think if we don't make it clear that
CLOS can be implemented relatively efficiently?

k