PEP 3107 and stronger typing (note: probably a newbie question)

[Donn Cave]

In article <mailman.491.1184001659.22759.python-list at python.org>,
 "Chris Mellon" <arkanes at gmail.com> wrote:

> I don't think it's the syntax that keeps people from checking for
> errors. It's more a difference of error handling philosophy - in
> Python, if you can't do something sensible with an error you  just
> pretend it can't happen and rely on your caller to do something
> sensible. In a lot of cases, this means that nobody does anything and
> errors propagate all the way up and thats fine.
> 
> What you're describing with the type inference solution feels more
> like Javas checked exceptions to me, where the compiler ends up
> signaling an error if you don't pretend like you considered the error
> condition. In Java, at least, this tends to create actively harmful
> code where you stick in empty or otherwise useless exception handlers
> to shut up the compiler, and when "can't happen" errors actually do
> occur they are lost or worse. Maybe this doesn't happen in Haskel, but
> I'd be interested in how it doesn't.

As Paul mentioned parenthetically, Haskell's type system doesn't
support all this by itself.  You can write a function that is defined
for only some cases of a value, so indeed you can fail to check for
an error status, or match the first element of an empty list, and
in general it is quite possible to get a run time error in this way.
There is naturally some dissatisfaction with this state of affairs.
Another point about this is that a 

The second point, about syntax and failure handling is another matter.
In the example -
>
>      g1 = re.match(pattern, string)
>      a = g2.group(0)
>      g2 = re.match(template % a, other_string)
>      result = g2.group(1)
>

... if all these re functions have a monad type that supports it,
this would be a sequence of monad bindings with failure options.
The algebra of these things is such that a failure short circuits
the larger expression just like a false result short circuits
evaluation of an "and" sequence.  I wouldn't say this prevents
data errors in Haskell, though, it only simplifies them in a sequential
computation where such a monad type is convenient.

I missed the type error -> data error point that this evidently
was all supposed to be some response to, and I don't know what
that was supposed to mean, but Haskell's type system addresses
just what we all would expect, the structural consistency of the
program in terms of data types.  It doesn't generally prevent data
errors or correct your misunderstanding of an algorithm or in
general avoid every kind of error.  What it does, though, it does
rather well.

   Donn Cave, donn at u.washington.edu