The Lupine M2 project will design an MOF M2 Metamodel for modeling of program components developed in ANSI Common Lisp.

The Lupine M2 metamodel will be designed around a modular concept, such that should include a metamodel module for modeling of programs extending the Common Lisp MetaObject Protocol (MOP). The Lupine M2 project may also design a module for modeling CLIM applications.

Overview

MOF provides a framework for definition of metamodels, such that provide structures for models in specific domains. MOF itself comprises a model for metamodels - a meta-metamodel, in some conventional parlance. Metamodels extending MOF include UML, SysML, and CWM.

The MOF modeling framework may be denoted as defining four effective tiers for modeling:

• M3: MOF
• M2: Metamodels such as UML, SysML, and CWM
• M1: Models, such as may be developed with UML modeling tools
• M0: Instance data, as from programs, system components, database tables, or otherwise objects within the domain of a single metamodel

The concept of applying UML for modeling of Common Lisp program components may present some challenges for the modeling expert. UML may be viewed as it being designed around a programmatic syntax and semantics fundamentally disjunct from the syntax and semantics of Common Lisp programs - from the simplest matters of functional syntax, to the nature of the object system itself. Some concerns include:

• Common Lisp defines a function class, but UML does not provide a UML metaclass for functions
• Common Lisp programs may be defined in such a regards that the selection of a CLOS metaclass for a CLOS class would be a significant feature of the program, and should therefore be illustrated in any visual models of the program, but UML itself does not define an exacting way for illustrating the metaclass of a program class (M0) with a model (M1)
• The Common Lisp type system, as defined in ANSI CL, represents some complexity among the distinctions of types, system classes, built in classes, and condition types, such that may not appear any less complex when the features of the Common Lisp object system must be modeled
• The functionality available with CLOS methods may effectively define a superset of the functionality that may be modeled with operations in UML - those being used, typically, to model class methods for programming languages like C++ and Java(r). CLOS methods may need their own higher-order model stereotypes, in order to illustrate features such as method specialization, method lambda list syntax, a method's metaclass, and a method's relation to its containing generic function
• The different types of lambda list syntax for procedures in Common Lisp must require some specific consideration, for modeling of program components having such syntax
• Similar to the matter of method definitions, CLOS class definitions may present some level of complexity for purposes of modeling in UML, such as at the level of a CLOS class' metaclass and metaclass properties (so far as may use slots of the metaclass, perhaps in a manner reminiscent of tagged values for stereotypes in UML, though in the Lupine M2 metamodel, those properties may be modeled as directly contained of the containing metaclass), and the slot definitions of a CLOS class, itself. Again, the model becomes more complex, when MOP is considered as in regards to the distinction of direct slot definitions and effective slot definitions, etc.
• The metamodel must allow for the extensibility of CLOS and MOP program elements, essentially to adapt to the semantics of extensional object models

In consideration of the disjunction between Common Lisp syntax and the abstract syntax of UML, this project will define an M2 metamodel for modeling of ANSI Common Lisp programs - including those extending MOP - as for a purpose of supporting model-oriented engineering in applications of the Common Lisp platform.

Design Discussions

• Modeling Common Lisp Generic Functions