[Re: [clean-list] Clean in the Real World]

[Marco Kesseler]

>> If (a + b) throws an exception, it HAS NO RESULT. 
>
>Yes it has: the exception itself (at least in a language where 
>exceptions are first-class). As Fergus said, the output type of
>a function (normally) returning an xxx and (possibly) throwing
>an eee is the discriminated union of xxx and eee.
>
>Or did I misconstrue his posting?

Unfortunately, I do not know the answer to that last question.

Yes, I think that the exception itself should be a first-class value. 
At least, I see no good reason not to.

There is no law however that says that the output type of a function 
should be interpreted as the union of its "actual" type and some 
exception type. I like the idea that the type that I write down for a 
function result is actually the type it has.

A am not saying that it would be necessarily wrong to do so in 
certain systems (getException does it). It is just that I find it 
highly peculiar that something like "DivisionByZero" is seen as the 
value of an expression like (a + b), while all it says is "the 
computation has failed".

Now when I proposed "catch" notation like:

foo :: Int -> Int
foo x
    = bar x
    catch e = baz e

I explicitly said that cathing the exception became decoupled from 
the guarded expression. This was - I thought - implying that the 
exception does NOT get returned as part of the value of the guarded 
expression.

If then a discussion arises w.r.t. commutativity in the "solution" 
that I proposed, then it seems sensible to actually reason within the 
boundaries of that proposal.

And yes, I do think that this discussion has been very fruitful 
indeed. I am glad that Fergus was so persistent.


regards,
Marco