- - [ ] Newton/Rhodes, \cite{Newton.Rhodes:2008}
- - [ ] filtered dispatch -- the point is that our work continues to
- be useful in cases where there are unbounded numbers of
- equivalence classes but each given invokation involves a small
- number of methods. Filtered dispatch works by having a custom
- discriminating function which wraps the usual one, and augments
- the set of applicable methods computed with applicable methods
- from other (hidden) generic functions (one per filter group). It
- then also has a custom method combination to handle combining
- these applicable methods. \cite{Costanza.etal:2008}
- - [ ] ContextL / context-oriented programming -- dispatch occurs on
- hidden layer argument being an instance of an anonymous class with
- suitably arranged superclasses -- OK because set of layers is
- bounded and under programmer control. \cite{Hirschfeld.etal:2008,Vallejos.etal:2010}
- - [ ] http://soft.vub.ac.be/Publications/2010/vub-tr-soft-10-04.pdf
- - [ ] http://soft.vub.ac.be/lambic/files/lambic-ilc09.pdf
- - [ ] http://soft.vub.ac.be/Publications/2011/vub-soft-phd-11-03.pdf
- - [ ] Prototypes with Multiple Dispatch
- http://sauerbraten.org/lee/ecoop.pdf -- extension of Self-style
- object system to handle multiple equally-privileged "receivers".
- A good test case for our protocol; handled adequately with
- generalizer being the tuple of (roles,delegations), with some
- thought needed for method redefinitions but otherwise working
- fine. \cite{Salzman.Aldrich:2005}
- - [ ] Sheeple
- - [ ] Multiple dispatch in Clojure
- http://clojure.org/multimethods -- seems to allow hierarchy-based,
- eql and the equivalent of filtered dispatch
+
+ The work presented here builds on specializer-oriented programming
+ described in \cite{Newton.Rhodes:2008}. Approximately
+ contemporaneously, filtered dispatch \cite{Costanza.etal:2008} was
+ introduced to address some of the same use cases: filtered dispatch
+ works by having a custom discriminating function which wraps the
+ usual one, where the wrapping function augments the set of
+ applicable methods with applicable methods from other (hidden)
+ generic functions, one per filter group; this step is not memoized,
+ and using =eql= methods to capture behaviours of equivalence classes
+ means that it is hard to see how it could be. The methods are then
+ combined using a custom method combination to mimic the standard
+ 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
+ well as hierachical and identity-based method selectors.
+
+ In context-oriented programming
+ \cite{Hirschfeld.etal:2008,Vallejos.etal:2010}, context dispatch
+ occurs by maintaining the context state as an anonymous class with
+ the superclasses representing all the currently active layers; this
+ is then passed as a hidden argument to context-aware functions. The
+ set of layers is known and under programmer control, as layers must
+ be defined beforehand.
+
+ In some sense, all dispatch schemes are specializations of predicate
+ dispatch \cite{Ernst.etal:1998}. The main problem with predicate
+ dispatch is its expressiveness: with arbitrary predicates able to
+ control dispatch, it is essentially impossible to perform any
+ substantial precomputation, or even to automatically determine an
+ ordering of methods given a set of arguments. Even Clojure's
+ restricted dispatch scheme provides an explicit operator for stating
+ a preference order among methods, where here we provide an operator
+ to order specializers; in filtered dispatch the programmer
+ implicitly gives the system an order of precedence, through the
+ lexical ordering of filter specification in a filtered function
+ definition.
+
+ The Slate programming environment combines prototype-oriented
+ programming with multiple dispatch \cite{Salzman.Aldrich:2005}; in
+ that context, the analogue of an argument's class (in Common Lisp)
+ as a representation of the equivalence class of objects with the
+ same behaviour is the tuple of roles and delegations: objects with
+ the same roles and delegations tuple behave the same, much as
+ objects with the same generalizer have the same behaviour in the
+ protocol described in this paper.
+
+ The idea of generalization is of course not new, and arises in other
+ contexts. Perhaps of particular interest is generalization in the
+ context of partial evaluation; for example, \cite{Ruf:1993}
+ considers generalization in online partial evaluation, where sets of
+ possible values are represented by a type system construct
+ representing an upper bound. The relationship between generalizer
+ metaobjects and approximation in type systems could be further
+ explored.