Omit extensions from cabal file which are problematic for "stack ghci"

[mgsloan]

-XNoImplicitPrelude can cause issues for modules which require the Prelude. So, if we use "stack ghci" to load a yesod project along with some other project, it doesn't work. See this issue: commercialhaskell/stack#1363

-XTemplateHaskell can also cause issues due to it changing the meaning of f $x and f $(x).

I realize that this would be a bit of an unpleasant refactoring, but it'd certainly be an improvement, at least with our current tools. Ideally, we wouldn't need to do this - https://ghc.haskell.org/trac/ghc/ticket/10827 - so this could be considered an upstream issue.

[gregwebs]

I was considering switching to base-noprelude. I am not sure if that will somehow have other ripple effects in this situation, but it seems like it should work.

With respect to TemplateHaskell I have not seen it create issues. But I always have a space after the $ application function and it seems peculiar not to.

[mgsloan]

Yeah, removing -XTemplateHaskell isn't nearly as important as -XNoImplicitPrelude, which pretty much always breaks things.

[snoyberg]

I know I felt quite differently in the past, but I'm now on board with
moving to in-module language extensions because of these tooling issues.

On Fri, Nov 20, 2015, 1:17 AM Michael Sloan notifications@github.com
wrote:

Yeah, removing -XTemplateHaskell isn't nearly as important as
-XNoImplicitPrelude, which pretty much always breaks things.

—
Reply to this email directly or view it on GitHub
#109 (comment)
.

[gregwebs]

I take a more nuanced view on this issue: we can divide language extensions in to 2 categories based on whether they can break existing code or not.

Those that don't break anything (usually any syntax extension such as RecordWildCards and in general most extensions that are not about the type system) should go in the .cabal file.
Any extensions which can break other modules should go in the module itself. Many type-system additions could potentially alter type inference and thus break otherwise working code.

There is definitely a grey area. I would argue that everyone should be putting a space after the dollar operator. However, having TemplateHaskell on can still make error messages worse in some cases even if it doesn't alter the ability to compile the code.

[snoyberg]

I like that division.

On Fri, Nov 20, 2015, 8:25 AM Greg Weber notifications@github.com wrote:

I take a more nuanced view on this issue: we can divide language
extensions in to 2 categories based on whether they can break existing code
or not.

Those that don't break anything (usually any syntax extension such as
RecordWildCards and in general most extensions that are not about the type
system) should go in the .cabal file.
Any extensions which can break other modules should go in the module
itself. Many type-system additions could potentially alter type inference
and thus break otherwise working code.

There is definitely a grey area. I would argue that everyone should be
putting a space after the dollar operator. However, having TemplateHaskell
on can still make error messages worse in some cases even if it doesn't
alter the ability to compile the code.

—
Reply to this email directly or view it on GitHub
#109 (comment)
.

[gregwebs]

2 pull requests above to move things in this direction (#110 and #111)
Also a stackage PR: commercialhaskell/stackage#990

[snoyberg]

Given improvements in stack ghci since this was open, is this still relevant? I believe we handle the case of extensions in .cabal files better than we used to (though, as someone who's not an ardent stack ghci user, I could be wrong).