-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove MonadFail (ST s)
instance(s)
#33
Comments
Agree. +1 for removal |
Get them out! I thought I remembered having proposed such a thing a few years ago. |
On Fri, 21 Jan 2022, Oleg Grenrus wrote:
These instances are now implemented as
instance MonadFail (ST s) where
fail s = errorWithoutStackTrace s
for both strict and lazy as ST, and these are very much against the
spirit of MonadFail proposal.
Right. So please remove them!
|
I hate to say it, but we need an impact assessment. Someone needs to prepare GHC 9.0 with the proposed patch and then build /~https://github.com/Bodigrim/clc-stackage against it. |
I won't be able to do it anytime soon, so any help is welcome. |
@Bodigrim I tried that and clc-stackage fails for vanilla GHC 9.0.1 with
|
Just remove it from |
I've been trying to build clc-stackage, and here's a quick recap. First, it goes slowly because I keep hitting "Missing dependencies on foreign libraries" like OpenGL stuff, and restarting the process every time is slow. Interesting breakages so far (with links to particular break points): I'm currently stuck because even after removing the said packages, the solver insists on building them. They're probably dependencies of some other packages (e.g. I'd guess, that a better process would be to (try to) build every package separately, but I'd need to get around to write some bash for that. Even better would be to employ Nix to avoid the missing native dependencies problem, I guess. |
@ulysses4ever nice!
is just a such big lie. See https://hackage.haskell.org/package/fgl-5.7.0.3/docs/src/Data.Graph.Inductive.Monad.html#GraphM These breakages pin point poorly written code, which is my intention with this proposal. |
I'm sorry but cabal-install giving me hard time today. I'm trying to build Bodigrim/clc-stackage after today's update where we removed several packages with native dependencies, for example:
Maybe it's a wrong place to ask, but why is this happening? To be sure, I checked with Meanwhile, another breakage is in regex-tdfa (failable patterns). |
Quick update on building Stackage (~2600 packages) under this change. It's done, and here's a list of 8 packages (including 4 mentioned above) that failed to build on their own because of the change; via a click on the package name you can get the build output. For posterity, the list is:
There's about 400 of build failures. Some are due to environment (missing native libs) but many of them are due to dependency on (some of) these 8 (about 350 on |
There was a use of `fail` for `Maybe` which is entirely pointless.
How should we communicate the fixed package to you? Update: fix also a second occurrence of the same pattern: |
In case of
into a use of |
@andreasabel: and people try to improve that in |
There was a use of `fail` for `Maybe` which is entirely pointless.
@andreasabel thanks for pitching in! A link to a branch with the fix or to the corresponding commit, if it's already merged into |
Three more failures:
Build output is here. There are 5 packages depending on these and failing to build. |
Preparing for a potential removal of `instance MonadFail (ST _)`, see haskell/core-libraries-committee#33.
The fix for the above error in Agda is here: /~https://github.com/agda/agda/tree/fail-ST (agda/agda#5766). UPDATE: Now in |
There was a use of `fail` for `Maybe` which is entirely pointless.
Preparing for a potential removal of `instance MonadFail (ST _)`, see haskell/core-libraries-committee#33.
Dear all, I successfully built the whole Stackage (the version presented on
(details are above). Two of these ( If CLC and @phadej are fine with it, I can submit a patch to GHC. And optionally to the affected packages. |
@ulysses4ever it would be great if you can make a patch, then CLC could vote (if I understand the process correctly). |
The MR passes CI, thanks @ulysses4ever. I therefore submit this proposal for vote to CLC. ping @Bodigrim |
I'm not sure what this spirit is. Could the spirit be documented, at the same time as the removal of the instances, so that no one considers adding similar instances in the future? I suspect the spirit is something like " |
Btw, this was discussed already in 2019: https://mail.haskell.org/pipermail/libraries/2019-November/030087.html but |
+1 |
🔥 +1 |
4 votes out of 6 are enough for approval, thanks all. @ulysses4ever @phadej since this is a breaking change, could you please prepare a migration guide along the lines of /~https://github.com/haskell/core-libraries-committee/blob/main/guides/no-noneq-in-eq.md ? |
CLC proposal: haskell/core-libraries-committee#33 The instances had `fail` implemented in terms of `error`, whereas the idea of the `MonadFail` class is that the `fail` method should be implemented in terms of the monad itself.
CLC proposal: haskell/core-libraries-committee#33 The instances had `fail` implemented in terms of `error`, whereas the idea of the `MonadFail` class is that the `fail` method should be implemented in terms of the monad itself.
Thanks all, the change has been merged in GHC, and I advertised the migration guide on Reddit. |
Thanks for the little migration guide. I have updated head.hackage with the relevant patches. |
Preparing for a potential removal of `instance MonadFail (ST _)`, see haskell/core-libraries-committee#33.
Preparing for a potential removal of `instance MonadFail (ST _)`, see haskell/core-libraries-committee#33.
I'm trying to summarise the state of this proposal as part of my volunteering effort to track the progress of all
Please, let me know if you find any mistakes 🙂 |
The MonadFail instance of ST was removed, see haskell/core-libraries-committee#33
The MonadFail instance of ST was removed, see haskell/core-libraries-committee#33
The MonadFail instance of ST was removed, see haskell/core-libraries-committee#33
These instances are now implemented as
for both strict and lazy as
ST
, and these are very much against the spirit ofMonadFail
proposal.The text was updated successfully, but these errors were encountered: