[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Jeff Morrill: Mop comments]

Return-Path: <kanderso@DINO.BBN.COM>
Received: from DINO.BBN.COM ([]) 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>


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.  


------- End of Forwarded Message