[closer-devel] Pointers on MOP tradeoffs

[Pascal Costanza]

On 22 Feb 2006, at 17:26, Tayssir John Gabbour wrote:

> Hi,
>
> I'm looking to learn the tradeoffs involved in the MOP spec, as  
> well as
> possible improvements (given the strength of today's hardware). Can
> anyone point me to info on that, or perhaps a historical record of  
> what
> the MOP people did?

You may want to take a look at Tiny CLOS and its related  
announcement. They have "improved" the slot access protocol in that  
implementation. In theory, this could lead to much improved  
efficiency for user-defined slot accesses. There is also a discussion  
of this in the book "Advances in Object-Oriented Metalevel  
Architectures and Reflection", edited by Chris Zimmermann (you should  
be able to get that one for very little money from used bookstores).  
In practice, I am not aware whether this was actually carried through  
to the end, so I remain skeptical, although I now understand the  
point better, especially after having read http://www.sbcl.org/sbcl- 
internals/Slot_002dValue.html#Slot_002dValue . (I have an idea how  
something similar to what Tiny CLOS does could be achieved in  
portable CLOS MOP code, but I haven't implemented it yet...)

Another reference point is a paper about the EuLisp MOP - see http:// 
citeseer.ist.psu.edu/bretthauer92balancing.html . One important  
"advantage" described in that paper is purportedly that EuLisp has a  
pure load-time MOP - in other words, you cannot change anything about  
classes and generic functions anymore at runtime. (Including no  
redefinition of classes, for example, which in the case of CLOS is  
already part of ANSI Common Lisp.) Dylan - which doesn't specify a  
MOP - makes similar restrictions compared to plain CLOS. What you can  
often read in those documents is that the ability to redefine things  
at runtime was typically considered a development aid, but not  
something to be used in 'real' deployed programs. For some reason,  
the belief that programs should remain static has somehow carried  
over to the Lisp world at that time. (I think the real reason is that  
a load-time MOP provides more opportunities for optimizations that  
don't need to be undone anymore, compared to a runtime MOP.)

There is a paper by Crista Lopes which describes how the step from  
run-time over load-time to compile-time MOPs has finally led to the  
notion of aspect-oriented programming. It's probably true that AOP is  
more "natural" for compile-time processing than a MOP. (Especially if  
you cannot revert to macros because your language has a too irregular  
syntax to support macros well. ;) For example, the slot access  
protocol in the CLOS MOP is a runtime protocol in the sense that the  
generic functions slot-xxx-using-class have to do their dispatch at  
runtime in the general case. The slot access protocol in Tiny CLOS is  
closer to a compile-time MOP because the slot access code can be  
completely determined once and doesn't rely on a runtime dispatch,  
but it is also somewhat harder to understand, IMHO. See http:// 
www.isr.uci.edu/tech_reports/UCI-ISR-02-5.pdf for Crista Lopes's paper.

Other interesting papers are:

- http://www.cs.indiana.edu/~jsobel/rop.html which gives a nice  
account of MOPs.
- http://people.csail.mit.edu/jrb/Projects/partial-dispatch.htm which  
describes a more modern approach of generic function dispatch than  
the one used in CLOS. With more modern I mean that that approach also  
tries to cache results at call sites which CLOS implementation don't  
seem to do, but which is now pretty common for example in JVM  
and .NET runtime implementations. With regard to the CLOS MOP this is  
"interesting" because I don't see how the specified generic function  
invocation protocols could be reconciled with such an approach.

I hope this helps...


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium