[Haskell-cafe] Proposal: Shorter Import Syntax

[Anthony Cowley]

On Sat, Jun 6, 2015 at 6:35 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> On 2015-06-04 at 23:36:01 +0200, Anthony Cowley wrote:
>>> On Jun 4, 2015, at 5:22 PM, Herbert Valerio Riedel <hvr at gnu.org> 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