
On Sat, Jun 6, 2015 at 6:35 PM, Herbert Valerio Riedel
On 2015-06-04 at 23:36:01 +0200, Anthony Cowley wrote:
On Jun 4, 2015, at 5:22 PM, Herbert Valerio Riedel
wrote: On 2015-06-04 at 23:05:42 +0200, Alexey Shmalko wrote: If I understand correctly, the initial proposal was to enable the new syntax by default and it mustn't break any code (full backward-compatible).
That would be a departure from how language extensions were handled in GHC in the past afaik, and if there's no language pragma to toggle this new syntax, Cabal has no way to know that a new language syntax is required and that thereby needs exclude (not implemented yet) the affected package versions from the install-plan configuration space.
I can't parse your last sentence.
I'll rephrase: Extending the syntax GHC accepts beyond H2010 w/o a language flag (but if I understood you correctly, you stated that there's gonna be an associated language pragma) is not desirable, since you wouldn't be able communicate that requirement to Cabal via the other-extensions/default-extensions mechanism (albeit that information is currently not used early enough to affect the install-plan solver, see also [1])
While I'm mildly against having this new syntax enabled in GHC's default-mode (i.e. when neither -XHaskell2010 nor -XHaskell98 is set), I'm strongly against enabling it implicitly via -XHaskell2010, as when you request -XHaskell2010 you want GHC ideally to tell you when you're using syntax beyond H2010.
Just to be clear, that ideal is not reality, is it? I can pass ghc -XHaskell2010 and use syntactic extensions in my programs today (e.g. LambdaCase). I can additionally pass ghc -Wall and not hear about it. So I think what you're writing here is a proposal for a new GHC feature that restricts available syntactic extensions in the presence of a language standard flag? The interplay between things like Haskell2010 and other language extensions isn't great. It would be nice to have a better story, but I think that really is a separate issue wherein you want Haskell2010 to act like a meta-pragma to ensure that the file really is Haskell2010 compatible. I am not volunteering to make that happen :) Anthony