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

stack ghci and the ghc-8.0 branch #65

Open
paulhilbert opened this issue Dec 16, 2016 · 5 comments
Open

stack ghci and the ghc-8.0 branch #65

paulhilbert opened this issue Dec 16, 2016 · 5 comments

Comments

@paulhilbert
Copy link

In contrast to the master branch, the ghc-8.0 branch compiles fine for me. However using stack ghci does not:

<interactive>:1:6: error: Not in scope: ‘>>’
<interactive>:1:70: error: Not in scope: ‘>>’
<interactive>:1:135: error: Not in scope: ‘return’

I am not exactly sure why (is there some fundamental difference in how the REPL works with extensions?)... I guess a mixture of the non-implicit prelude and RebindableSyntax is the culprit, but I am way to new to haskell to figure out on my own.

Reproduction steps:

git clone https://github.com/mikeizbicki/subhask
cd subhask
git checkout ghc-8.0
stack build
stack ghci
@mikeizbicki
Copy link
Owner

mikeizbicki commented Dec 16, 2016 via email

@paulhilbert
Copy link
Author

Well that gives me dozens of compile errors given that subhask does not compile without it...

(I tried removing it from the default-extensions in the cabal file or alternatively using

stack ghci --ghci-options XNoRebindableSyntax

which also triggers a rebuild - and no, --no-build won't help).

@schiegl
Copy link

schiegl commented Dec 21, 2016

I'm having the same problem. Build and run works but not ghci.

@mikeizbicki
Copy link
Owner

By turn off RebindableSyntax, I meant modify your ~/.ghc/ghci.conf file so that :set -XRebindableSyntax is not included. This would only work for non-stack users.

I personally don't use stack, but it looks like stack is starting up ghci with whatever flags the project uses. A quick fix would be to just run import Control.Monad first thing when you start ghci. This will import the required functions from base. An alternative would be to import SubHask.Monad to load the symbols from subhask. These won't be compatible with any monads defined in base, however. There is some template haskell code that will automatically define these, but I've tried it from ghci.

@paulhilbert
Copy link
Author

I switched away from stack for further tests so it kind of works for me by disabling RebindableSyntax. I didn't do any more complex tests since I already switched away from subhask, but from a quick check I could tell that modifying the .ghci.conf with NoRebindableSyntax/import Control.Monad did indeed seem to at least have the stack ghci start (stack does use the local .ghci.conf in PWD). Whatever the solution the initial source of the problem seems to be the assertion of stack that ghc and ghci extension parameters always agree which imo makes this a problem of stack, not subhask (so feel free to close this issue).

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