From: Christophe Rhodes Date: Sun, 9 Mar 2014 19:54:53 +0000 (+0000) Subject: responses to comments from Pascal Costanza X-Git-Url: http://christophe.rhodes.io/gitweb/?a=commitdiff_plain;h=6c1b9b6701486283493c9d7c0ea56bf3d62c122d;p=paper-els-specializers.git responses to comments from Pascal Costanza Also include goldsmiths' eprint report number for future Open Accessish experiments --- diff --git a/els-specializers.org b/els-specializers.org index 74b2649..af28252 100644 --- a/els-specializers.org +++ b/els-specializers.org @@ -54,6 +54,9 @@ efficient. #+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} @@ -72,14 +75,15 @@ efficient. 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 @@ -170,8 +174,8 @@ efficient. 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 @@ -457,7 +461,7 @@ unbound variables. 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 @@ -599,20 +603,22 @@ unbound variables. 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 @@ -641,13 +647,13 @@ unbound variables. 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= @@ -812,7 +818,7 @@ unbound variables. 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 @@ -917,7 +923,7 @@ unbound variables. 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 @@ -933,7 +939,7 @@ unbound variables. 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} @@ -950,6 +956,14 @@ unbound variables. 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