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

[Karp, Alan]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Friday, August 24, 2001 12:48 PM
> To: Karp, Alan
> Cc: E Language Discussions
> Subject: RE: [E-Lang] when-catch-finally (was: pending 
> revision of E in
> a Walnut)
> 
> 
> 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.
> 

That's what I intended to say.  The analogy is a NullPointerException in
Java.  It's not an exception to generate a null pointer, just to dereference
one.

> 
> code by Alan was fixed as follows:
> 

Thanks.  That's what comes from not having written any E programs.

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

There should be something like a CallToBrokenReferenceException, right?

> 
> 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.

My mistake.  I got too clever for my own good.  I originally had a line
containing nothing but a reference to "moving" in order to trigger the
exception.  On editing the note, I saw a way to save a line of code by
writing nextCar name().  Unfortunately, my error obscures my point.  (Will
"moving name()" print the same thing?)

> 
> 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.
> 

I think the situation is reasonbly simple, and analogous to null pointers in
Java.  If I want to check the variable in this routine, I need to reference
it.  On the other hand, data needed to deal with the exception may only be
available elsewhere.  In that case, I might want to catch the broken
reference there.  The complicating factor is that I must know that sending
won't trigger the exception.

> 
> 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
> 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
> 

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-3
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/