#+end_abstract
#+begin_LaTeX
+\begin{flushleft}
+Report-No.:~\url{http://eprints.gold.ac.uk/id/eprint/9924}
+\end{flushleft}
\category{D.1}{Software}{Programming Techniques}[Object-oriented Programming]
\category{D.3.3}{Programming Languages}{Language Constructs and Features}
\terms{Languages, Design}
final standard; the third chapter, covering a Metaobject Protocol
(MOP) for CLOS, was not.
- Nevertheless, the CLOS MOP has proven to be a robust design, and
- while many implementations have derived their implementations of
- CLOS from either the Closette illustrative implementation in
- \cite{AMOP}, or the Portable Common Loops implementation of CLOS
- from Xerox Parc, there have been largely from-scratch
- reimplementations of CLOS (in CLISP[fn:1] and CCL[fn:2], at least)
- incorporating substantial fractions of the Metaobject Protocol as
- described.
+ Nevertheless, the CLOS MOP continued to be developed, and the
+ version documented in \cite{AMOP} has proven to be a reasonably
+ robust design. While many implementations have derived their
+ implementations of CLOS from either the Closette illustrative
+ implementation in \cite{AMOP}, or the Portable Common Loops
+ implementation of CLOS from Xerox Parc, there have been largely
+ from-scratch reimplementations of CLOS (in CLISP[fn:1] and
+ CCL[fn:2], at least) incorporating substantial fractions of the
+ Metaobject Protocol as described.
#+CAPTION: MOP Design Space
#+LABEL: fig:mopdesign
this section do not include some of the necessary support code to
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 an appendix / in
- the accompanying repository snapshot / at this location.
+ \cite{Rhodes:2008} of Common Lisp, are included in the authors'
+ repository[fn:4].
A note on terminology: we will attempt to distinguish between the
user of an individual case of generalized dispatch (the
The metaprogrammer can then add support for objects representing
client requests, such as instances of the =request= class in the
- Hunchentoot web server, by translating these into
+ Hunchentoot[fn:5] 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
The new =compute-applicable-methods-using-generalizers= is the
analogue of the MOP's =compute-applicable-methods-using-classes=.
- Instead of calling it with the =class-of= each argument, we compute
- the generalizers of each argument using the new function
+ Instead of calling it with the =class-of= each argument, we
+ compute the generalizers of each argument using the new function
=generalizer-of-using-class= (where the =-using-class= refers to
the class of the generic function rather than the class of the
- object), and call it with the list of generalizers. As with the
- standard function, a secondary return value indicates whether the
- result of the function is definitive for that list of generalizers.
+ object), and call =compute-applicable-methods-using-generalizers=
+ with the generic function and list of generalizers. As with
+ =compute-applicable-methods-using-classes=, a secondary return
+ value indicates whether the result of the function is definitive
+ for that list of generalizers.
Thus, in generic function invocation, we first compute the
generalizers of the arguments; we compute the ordered set of
applicable methods, either from the generalizers or (if that is
not definitive) from the arguments themselves; then the normal
effective method computation and call can occur. Unfortunately,
- the nature of an effective method object is not specified, so we
+ the nature of an effective method function is not specified, so we
have to reach into implementation internals a little in order to
call it, but otherwise the remainder of the generic function
invocation protocol is unchanged from the standard one. In
One issue is what to use as the key for that cache. We cannot use
the generalizers themselves, as two generalizers that should be
considered equal for cache lookup will not compare as =equal= –
- and indeed even the standard generalizer, the =class=, cannot be
- used as we must be able to invalidate cache entries upon class
- redefinition. The issue of =class= generalizers we can solve as
- in \cite{Kiczales.Rodriguez:1990} by using the =wrapper= of a
- class, which is distinct for each distinct (re)definition of a
- class; for arbitrary generalizers, however, there is /a priori/ no
- good way of computing a suitable hash key automatically, so we
+ and indeed even the standard generalizer, the =class=, cannot
+ easily be used as we must be able to invalidate cache entries upon
+ class redefinition. The issue of =class= generalizers we can
+ solve as in \cite{Kiczales.Rodriguez:1990} by using the =wrapper=
+ of a class, which is distinct for each distinct (re)definition of
+ a class; for arbitrary generalizers, however, there is /a priori/
+ no good way of computing a suitable hash key automatically, so we
allow the metaprogrammer to specify one by defining a method on
=generalizer-equal-hash-key=, and combining the hash keys for all
required arguments in a list to use as a key in an =equal=
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:5] with a variant of filtered dispatch as
+ supports multimethods[fn:6] 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:4], and over
+ such as implemented in the \textsf{Optima} library[fn:7], 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
backwards-incompatible fashion.
** Acknowledgments
We thank Lee Salzman, Pascal Costanza and Mikel Evins for helpful
- and informative discussions, and all the respondents to one
+ and informative discussions, and all the respondents to the first
author's request for imaginative uses for generalized specializers.
\bibliographystyle{plain}
different implementations of the metaobject protocol in Common
Lisp.
-[fn:4] https://github.com/m2ym/optima
+[fn:4] 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] http://clojure.org/multimethods
+[fn:5] 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:7] https://github.com/m2ym/optima
projects / paper-els-specializers.git / commitdiff