[E-Lang] when-catch-finally (was: pending revision of E in a Walnut)

[Mark S. Miller]

At 09:08 AM Thursday 8/23/01, Karp, Alan wrote:
>Well, if a broken reference is an exception

Just to be clear, the broken reference isn't an exception.  It holds an 
exception, and throws it when called.


>then when(...) can move into
>its block whenever a reference is either resolved or broken.  That block can
>contain a try-catch with an exception thrown on an attempt to use a broken
>reference.  For example,
>
>            when (nextCar <- moveTo(toX,toY)) -> done(moving) {
>                try {
>                   println(nextCar name() + " arrived, next car to start moving")
>                } catch e :BrokenReferenceException {
>                    println("car died: " + e)
>                } catch e :Exception {
>                    println("" + e + " happens.")
>                } finally {
>                    moveRemainingCars()
>                }
>            }

The above example code by Alan was fixed as follows:

* tabs were replaced by spaces.  This is a perpetual problem with all 
  languages which use indentation.
* The old syntax "nextCar name" was replaced with the now required 
  "nextCar name()".
* The catch-patterns were changed from the Java-like "Exception e", which 
  was never legal E syntax, to "e :Exception".
* The 'println(e + ...)' was changed to 'println("" + e + ...)', since 
  exceptions don't automagically turn into a string by *receiving* an add 
  message.

There is no BrokenReferenceException.  But I don't think that's crucial to 
Alan's point, so I'll ignore that.

I don't understand this example as is.  "moving" is the resolution which may 
or may not be broken.  In order for the code to correspond to the text, the 
try clause would need to call "moving" before anything else.  If it were 
"moving name()" rather than "nextCar name()", then this would make sense.

The problem with this technique is the programmer would have to be careful 
to call the resolution before doing anything else.  If the resolution were 
far rather than near, this would still be a successful resolution, but could 
not be called, only sent to.  Once these issues are corrected for, Alan's 
code becomes identical to the new expansion of when-catch-finally.  But it's 
a sufficiently tricky idiom that it's better for the expansion to generate 
it rather than have the programmer remember how to do it.


Btw, Terry & I, while working on the new multi-vat updoc, have already had 
occasion to use the new when-catch-finally expression.  Just in time 
language design, thanks!


        Cheers,
        --MarkM