4 ms·
God, I'm so tired of this boring platitude. Every criticism of Haskell not satisfying category laws (of which there are many) are of the form "undefined breaks
by wyager 10y ago
God, I'm so tired of this boring platitude. Every criticism of Haskell not satisfying category laws (of which there are many) are of the form "undefined breaks things". Obviously! How would a runtime-error-inducing concession to practicality not break things? Haskell also fails to satisfy the category laws if I make unsafe FFI calls or use unsafePerformIO to crash the program randomly. Thus is the nature of programming languages.
- ezyang 10y agoReplace every occurrence of "undefined" with "non-terminating program" and the point still stands.
- seagreen 10y agoBut as Haskellers we _are_ concerned about unsafePerformIO et al. -- this is why we have the SAFE pragma.
- tome 10y agoAgreed. But it doesn't need Andrej Bauer to point it out to us.
- l_zzie 10y ago"undefined" isn't the problem here, seq is.
- catnaroek 10y agoBottom values aren't a “concession to practicality”: they're a defect in lazy languages. In ML, when types are viewed as collections of values, the empty type is really empty, sum types are really sums, tuple types are really tensor products and distribute over sums. But, of course, strict languages have dual defects, function spaces aren't as nice unless the language is total (which a general-purpose language can't be), and `let x = e in t` isn't equivalent to the result of substituting `x` with `e` in `t`. To get both the good parts of strictness and the good parts of laziness, you need call-by-push-value: http://www.cs.bham.ac.uk/~pbl/cbpv.html http://www.cs.bham.ac.uk/~pbl/cbpv.html. But, if that's overkill, it's easier to get the benefits of laziness in a primarily strict language, than the other way around.