Nevertheless, the MOP is flexible, and is used for a number of
things, including: documentation generation (where introspection in
- the MOP is used to extract information from a running system);
- object-relational mapping and other approaches to object
- persistence; alternative backing stores for slots (hash-tables or
- symbols); and programmatic construction of metaobjects, for example
- for IDL compilers and model transformations.
+ the MOP is used to extract information from a running system[fn:3]);
+ object-relational mapping[fn:4] and other approaches to object
+ persistence \cite{Paepke:1988}; alternative backing stores for slots
+ (hash-tables or symbols); and programmatic construction of
+ metaobjects, for example for IDL compilers and model
+ transformations.
One area of functionality where there is scope for customization by
the metaprogrammer is in the mechanics and semantics of method
=compute-applicable-methods=,
=compute-applicable-methods-using-classes=), for example, in
practice implementation support for this was weak until relatively
- recently[fn:3].
+ recently[fn:5].
Another potential mechanism for customizing dispatch is implicit in
the class structure defined by AMOP: standard specializer objects
run; complete implementations of each of these cases, along with the
integration of this protocol into the SBCL implementation
\cite{Rhodes:2008} of Common Lisp, are included in the authors'
- repository[fn:4].
+ repository[fn:6].
A note on terminology: we will attempt to distinguish between the
user of an individual case of generalized dispatch (the
“programmer”), the implementor of a particular case of generalized
dispatch (the “metaprogrammer”), and the authors as the designers
and implementors of our generalized dispatch protocol (the
- “metametaprogammer”, or more likely “we”).
+ “metametaprogrammer”, or more likely “we”).
** CONS specializers
:PROPERTIES:
:CUSTOM_ID: Cons
The metaprogrammer can then add support for objects representing
client requests, such as instances of the =request= class in the
- Hunchentoot[fn:5] web server, by translating these into
+ Hunchentoot[fn:7] web server, by translating these into
=accept-generalizer= instances. The code below implements this, by
defining the computation of a =generalizer= object for a given
request, and specifying how to compute whether the specializer
implementations in the context of methods with regular specializers
(in an implementation similar to that in
\cite{Kiczales.Rodriguez:1990}), and with implementation in
- straightforward functions.
+ straightforward functions. We performed our benchmarks on a
+ quad-core X-series ThinkPad with 8GB of RAM running Debian
+ GNU/Linux, and took the mean of the 10 central samples of 20 runs,
+ with the number of iterations per run chosen so as to take
+ substantially over the clock resolution for the fastest case.
+ Despite these precautions, we advise against reading too much into
+ these numbers, which are best used as an order-of-magnitude
+ estimate.
In the case of the =cons-specializer=, we benchmark the walker
acting on a small but non-trivial form. The implementation
one; in principle implementors of other method combinations could
cater for filtered dispatch, but they would have to explicitly
modify their method combinations. The Clojure programming language
- supports multimethods[fn:6] with a variant of filtered dispatch as
+ supports multimethods[fn:8] with a variant of filtered dispatch as
well as hierarchical and identity-based method selectors.
In context-oriented programming
widespread demand (in as much as any language extension can be said
to be in “demand”). In particular, we have preliminary work
towards supporting efficient dispatch over pattern specializers
- such as implemented in the \textsf{Optima} library[fn:7], and over
+ such as implemented in the \textsf{Optima} library[fn:9], and over
a prototype object system similar to that in Slate
\cite{Salzman.Aldrich:2005}. Our current source code for the work
described in this paper can be seen in the git source code
[fn:2] Clozure Common Lisp, at http://ccl.clozure.com/
-[fn:3] the \textsf{Closer to MOP} project, at
+[fn:3] as in many of the systems surveyed at
+https://sites.google.com/site/sabraonthehill/lisp-document-generation-apps
+
+[fn:4] e.g. CLSQL, at http://clsql.b9.com/
+
+[fn:5] the \textsf{Closer to MOP} project, at
http://common-lisp.net/project/closer/, attempts to harmonize the
different implementations of the metaobject protocol in Common
Lisp.
-[fn:4] the tag =els2014-submission= in
+[fn:6] the tag =els2014-submission= in
http://christophe.rhodes.io/git/specializable.git corresponds to the
code repository at the point of submitting this paper.
-[fn:5] Hunchentoot is a web server written in Common Lisp, allowing
+[fn:7] Hunchentoot is a web server written in Common Lisp, allowing
the user to write handler functions to compute responses to requests;
http://weitz.de/hunchentoot/
-[fn:6] http://clojure.org/multimethods
+[fn:8] http://clojure.org/multimethods
+
+[fn:9] https://github.com/m2ym/optima
+
-[fn:7] https://github.com/m2ym/optima
projects / paper-els-specializers.git / commitdiff