paper

Metaobject protocols: Why we want them and what else they can do

  • Authors:

📜 Abstract

Originally conceived as a neat idea that could help solve problems in the design and implementation of CLOS, the metaobject protocol framework now appears to have applicability to a wide range of problems that come up in high-level languages. This chapter sketches this wider potential, by drawing an analogy to ordinary language design, by presenting some early design principles, and by presenting an overview of three new metaobject protocols we have designed that, respectively, control the semantics of Scheme, the compilation of Scheme, and the static parallelization of Scheme programs.

✨ Summary

Summary

The paper presents metaobject protocols (MOPs) as a way to create open language implementations: language abstractions remain usable at a high level, while programmers can selectively customize implementation strategies and semantic behavior. The motivating examples are sparse versus dense object representations in CLOS and differences in multiple-inheritance rules between CLOS and systems such as Flavors and Loops. The authors argue that MOPs can address both performance trade-offs and semantic incompatibilities without requiring programmers to implement an entire language system from scratch.

The proposed design uses object-oriented meta-level interfaces, typically generic functions, to expose selected implementation components. The paper emphasizes locality: extensions should target individual language features, be associated conveniently with selected base-level objects or program text, alter only particular implementation strategies, and be incremental rather than requiring replacement of the full implementation. It also explains how caching, compile-time processing, and moving meta-level computation out of critical runtime paths can reduce the overhead introduced by reflective customization.

Three Scheme-oriented systems illustrate the broader applicability of the approach. Ploy exposes interpreter and binding behavior, supporting extensions such as monitored variables, dynamic variables, altered evaluation order, normal-order evaluation, and partial closures. Sartor separates compiler and runtime protocols, allowing customization of compilation decisions and runtime representations such as activation records and closure environments. Anibus applies a compile-time MOP to static parallelization, enabling programmers to define new parallelization marks and strategies.

Subsequent influence

Later research applied the same general MOP idea beyond CLOS. Chiba’s A Metaobject Protocol for C++ developed a compile-time MOP for C++, explicitly targeting extensible language features while avoiding runtime overhead; it appeared at OOPSLA 1995. (static.csg.ci.i.u-tokyo.ac.jp) A 2018 study on open meta-modelling frameworks used MOPs to extend and configure MetaDepth and the Eclipse Modeling Framework, including services not anticipated by those systems’ original designs. (repositorio.uam.es) More recently, a 2022 paper proposed MOP mechanisms for Julia, using the language’s compilation and runtime type information to support customizable multiple-inheritance dispatch and method combination with limited or zero runtime overhead. (drops.dagstuhl.de) These examples document continuing research use of the paper’s central principles—selective exposure of language implementation, user-defined semantic or compilation strategies, and performance-conscious reflective extensibility. The sources reviewed provide clear evidence of research influence; they do not by themselves establish specific industrial adoption of this chapter.