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
|