X-Git-Url: http://christophe.rhodes.io/gitweb/?p=paper-els-specializers.git;a=blobdiff_plain;f=els-specializers.org;h=179120587a537442d2a49c6aff04f7de8562e8ee;hp=af28252b44881215de0ad296e3e6f799bff14455;hb=HEAD;hpb=6c1b9b6701486283493c9d7c0ea56bf3d62c122d

diff --git a/els-specializers.org b/els-specializers.org
index af28252..1791205 100644
--- a/els-specializers.org
+++ b/els-specializers.org
@@ -4,6 +4,7 @@
 
 #+LaTeX_CLASS: acm_proc_article-sp
 #+LaTeX_HEADER: \DeclareTextFontCommand{\texttt}{\ttfamily\hyphenchar\font=45\relax}
+#+LaTeX_HEADER: \renewcommand{\baselinestretch}{0.99}
 
 #+begin_src elisp :exports none
 ;;; use C-x C-e on this if org refuses to export
@@ -14,6 +15,15 @@
                ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
                ("\\paragraph{%s}" . "\\paragraph*{%s}")
                ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
+(add-to-list 'org-latex-classes
+             '("sig-alternate" "\\documentclass{sig-alternate}"
+               ("\\section{%s}" . "\\section*{%s}")
+               ("\\subsection{%s}" . "\\subsection*{%s}")
+               ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
+               ("\\paragraph{%s}" . "\\paragraph*{%s}")
+               ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
+(set (make-local-variable 'org-latex-pdf-process)
+     '("latexmk -f -pdf -bibtex %f"))
 (set (make-local-variable 'org-latex-title-command)
      "\\numberofauthors{3}
 \\author{
@@ -111,11 +121,13 @@ Report-No.:~\url{http://eprints.gold.ac.uk/id/eprint/9924}
 
   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 \cite{Kiczales.etal:1993} or symbols
+  \cite{Costanza.Hirschfeld:2005}); and programmatic construction of
+  metaobjects, for example for interoperability with other language
+  runtimes' object systems.
 
   One area of functionality where there is scope for customization by
   the metaprogrammer is in the mechanics and semantics of method
@@ -125,7 +137,7 @@ Report-No.:~\url{http://eprints.gold.ac.uk/id/eprint/9924}
   =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
@@ -175,14 +187,14 @@ Report-No.:~\url{http://eprints.gold.ac.uk/id/eprint/9924}
   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
@@ -461,7 +473,7 @@ unbound variables.
 
    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
@@ -684,7 +696,14 @@ unbound variables.
    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
@@ -818,7 +837,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: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
@@ -923,7 +942,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: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
@@ -938,8 +957,10 @@ unbound variables.
    with confidence that the semantics will not change in a
    backwards-incompatible fashion.
 ** Acknowledgments
-   We thank Lee Salzman, Pascal Costanza and Mikel Evins for helpful
-   and informative discussions, and all the respondents to the first
+   We thank the anonymous reviewers for their helpful suggestions and
+   comments on the submitted version of this paper.  We also thank Lee
+   Salzman, Pascal Costanza and Mikel Evins for helpful and
+   informative discussions, and all the respondents to the first
    author's request for imaginative uses for generalized specializers.
 
 \bibliographystyle{plain}
@@ -951,19 +972,26 @@ unbound variables.
 
 [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