In article <[EMAIL PROTECTED]>, "Chris Mellon" <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
