From: Christophe Rhodes Date: Fri, 18 Apr 2014 21:21:51 +0000 (+0100) Subject: minimal changes to address reviews from ELS 2014 reviewers X-Git-Url: http://christophe.rhodes.io/gitweb/?a=commitdiff_plain;h=ee15d0bd0cb8fbdf8a2df78090a44122eae133b3;p=paper-els-specializers.git minimal changes to address reviews from ELS 2014 reviewers --- diff --git a/els-specializers.org b/els-specializers.org index af28252..3458d0a 100644 --- a/els-specializers.org +++ b/els-specializers.org @@ -111,11 +111,12 @@ 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 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 @@ -125,7 +126,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 +176,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 +462,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 +685,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 +826,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 +931,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 @@ -951,19 +959,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 diff --git a/specializers.bib b/specializers.bib index 9ca12f0..c528d10 100644 --- a/specializers.bib +++ b/specializers.bib @@ -252,3 +252,25 @@ OPTannote = {} } +@InCollection{Paepke:1988, + author = {Andreas Paepke}, + title = "{PCLOS: A Flexible Implementation of CLOS Persistence}", + booktitle = {ECOOP '88 Conference on Object-Oriented Programming}, + OPTcrossref = {}, + OPTkey = {}, + publisher = {Springer}, + year = {1988}, + editor = {Stein Gjessing and Kristen Nygaard}, + OPTvolume = {}, + number = {322}, + series = {LNCS}, + OPTtype = {}, + OPTchapter = {}, + pages = {374--389}, + OPTedition = {}, + OPTmonth = {}, + address = {Berlin}, + OPTnote = {}, + OPTannote = {} +} +