[e-lang] Variations on When-Catch

Dean Tribble tribble at e-dean.com
Tue Dec 21 00:40:09 EST 2004

Since I'm mostly going to react to the two parts of the proposal, I'll 
just respond to this initial message (which I think was a great write-up).

marcs wrote:

>Variation One: Default Function Shorthand
>In the course of teaching my first class of new E programmers, one of the
>things that my students reminded me of (rather obstreperously) is that the
>current when-catch is pretty clunky:
Yes.  Something absolutely has to be done about it.  It's one of the 
most distinguishing features of the language, and you end up trying to 
explain why you can't have two of them with the same name.  It makes the 
scoping rules look like a problem rather than a nice consistent theory.  
And finally, it interferes with simply copying and pasting code or 
patterns of code.

>when (vow1, ...) -> {
>    #do something
>} catch prob {
>    #do something
This is a big improvement.  One of the issues that needs to be addressed 
with the various shortenings is that it needs to be *easy* to have 
multiple when-clauses without mucking with different names.  It's also 
just too hard to explain!  Finally, the suggestion of no longer 
requiring the "catch" clause seems right to me as well.  Great!

>Now, on to the intriguing idea, which markm suggested to me but didn't name.
>For the moment, I am calling it "event sequencing".
In any case, not a good name:  events are messages to objects.  I can 
sequence events by sending messages to another vat, and *not* waiting 
for answers.  perhaps resolve-chaining?  Perhaps below I will 
sufficiently discourage this that you won't need a better name?

>Variation Two: The "Before" Operator for Event Sequencing
>def resultVow := (vow1, ...) -> (vowN1, ...) -> (vowLast1...)
>... Nested when-catches have been rare in my experience, but really annoying when
>they've arisen.
First, I want to emphasize *rare*.  The importance of the first problem 
this message solved should not bleed over to this second, minor problem 
for a rare issue.  For someone who has learned to use promises, the 
nesting when clause approach isobvious to either think of or read.  A 
new syntax for something that is infrequent just makes these rare cases 
even harder to get right because they use unfamiliar constructs.  It is 
worse that it introduces a bunch of wierdnesses into the scoping, etc. 

Still not convinced?  One of the hardest parts of the conceptual 
transition to dataflow concurrency via promises is to stop trying to get 
order (e.g., across different machines) by waiting for confirmation and 
then sending the next message.  That suggests to me that we should not 
add a construct for some rare case that makes this bad but occasionally 
necesszary design habit easier to apply.  By eliminating the required 
catch clause, the really annoying part is reduced.  By supporting 
multiple promises in the same 'when' I bet some of the occurrences are 
eliminated.  I think it is better that the remaining occurrences are 
still at least a little annoying :-)

I'd like to see some real occurrences.  It would not surprise me if 
there was a better way to do them that did not require the round trip 
(unless you were interfacing to external libraries).

>This naive event sequencing implementation has 2 defects compared to the
>when-catch version:
>- It kills parallelization, since it is fully sequentialized. 
That seems like the wrong thing to make the "easy" thing..

>- It is probably more vulnerable to datalock, since it introduces artifical
Nope don't want to make that the easy, either.

>These disadvantages are often irrelevant, and the ability to read the code
>almost as if it were immediate calls is intriguing for both maintenance and
Right, As you note later, having the concurrent, happens in a different 
event, non-atomic, might have different failure semantics stuff be hard 
to distinguish from the sequenctial code is not a good thing.

>We fix the parallelization and datalock problems simply by replacing a
>before symbol (with attendant parens) with a comma (I have a vague
>suspicion, from my ancient dim memories, that Joule had this nature; no
>doubt dean and markm are laughing at me as I rediscover cool stuff they did
>a decade ago :-). 
Heh.  This is actually the kind of cheating that Joule would never let 
one gtet away with.  It was very hard to send a message, waith for a 
result, and then send another message, and have any assurance that 
things happened in that order just because you thought they should.  The 
thing that responded so promptly might only have done the part needed to 
respond to you, and not the part that you were hoping would happen 
before the second message you send.  Dataflow synchronization is the 
only safe concurrency!!! :-)

>The bottom line: event sequenceing enables a much smoother transition from
>local computation to robust efficient distributed computation.
>I am uncertain whether this is actually good or bad. There is merit in the
>philosophy, "things should either be the same or very different", and event
>sequencing blurs the distinction between two types of programming that are
>really different. 
Repeat after me:  "Bad"  :-)

>I hypothesize that E in a Walnut should introduce and
>explore the when-catch at length before unveiling event sequencing as an
>alternative. But event sequencing is certainly a worthy experiment to be put
>into a pragma. 
I think that it should *not* be put into a pragma until there is a bunch 
of code that legitimately requires nested when clauses.  The grammar is 
cluttered enough :-)  I would wait until there is a pattern of such that 
suggests we will need to use it frequently.  And even then, I would hold 
off, because it undermines most of the things that are valuable about 
the E concurrency model.


More information about the e-lang mailing list