Concurrency in ToonTalk

[Mark S. Miller]

ToonTalk, by Ken Kahn, and Joule both descend directly from the Vulcan 
Project (headed by Ken, with both Dean & I as members), and E descends 
directly from Joule.  The project was named "Vulcan" because it combined 
insights from Actors and Concurrent Logic Programming.  These all share a lot 
of memes.

http://www.toontalk.com/English/concur.htm is an elegant explanation of 
concurrency in ToonTalk, including how it relates to traditional programming 
constructs, and why it is deadlock free.  ToonTalk, like Joule, is fully 
concurrent, so the page doesn't quite apply to E at object granularity, but 
it does seem to apply to E at Vat granularity.

However, the page's concluding paragraph:

>In summary, attempts to add concurrency to languages with subroutines and 
>shared state lead to complexity, costly implementations of processes, and 
>bugs that are very hard to track down. ToonTalk, in contrast, was designed 
>from scratch to be concurrent. In ToonTalk there is no need to introduce 
>locks or critical regions, processes cost very little, and race conditions 
>and deadlocks are avoided.

represent well the premise under which Actor languages have evolved, from
Hewitt to Vulcan to Joule & ToonTalk.  Because all pre-E attempts at adding
concurrency to sequential languages added threads and locks, we all seemed
to assume they must.

Doug Barnes' big discovery at Electric Communities with Original E (before
I arrived) is that the Actors/Logic/Vulcan/Joule/ToonTalk concurrency
control model can itself be added to sequential programming without
conflict.  Surprisingly, it turns out the issue is not designing from
scratch to be concurrent.  The issue is only choosing the right way to be
concurrent.

	Cheers,
	--MarkM