X-Git-Url: http://christophe.rhodes.io/gitweb/?p=paper-els-specializers.git;a=blobdiff_plain;f=els-specializers.org;h=d9b66cf7c23e3d83e68274bf46a2a631e33fba54;hp=6af13922e89061170f1e4e46ca20a85379664924;hb=5773631f063cdbe16e0880ce21c73cb0b911789c;hpb=528a37d55e475944ecbe497c3ea16f8b569abbbb

diff --git a/els-specializers.org b/els-specializers.org
index 6af1392..d9b66cf 100644
--- a/els-specializers.org
+++ b/els-specializers.org
@@ -48,6 +48,10 @@
   Paepke; AMOP?].  XXX include typical examples of MOP: object
   persistence; maybe ref. Kizcales "MOPs: why we want them and what
   else they can do"? (Fig. 2 in that is good) ORMs; sparse slots.
+  jmoringe:
+  + introspection, e.g. documentation generation
+  + programmatic construction of classes and generic functions
+    e.g. for IDL compilers, model transformations
 
   One area of functionality where there is scope for customization by
   the metaprogrammer is in the mechanics and semantics of method
@@ -59,6 +63,8 @@
   practice implementation support for this was weak until relatively
   recently (ref. closer, also check how ContextL and filtered dispatch
   are implemented).
+  jmoringe: filtered dispatch uses a custom method combination, i
+  think
 
   Another potential mechanism for customizing dispatch is implicit in
   the class structure defined by AMOP: standard specializer objects
@@ -78,7 +84,12 @@
   (ahem) the return value of =class-of=, and allows the metaprogrammer
   to hook into cacheing schemes to avoid needless recomputation of
   effective methods for sufficiently similar generic function
-  arguments.
+  arguments (See Figure\nbsp\ref{fig:dispatch}).
+
+  #+CAPTION:    Dispatch Comparison
+  #+LABEL:      fig:dispatch
+  #+ATTR_LATEX: width=0.9\linewidth float
+  [[file:figures/dispatch-comparison.pdf]]
 
   The remaining sections in this paper can be read in any order.  We
   give some motivating examples in section XX, including
@@ -127,7 +138,7 @@
 (defmethod specializer-accepts-p ((s cons-specializer) o)
   (and (consp o) (eql (car o) (%car s))))
 
-#| less interesting methods elided |#
+#| less interesting methods elided: jmoringe: (un)parsing, specializer<?, more? |#
 
 #| XXX insert motivating example from Newton/Rhodes here |#
 #+end_src
@@ -186,9 +197,14 @@
    specializer could be applicable to any given argument)
 
    Also of interest: note that we can have these
-   specializer/generalizers handle arbitrary objects: the string and
-   tbnl:request methods are independent of each other; this
+   specializer/generalizers handle arbitrary objects: the =string= and
+   =tbnl:request= methods are independent of each other; this
    generalizes to dealing with multiple web server libraries.
+
+   jmoringe: the name =accept-specializer=, while sensible, may
+   confusing in this context because "accept" occurs as part of the
+   protocol with a different semantic.
+
 #+begin_src lisp
 (defclass accept-specializer (extended-specializer)
   ((media-type :initarg :media-type :reader media-type)))
@@ -198,7 +214,7 @@
    (next :initarg :next :reader next)))
 (defmethod generalizer-equal-hash-key
     ((gf accept-generic-function) (g accept-generalizer))
-  `(accept-generalizer ,(header g)))
+   `(accept-generalizer ,(header g)))
 (defmethod specializer-accepts-generalizer-p ((gf accept-generic-function) (s acc
 ept-specializer) (generalizer accept-generalizer))
   (values (q (media-type s) (tree generalizer)) t))
@@ -235,12 +251,18 @@ est))
 (defmethod specializer-accepts-p ((s accept-specializer) (string string))
   (q (media-type s) (parse-accept-string string)))
 #+end_src
+
+   jmoringe: The role of =accept-generalizer.tree= and the =q=
+   function are hard to understand and may require some
+   explanation. However, the example with its distinct, asymmetric
+   specializers/generalizers, =accept-generalizer.next= and
+   =specializer<= is likely worth it.
+
 ** Pattern / xpattern / regex / optima
    Here's the /really/ interesting bit, but on the other hand we're
    probably going to run out of space, and the full description of
-   these is going to take us into make-method-lambda territory.  A
-   second paper?  Future work?  It would be really nice to put a
-   marker in the sand.
+   these is going to take us into =make-method-lambda= territory.
+   A second paper?  Future work?
 * Protocol
 ** Generalizer
    - [ ] =generalizer-of-using-class= (NB class of gf not class of object)
@@ -249,12 +271,41 @@ est))
    - [ ] =specializer-accepts-generalizer-p=
    - [ ] =specializer-accepts-p=
    - [ ] =specializer<=
+     jmoringe: If I remember correctly, closette has
+     =method-more-specific-p= should we aim for parity with that and
+     use =specializer-more-specific-p=? The downside would be that
+     =-p= indicates a Boolean return value which is not the case here.
 ** Full protocol
    Description and specification left for reasons of space (we'll see?)
    - [ ] =same-specializer-p=
    - [ ] =parse/unparse-specializer-using-class=
    - [ ] =make-method-specializers-form=
+   - [ ] jmoringe: In an email, I suggested
+     =make-specializer-form-using-class=:
+
+     #+begin_quote
+     Could we change =make-method-specializers-form='s default
+     behaviour to call a new generic function
+     #+begin_src
+       make-specializer-form-using-class gf method name env
+     #+end_src
+     with builtin methods on =sb-mop:specializer=, =symbol=, =cons= (for
+     eql-specializers)? This would make it unnecessary to repeat
+     boilerplate along the lines of
+     #+begin_src lisp
+     (flet ((make-parse-form (name)
+              (if <name-is-interesting>
+                <handle-interesting-specializer>
+                <repeat-handling-of-standard-specializers>)))
+       `(list ,@(mapcar #'make-parse-form specializer-names)))
+     #+end_src
+     for each generic function class.
+     #+end_quote
    - [ ] =make-method-lambda= revision (use environment arg?)
+
+     jmoringe: would only be relevant for pattern dispatch, right? I
+     think, we didn't finish the discussion regarding special
+     variables vs. environment vs. new protocol function
 * Related Work
   - [ ] Newton/Rhodes
   - [ ] filtered dispatch