- Remove illegitimate MonadFail instances for strict and lazy ST.
- Document that fail should never raise an exception from "pure" code.
Details
Details
Diff Detail
Diff Detail
- Repository
- rGHC Glasgow Haskell Compiler
- Branch
- st-no-fail
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Comment Actions
It might be wise to hold off on this until we reach a clear consensus on the topic on the libraries mailing list.
Comment Actions
You may have noticed that I added the only detractor (thus far) as a reviewer. I'm not trying to fly under the radar; just setting up in case it's approved.
Comment Actions
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.
| libraries/base/Control/Monad/Fail.hs | ||
|---|---|---|
| 54 | 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. | |
| libraries/base/Control/Monad/ST/Lazy/Imp.hs | ||
| 199 | 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. | |