[E-Lang] Re: Why Not Coroutines? (was: Deadlock-free [was what is good about E?])

[zooko@zooko.com]

MarkM:

That was a well-written and highly accurate summary of one of the three reasons
that pre-emptive multithreading is so abhorrent to me as a programmer.

The first reason, as you described, is that pre-emptive multithreading
prevents me, when reading a sequence of source code, from using valuable
assumptions about how all of the state remains unchanged during the execution
of this sequence except for changes caused by the code I am looking at.

The second reason is deadlock.

The third reason is that bugs caused by the first two reasons are almost always
non-reproduceable and rare, thus being much more destructive and time-consuming
than a reproduceable and frequent bug would be.

If I understand correctly, E's execution model completely solves all three of
these problems.

So describing E as "deadlock free" may be describing only one of three valuable
improvements for the working programmer.

Regards,

Zooko

> When coding, I, and I believe most programmers, need a strong convention 
> about what boundaries in a program represent places where they need to 
> recheck assumption, because things can change since "they" last looked.  (Or 
> rather, when the narrative in their head about what the program is doing last 
> looked.)  Our naive intuitions from sequential programming are mostly 
> inarticulate, but go something like:
> 
> 1) On entry to a function/method, assume state invariants are intact, but 
> within those constraints anything may have changed.  [...]
> 
> 2) From one instruction/expression/statement to the next, assume that the 
> immediately accessible world is only affected in the ways I (this code) 
> affects it.
> 
> 3) Between a call and a return, assume that the callee only affects the world 
> in way I can understand.  (This is strengthened in a pointer-safe language, 
> and especially in a capability language, in that we may have a principled 
> basis for reasoning about the what state the callee may and may not affect.)
> 
> Advocates of pre-emptive shared-memory multithreading would have us relearn 
> #2 and #3.  I say #2 is too valuable and relearning it is too hard, so forget it.
> 
> Advocates of coroutines would let us keep #2, but have us relearn #3.  We 
> see by the hypothetical transformation, combined with a coroutine-based 
> scheduler, that the programmer using such a hypothetical transformer is now 
> writing source code that confuses #1 and #3.  Put another way, since the 
> transformer silently turns #3 into #1, on return from a call, we would now 
> have to be as assumption-free about the current state as we normally are on 
> entry to a method.
> 
> Traditional pure event-loop languages (Actors...Toontalk) have not had 
> call/return, but are faithful to intuitions #1 and #2.
> 
> E is faithful to all three intuitions.