"Hamilton, William " <[EMAIL PROTECTED]> 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. This article explaining Haskell's Maybe typeclass (what you'd use instead of returning None in a Python function) may be of interest: http://blogs.nubgames.com/code/?cat=2 -- http://mail.python.org/mailman/listinfo/python-list