Python and Flaming Thunder

[Dan Upton]

On Wed, May 28, 2008 at 11:09 AM, Dave Parker
<daveparker at flamingthunder.com> wrote:
>> > If catch(set x to y+z.) < 0.1 then go to tinyanswer.
>>
>> So what does this do exactly if the set throws an error?
>
> I think the catch should catch the error thrown by set, compare it to
> 0.1, the comparison will not return true because the error is not less
> than 0.1, and so the go-to to tinyanswer will not be taken.
>

The semantics you're describing aren't clear here.  I suppose that's
sort of reasonable, given that you haven't implemented it yet, but
let's think about it for a second.  You say the catch construct should
catch the error thrown by set, but there's no reason "set" itself
should throw any sort of error in the sense of an exception--in a
statement like "Set x to SomeFunctionThatCanBlowUp()", the semantics
should clearly be that the error comes from the function.  In a simple
addition statement, that makes no sense.  So then I considered that
maybe you meant the error in the sense of some determination of
floating point roundoff error, but that can't be it, since you've
claimed recently a big win over Python with FT in that it has no
roundoff error.  So what, exactly, is the error you could even be
catching in that?  Assuming the answer is "You're right, there's no
actual error that could generated by that assignment," there are two
options: the compiler optimizes it away, or you throw a compile-time
error.  The latter makes more sense, as someone trying to catch an
exception where one can't possibly exist probably indicates a
misunderstanding of what's going on.

> ...  That's why C had to
> resort to the confusing "=" vs "==" notation -- to disambiguate the
> two cases.  The "catch" keyword unambiguously alerts the reader that
> the parenthesis contain a statement (or a whole list of statements).
>

However, I think overloading your catch error types to include objects
(or integral values, I guess, your example below isn't clear) along
with real values (ignoring the bit above about whether floating-point
assignment could throw an error) makes things confusing.  It's nice
that "catch(stuff)" indicates that there's one or more statements
inside, but so does indentation in Python, bracketing in C/C++,
Begin/End in <insert language here>, and so forth, but it doesn't give
any indication to what could come out and ideally, only one thing (or
its descendants in a type hierarchy) can come out.  (I suppose this
can be solved by overloading your comparison operators.)  Beyond that,
I think you would want a good mechanism for comparing ranges of values
if you want to make exceptions/errors real-valued.

>> For that matter, is there any way to distinguish between different errors
>> and only catch particular ones?
>
> I think the catch function should catch all of the errors (and the non-
> error result if no error occured), so I think distinguishing the error
> would have to come after.  Maybe something like:
>
> Set result to catch(read x from "input.txt".).
> If result = dividebyzeroerror then ... else throw result.
>
> I'm open to alternate suggestions, though.
>