> From: "Peter Smet" <peter.smet at flinders.edu.au>
>
> Not only is 'locality multicast' more biologically plausible, it  
is much
> more efficient to implement than a global broadcast mechanism. The  
problem
> still is that 'ripple effects' will be substantial. Since the  
whole thing is
> happening asynchronously, it becomes a nightmare to predict the  
sequence of
> events. But perhaps this is exactly the point - let the local  
interactions
> happen, and the global consequences will take care of themselves.

The software architecture people have been doing research on  
implicit invocation:

http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/implinvoc-fse98.html

Another issue with "broadcast" in Smalltalk is that there is no  
syntax for it.  You can only send a message to a single named entity,  
though that entity can be a proxy for a collection of objects (  
collection + trampoline ).  This is multicast to a static group.   
Multicast to a dynamic group is the next step:

	self neighbours doSomethingInteresting:fascinatingArgument.

(assuming that neighbours is in fact computed dynamically)  A ripple  
effect would be:

	self neighbours doSomethingInteresting:fascinatingArgument.
	self neighbours neighbours  
doSomethingInteresting:fascinatingArgument.
	self neighbours neighbours neighbours  
doSomethingInteresting:fascinatingArgument.
	...

Although this looks like it will first compute the neighbours and  
then send the message, an iterator based implementation could  
actually send the messages incrementally as the (expanding) list of  
neighbours is computed.

The rippling effect is actually a higher order effect that could  
again be captured by a message:

	self probe neighbours doSomethingInteresting:fascinatingArgument.

#probe keeps applying the #neighbours message to the results of the  
previous #neighbours send, and applies the "interesting" message to  
each result.   ( Note:  the common, symmetric interpretation of  
neighbours would in this case lead to non-termination of the example,  
but that can be fixed by either a more limited view of neighborhood  
or a sufficiently smart #probe method, or by running the example on  
suitably rigged slide projector :-)) ).

Again, an iterator based implementation does not have to compute  
large collections of intermediate results but can proceed to send  
messages one by one (at least in principle).

(Just thinking:  tree traversal :=  self probe children  
doSomethingWithTreeNodes )

Marcel