stack ghci and the ghc-8.0 branch

[paulhilbert]

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]

If you turn off RebindableSyntax, this should work.

On Fri, Dec 16, 2016 at 10:01 AM, Paul Hilbert notifications@github.com wrote:

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

:1:6: error: Not in scope: ‘>>’ :1:70: error: Not in scope: ‘>>’ :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 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or mute the thread .

[paulhilbert]

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]

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

[mikeizbicki]

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]

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).