search

yesodweb / yesod-scaffold

The Yesod scaffolding, with branches for different versions.
MIT License
76 stars 39 forks source link

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

Open mgsloan opened 9 years ago

mgsloan commented 9 years ago

-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: https://github.com/commercialhaskell/stack/issues/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 commented 9 years ago

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 commented 9 years ago

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

snoyberg commented 9 years ago

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 https://github.com/yesodweb/yesod-scaffold/issues/109#issuecomment-158229873 .

gregwebs commented 9 years ago

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 commented 9 years ago

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 https://github.com/yesodweb/yesod-scaffold/issues/109#issuecomment-158294177 .

gregwebs commented 8 years ago

2 pull requests above to move things in this direction (#110 and #111) Also a stackage PR: https://github.com/fpco/stackage/pull/990

snoyberg commented 8 years ago

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