Python and Flaming Thunder

[Duncan Booth]

"Dan Upton" <upton at virginia.edu> wrote:

> On Thu, May 29, 2008 at 3:36 AM, Duncan Booth
><duncan.booth at invalid.invalid> wrote:
>> Dave Parker <daveparker at flamingthunder.com> wrote:
>>
>>> Catch doesn't return just error types or numbers, it can return any
>>> object returned by the statements that are being caught; catch
>>> doesn't care what type they are.  For example:
>>>
>>>   Writeline catch(set x to "hello world".).
>>>
>>> will write "hello world".
>>
>> I really don't get this. Surely the point about an error being thrown
>> to a catch statement is that the error path is separate from the
>> normal execution path? What you are doing here is ensuring that
>> unexpected errors have no chance at all of propagating up to the top
>> level: they are invariably going to get caught by some other handler
>> that was installed just because someone was too lazy to write a set
>> statement followed by a writeline.
> 
> It also looks like an overloading of catch, semantically similar to
> the C: 
> 
> int retcode;
> if( retcode = doSomethingThatReturns0or1() ) printf("Hello world");
> 
> Again, I don't think you want to start overloading your
> exception-handling mechanism.  If you want a set expression to be
> equal to the l-value at the end, that's fine, but there's no reason
> that catch should evaluate to an object or an integral- or real-valued
> exception in error cases, or of the last statement of the block if
> there's no error.  (Evaluating a block to be equal to its last
> statement is okay, I guess; I know at least that there's a call in
> Scheme that lets you do a more imperative programming style in the
> functional language--whether that's a good thing is probably a holy
> war.)  I just think if you're shooting for an easily understandable
> language, overloading error handling requires more thought on the
> programmer's part, not less, because they have to reason about all
> outcomes.
> 
I like BCPL's way of handling block expressions: VALOF is followed by a 
block of statements and within that block RESULTIS gives the result. 
This lets you exit the block early (just like a return statement does), 
but without returning from the current procedure (unless of course the 
entire body of the procedure is a VALOF block). Naturally the result has 
to be explicitly specified (otherwise the value is undefined).

Maybe FT should do something similar:

   Writeline value of (set x to "hello world". Result is x.).

and catch can then stick to catching errors.

-- 
Duncan Booth http://kupuguy.blogspot.com