🚀 go-pugleaf

An interesting (at least to me), semi-philosphical question is 
this: exactly what is the constribution of the MOP?

There's talk, in the AMOP book and other places, about how a MOP
breaks down the distinction between programmers and language
designers; but the same can be said of Lisp itself.  (For an
instance of where it has been said, see McCarthy's paper in
the 1980 Lisp Conference.)

There's also some talk about the MOP letting you combine
customizability with efficiency, but that's also a goal in
plain Lisp.  It's why we have compiler macros and the like.

What we might do in ordinary Lisp is this, there would be a
set of "good primitives", new ways of doing things would be
defined as functions, and compiler macros could be used to
tell the compiler how to compile them efficiently.

Unfortunately, the "good primitives" are often missing.  (Eg,
look at all the people who want a bit more control over DEFSTRUCT.)
The main thing the MOP provides (imho) is a set of good primitives
in a certain area.  The main things it fails to provide (as yet)
is a way to tell the compiler what it needs to know.

-- jd