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

[Chris Mellon]

On 07 Jul 2007 23:27:08 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
> "Hamilton, William " <whamil1 at entergy.com> writes:
> > > Why on earth would anyone prefer taking a failure in the field over
> > > having a static type check make that particular failure impossible?
> >
> > Because static typechecking won't make that particular failure
> > "impossible,"  but instead just change it from a type error into a data
> > error that may or may not be harder to identify.  If your program gets a
> > piece of data that breaks it, you'll get a failure in the field.  Static
> > typechecking won't prevent that.
>
> I'm not doing a good job explaining that regexp example.  Static
> checking a la Haskell and ML avoids these problems by:
>
>   1) noticing through case analysis that you actually handle the
>      error return (except it looks like you have to use a separate
>      tool for this in Haskell, sigh); and
>
>   2) (in Haskell) using monadic types to propagate match results from
>      one operation to another, automatically taking care of turning
>      a match failure in a chain of operations into a failure of the
>      whole chain.
>
> In Python it's all too common to say
>
>      g1 = re.match(pattern, string)
>      a = g2.group(0)
>      g2 = re.match(template % a, other_string)
>      result = g2.group(1)
>
> or stuff like that, without bothering to check for match failures,
> just because of Python's inconvenient syntax.
>

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.