opening it up with Common Lisp

Favorite weblogs

Lisp Related

Bill Clementson

Finding Lisp

Lemonodor

Lispmeister.com

Planet Lisp

Politics

Orcinus

Talking Points Memo

This Modern World

Working for Change

Other home

Polliblog

Recent Readings

Book review: Darwinia
Reviewed: Friday, August 11, 2006

Summer reading: Spin
Reviewed: Saturday, August 5, 2006

Runner
Reviewed: Tuesday, July 18, 2006

the Omnivoire's Delimma
Reviewed: Wednesday, July 12, 2006

the Golem's Eye
Reviewed: Wednesday, May 31, 2006





tinderbox

What a metaobject protocol based compiler can do for Lisp
Gregor Kiczales, John Lamping and Anurag Mendhekar, 0 , (Paper URL)
Tuesday, August 3, 2004

Compiler macros are a simple way to give a compiler advice about better ways to generate code; declarations and pragmas are another. In this ancient paper Kiczales et. al. outline a third that aims significantly higher. A metaobject protocol exposes a framework for some section of a system such that users can tune this section in different ways. The classic MOP book talks about expanding a language from a single point to an entire region of design space. The CLOS MOP provides mechanisms to adjust the allocation and behavior of objects so that, for example, one can efficiently implement both tiny objects with few slots and massive ones with more slots that any one would care to think about. The point is not being able to have big and little objects in the same system (anyone can do that!). The point is that these big and little objects can both be efficiently managed in the same system — a much harder proposition.

The compiler MOP presented here is a prototype attempt to do the same thing for a scheme compiler: let programmers extend and tune portions of the language protocols consistently, safely and efficiently. MOPs let a programmer have and eat their cake; they can mold the language to suit their needs without a loss in efficiency. This molding goes beyond the level of macros. Macros let you express things more succinctly and effectively but they do not change the fundamentals of the language. MOPs, on the other hand, actually let you stick your hands into the guts of the implementation and make adjustments to what goes on inside the box. A good MOP lets you make these adjustments without losing your hand!

This paper is clearly early work and work that has mostly been abandoned (by Kiczales at least) in favor of aspects (and, horrors, Java). Nonetheless, it shows the potential of the approach with good examples and motivation. There is also a nice summary of related work and pointers to what needs to be done.

My own opinion is that MOP work like this needs to be combined with effective IDEs and with Artificial Intelligence classification and expert-like systems in order to put together a programming environment that adapts to the programmers and helps make order of of chaos. Such a project would be a major research effort but its benefits could be extreme.


Home | About | Quotes | Recent | Archives

Copyright -- Gary Warren King, 2004 - 2006