stack repl does not use default-language setting

[qxjit]

General summary/comments

stack repl does not use the default-language setting given in cabal files. This only seems to be the case for stack repl (and the equivalent stack ghci). stack build behaves as expected.

Steps to reproduce

1. Run command stack new stack-bug-test
2. Run command cd stack-bug-test
3. Observe that stack-bug-test.cabal has default-language: Haskell2010 for all targets
4. Run command stack repl
5. Run :show language at the repl prompt

Expected

base language is: Haskell2010 reported

Actual

base language is: GHC2021 reported

Output

stack repl --verbose

https://gist.github.com/qxjit/702442014b52aced86a6155aea120ad8

Stack version

stack --version
Version 2.9.1, Git revision 409d56031b4240221d656db09b2ba476fe6bb5b1 x86_64 hpack-0.35.0

Method of installation

• Via GHCup

[mpilgrem]

I think that what you experience is the intended behaviour, and you have to set the GHCi 'language' expressly if you do not want GHCi's default (stack repl --ghci-options -XHaskell2010).

For example, if you had a multi-package project (with different default-languages in each Cabal file), or a single-package project where the default-language of the library stanza differed from that of the executable stanza, or a multi-module package in which different modules used {-# LANGAGE #-} pragmas to set the 'language' differently, which 'language' would Stack chose to set up GHCi?

There is a sort of related discussion here https://gitlab.haskell.org/ghc/ghc/-/issues/19207 about GHCi's ignoring of {-# LANGAGE #-} pragmas in modules in respect of what is set up within GHCi itself.

[qxjit]

@mpilgrem That's a good point. I hadn't considered about the language setting used at the repl prompt vs. loading files. That said, I think I oversimplified the example from the original issue I encountered. Shouldn't I still expect the files loaded from the project to processed as Haskell2010 in this case? For instance, if I edit src/Lib.hs in the template created by stack new and add

newtype MyInt = MyInt Int deriving Num

in the file then stack build fails because GeneralizedNewtypeDeriving is not part of Haskell2010. On the other hand, stack repl loads the file successfully which I did not expect.

[mpilgrem]

I think that, when GHCi loads a module, it respects any LANGUAGE pragmas in the module and otherwise applies its 'language' and any :set options - and that Cabal files don't play a part. When GHCi evaluates an expression at its command line, it applies any :seti options (which are the :set options plus any additional options that have been set using :seti).

[qxjit]

@mpilgrem At the very least stack repl respects any default-extensions in the cabal file. For instance, if I add Haskell2010 under default-extensions with the above example it fails to load Lib.hs due to GeneralizedNewtypeDeriving no longer being on by default (as expected). default-language is not similarly respected however.

By comparison, cabal repl behaves as expected for the same setup -- it applies the default-language setting from the cabal file to the project files that it loads.

[mpilgrem]

@qxjit, thanks. In that case, it seems to me that Stack should treat default-language like default-extensions. It is unhelpful that default-language is undocumented by Cabal: https://cabal.readthedocs.io/en/3.8/cabal-package.html?highlight=default-extensions#pkg-field-default-language. I wonder which has priority, if default-extensions and default-language conflict.

[mpilgrem]

@qxjit, I think this is now implemented in the master branch version of Stack (eg stack upgrade --source-only --git). I have performed some simple tests on Windows. However, if you were able to test it, I would be grateful.

[mpilgrem]

@qxjit, I think this is now implemented in the master branch version of Stack (eg stack upgrade --source-only --git). I have performed some simple tests on Windows. However, if you were able to test it, I would be grateful.

[qxjit]

@mpilgrem I tested it as well and it appears to work as expected. Thank you!