[Jeff Morrill: Mop comments]

[kanderso@DINO.BBN.COM]

Return-Path: <kanderso@DINO.BBN.COM>
Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 21 AUG 90 10:30:56 PDT
Original-Date: Tue, 21 Aug 90 13:55:04 -0400



------- Forwarded Message

Return-path: jmorrill@bbn.com
Date: Tue, 21 Aug 90 12:35 EDT
From: Jeff Morrill <jmorrill@BBN.COM>
Subject: Mop comments
To: kanderson@BBN.COM
Cc: jmorrill@BBN.COM, delatizky@BBN.COM
Message-ID: <19900821163502.1.JMORRILL@adams.bbn.com>

Ken,

I have looked over the draft CLOS Mop Specification,
and here are a couple of comments you may want to
pass along.

What is the status of slot optimization?  I lamented
the removal of methods like deoptimize-slot-access, and
I don't see any "specified" way to deoptimize now.  
Clearly the use of slot-value-using-class is very important 
to those who program at the meta level, and I have been 
accustomed to deoptimizing SLOT-VALUE as the accepted 
procedure for getting slot-value-using-class to run.

Symbolics' current Mop implementation doesn't appear to
have anything like deoptimize-slot-access either.  This
makes me concerned that each vendor will have their
own twist to defining the relationship between slot-value,
slot-value-using-class, and the compiler.  It is useful
if not necessary to portable programs to be able to control
compiler optimizations using meta behavior.

For now I have TWO versions of slot-value (in two different
packages):  1) the "real" slot-value, that always gets
optimized and only sometimes calls slot-value-using-class, 
and 2) my own slot-value, that always calls
slot-value-using-class and never gets optimized.  

jeff

------- End of Forwarded Message