Sugar for when/latch/catch

[Mark S. Miller]

Ok, here's our proposed sugar, which will look frighteningly familiar to 
programmers of Original-E:

     when (foo <- msg(args)) -> observer(result) {
         ... handle the success case ...
     } catch problem {
         ... handle the failure case ...
     }

which expand to the previous

     (foo <- msg(args)) <- whenResolved(define observer(result) {
         if (E isBroken(result)) {
             define problem := E optProblem(result)
             ... handle the failure case ...
         } else {
             ... handle the success case ...
         }
     })

Experience has already shown that this results in a significant improvement 
in readability for distributed programs, but since this is MarcS' 
experience, I'll defer to him for further tales-from-experience.

"->" is pronounced "latch".  The symbol "->" was chosen by loose analogy 
with "<-".  The result of the expression on the left *eventually* becomes 
resolved to the value of the parameter on the right.  The catch clause is 
not optional.  If you want an observer that doesn't handle errors separately 
(which is sometimes useful), you have to write in the non-sugared syntax.

I say Original-E programmers will find this frightening because it's similar 
in many ways to the now-dreaded etry/ecatch construct from Original-E.  
Because it looked like a do-it-now control flow construct, people constantly 
misled themselves into thinking the catch body would be executed in the 
current side-effect state of the world, and that any side-effects it caused 
would effect the current world.  Even when you knew better, your eyeballs 
just weren't telling you that you were defining behavior to be executed 
later in its own event/turn.  I was one of many people arguing at the time 
that this shouldn't be made to appear as an in-line control flow construct, 
because of this issue.  Well, I don't have to listen to my own advice.

My hope is that the choice of "->", as well as the function-definition-like 
"observer(result) {", will be adequate clues to the eyes that a closure 
being defined and eventually invoked.

There are many other things criticize to in the above sugar as well.  But to 
separate issues, and to let people who are interested in different kinds of 
issues know which email to ignore, please discuss syntactic issues by 
replying to this email, but semantic issues by replying to the previous one. 
For those that are unavoidably both, or if you're not sure, reply to this 
email, but say something in the first line.  Thanks.


         Cheers,
         --MarkM