Re: Generics vs. Message passing: object namespaces

> The nice thing about this is that different modules can all contribute
> to the func dispatch table, simply by executing a
> (defmethod func ((arg1 (eql 'blah)) arg2)
> 	...)
> form.

The most recent place I've run into such a mechanism is (the rather  
verbose) Inform 7 (in which "the nearest examined node contacting the  
current node" can be both specification and executable code).

It dispatches by the most specific phrase, so one can build up definitions  
in a piecewise manner, either providing base cases (having stated the  
general recursive case elsewhere):

http://en.literateprograms.org/99_Bottles_of_Beer_(Inform_7)
> Definition: a wall is empty if its inventory is zero.
> To say beer count of (w - an empty wall): say "no more bottles of beer".
> To act on (w - an empty wall): say "go to the store to buy some more, ".

or merely exhausting a set of alternatives:

http://en.literateprograms.org/Dijkstra's_algorithm_(Inform_7)
> To examine (m - an unreached node) from (n - a node):
> 	now m is examined;
> 	change the total distance of m to the extension of n to m;
> 	now m follows n.
> 	
> To examine (m - an examined node) from (n - a node):
> 	let d be the extension of n to m;
> 	if the total distance of m > d begin;
> 		change the total distance of m to d;
> 		now m follows n;
> 	end if.
(avoiding the 'if' by adding another dispatched phrase left as an exercise  
for the reader)

I'd been thinking of this mechanism in pattern matching terms, a la  
gopher, haskell, etc., because I'd only been vaguely aware of CLOS as  
handling before/after/around, not as providing generic dispatch.  What are  
the differences between clausal function definitions and lispy  
multimethods?

-Dave

(now, if methods choose an appropriate chunk of code on the left depending  
upon one part of the data they are hit with from the right, and objects  
choose an appropriate slot of data on the right depending upon the code  
selector they are hit with from the left, and multimethods dispatch on any  
or all of their arguments, would multiobjects be able to evaluate  
equationally rather than freely, dispatching on any or all of the  
functions/monad to which they have been applied?)