Skip to content
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

yi does not build with -XMonadFailDesugaring enabled (default in GHC 8.6+) #1102

Open
chessai opened this issue Nov 23, 2018 · 8 comments
Open

Comments

@chessai
Copy link

chessai commented Nov 23, 2018

-XMonadFailDesugaring is enabled by default with GHC 8.6+. There are some failable patterns involving BufferM that cause Yi to fail to compile, because BufferM doesn't have a MonadFail instance.

@chessai
Copy link
Author

chessai commented Nov 23, 2018

Apologies for the fact that I forgot to copy the error I was getting the other day. There's likely more than one place, the easiest way to see all of them is either with GHC 8.6 or setting default-extensions: MonadFailDesugaring in your .cabal files

@chessai chessai changed the title yi does not build with -XMonadFailDesugaring enabled yi does not build with -XMonadFailDesugaring enabled (default in GHC 8.6+) Nov 23, 2018
@zenhack
Copy link

zenhack commented Nov 28, 2018

Just ran into this. I don't really have anything to add, except ftr this is the error output I got:

[33 of 70] Compiling Yi.Buffer.Misc   ( src/Yi/Buffer/Misc.hs, dist/build/Yi/Buffer/Misc.o )

src/Yi/Buffer/Misc.hs:453:25-95: error:
    • No instance for (Control.Monad.Fail.MonadFail BufferM)
        arising from a do statement
        with the failable pattern ‘Just mrks’
    • In a stmt of a 'do' block:
        Just mrks <- uses
                       winMarksA (M.lookup $ wkey (b ^. lastActiveWindowA))
      In the expression:
        do Just mrks <- uses
                          winMarksA (M.lookup $ wkey (b ^. lastActiveWindowA))
           forM mrks getMarkValueB
      In a stmt of a 'do' block:
        newMarkValues <- if wkey (b ^. lastActiveWindowA) == def then
                             return
                               MarkSet
                                 {insMark = MarkValue 0 Forward, selMark = MarkValue 0 Backward,
                                  fromMark = MarkValue 0 Backward}
                         else
                             do Just mrks <- uses
                                               winMarksA (M.lookup $ wkey (b ^. lastActiveWindowA))
                                forM mrks getMarkValueB
    |
453 |                         Just mrks  <- uses winMarksA (M.lookup $ wkey (b ^. lastActiveWindowA))
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Yi/Buffer/Misc.hs:873:3-30: error:
    • No instance for (Control.Monad.Fail.MonadFail BufferM)
        arising from a do statement
        with the failable pattern ‘Just !ms’
    • In a stmt of a 'do' block: Just !ms <- getMarks =<< ask
      In the expression:
        do Just !ms <- getMarks =<< ask
           return ms
      In an equation for ‘askMarks’:
          askMarks
            = do Just !ms <- getMarks =<< ask
                 return ms
    |
873 |   Just !ms <- getMarks =<< ask
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cabal: Failed to build yi-core-0.18.0 (which is required by exe:yi from
yi-0.18.0). See the build log above for details.

@xaverdh
Copy link

xaverdh commented Feb 17, 2019

I have a quick and dirty (may eat your data) patch here: https://github.com/xaverdh/yi/commits/monad-fail
Actually it probably won't eat your data.

@chessai
Copy link
Author

chessai commented Feb 17, 2019

Do we really want the possibility for 'error' to occur there? Is there not a way to just avoid the failable pattern?

@xaverdh
Copy link

xaverdh commented Feb 17, 2019

Its not just failable patterns. printableChar for example calls fail explicitly.
The implementation of MonadInteract also has an Fails constructor which deals with this.

@xaverdh
Copy link

xaverdh commented Feb 17, 2019

Ah ok, you are probably referring to BufferM / EditorM. I don't know about that one.

@xaverdh
Copy link

xaverdh commented Feb 17, 2019

Ok, its mostly about Marks. getMarks returns a Maybe value, but askMarks (which is used all over the place in that file) then discards it, so maybe its presence is/should be an invariant?
runBufferFull looks like it should be, but then I don't understand why getMarks exists / is exported at all.

@xaverdh
Copy link

xaverdh commented Feb 17, 2019

I opened a pull request #1108 based on a different branch, where I attempt to do things properly.
We can discuss details there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants