Thoughts on the nature of programming...Asynchronous Events

Marcel Weiher marcel at system.de
Wed Jun 23 15:17:40 UTC 1999


> From: "Peter Smet" <peter.smet at flinders.edu.au>
> >This thread is great, my own experimentation with asynchronous  
messages was
> >a real eye opener.
>
>
> I haven't looked at this code yet, but it occurred to me that you  
could get
> an approximation of locality with asynchronous events. How would  
that work?

[snipped]

What you are describing is a kind of implicit invocation system.   
Implicit invocation is one of many possible styles of interaction  
between software components.

I think that most of these interaction styles can be seen as a  
special kind of messaging.  Taking Smalltalk synchronous, name-based,  
single-target messaging as a starting point, we can derive various  
other styles by varying small parts.

1.	Asynchronous messaging

Simply allow the sender to proceed while the receiver is processing.  
 Potentially allow multiple results, usually needs explicit  
synchronization.

	answerQueue := someObject async someMessage:param.
	" ... do something spiffy ... "
	answer := answerQueue next.		"  wait for answer "
	answer displayOnScreen.

A simplified version of this that integrates better with call/return  
style synchronous messaging is the future mechanism, with the future  
being a proxy that (in terms of the implementation shown above)  
retains the answerQueue and will wait for an answer as soon as any  
message is sent.

	answer := someObject future someMessage:param.  " returns a  
future-object "
	" ... do something spiffy ... "
	answer displayOnScreen.		" automagically waits for  
answer if necessary "

2.	Broadcast/multicast messaging

The event system is a broadcast system.  Messages are not sent to a  
single specific target but broadcast 'to the world', with any part of  
'the world' capable of registering an interest in receiving this  
particular message.

This is actually implemented as a kind of 'multicast', with the  
message sent to a specific collection of objects.  The collection is  
implicitly defined as the set of objects registered for a specific  
message.  A roughly equivalent formulation would be

	(messageCenter objectsInterestedIn:#someMessage:)  
someMessage:param.

or simplified

	messageCenter broadcast someMessage:param.

3.	Rule based systems

Rule-based systems execute the body of a rule when the head matches  
some local/global conditions.  (I am sure this is a simplification,  
feel free to correct me).

The Smalltalk message lookup mechanism is really a special version  
of this, with the condition being that the name of the message sent  
to this object (or broadcast with an event system) matches the name  
of the method exactly.

Various other matching mechanisms are imaginable, for example  
allowing regular expressions for method names yields AWK- or lex-like  
string processing facilities.  So instead of having to implement a  
mini-language on top of the current language, you exploit constrained  
variability of the base language.

4.	Simplifications

Direct jump-tables, straight procedure calls, inlined procedure  
calls and macros can all be viewed as specializations of message  
sending.  I think it should be possible for the programmer to somehow  
specify such simplified versions.

I can see everybody cringe here, thinking of Java final classes and  
the various C++ atrocities, but I think there is a fairly simple  
reason why they got it wrong, and more importantly, an avoidable  
reason.  Using the terminology from [1], binding is an integration  
mechanism, and should therefore be specified by integrators during  
integration (or only slightly beforehand) not by library/framework  
producers, who have to make their components as flexible as possible.



What is the point?

The point is that surprisingly minor variations of messaging as  
implemented now can cover a surprisingly large variety of problem  
domains/implementation technologies.  Programming languages typically  
provide a single mechanism, but OO is exactly about capturing  
similarities like these, so it is time for OO to be applied to Squeak  
itself.  A similar hierarchy of related concepts can be found for  
iteration ( loops, higher order messaging, iterators/streams,  
backtracking, ... ) and probably for other aspects of language as  
well ( variable binding, lazy evaluation, PROLOG-like unbound  
variables, ... )

Well, I could go on and on about this, but enough for now.

Marcel

1. Flexible Packaging,  
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/www/paper_abstracts/DeLine.FlexPack.html





More information about the Squeak-dev mailing list