- Remove illegitimate MonadFail instances for strict and lazy ST.
- Document that fail should never raise an exception from "pure" code.
|No Unit Test Coverage|
|Build 42717: [GHC] Linux/amd64: Continuous Integration|
|Build 42716: [GHC] OSX/amd64: Continuous Integration|
|Build 42715: [GHC] Windows/amd64: Continuous Integration|
|Build 42714: arc lint + arc unit|
I'll check back in after a couple of weeks by which time we'll have a better overall sense of the opinion on the proposal after the initial interest spike, at that point I should be more prepared to weigh in with an official "maintainer" grade position.
These are just my initial thoughts.
This artificial side condition is not mathematically required for a "monad with left zero."
We may choose that encouraging "fail" in ST is something we don't want to encourage because it is too easy to do or because it doesn't produce the same kind of result as "error" or something, but I don't think this condition is the dividing line.
Removing the instance is a value judgement that we might choose to make, not a product of the laws at hand.
Interestingly, this should have been careful to behave the same way as fail in IO, which carefully throws in IO at the right time in the calculation by building on throwIO
seq (fail s) x ==> errorWithoutStackTrace s
throwing an exception, but handling this through the throwIO-like machinery should yield
seq (fail s) x ==> x
as it is an ST calculation that will fail when executed, not an error in its own right when forced.
Consequently, this instance as written was incorrect to begin with at the very least.