Re: [Haskell-cafe] Proposal: Shorter Import Syntax

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. One risk I see with enabling this new and yet unproven syntax extension by default right away is that it blocks the way for any alternative (or just conflicting) import-syntax feature we may come up with in the future, as we would have already locked on to this new syntax by making it available out of the box, thereby increasing the cost of disabling it again. Another issue I see is with editors, which benefit a lot from having syntax advertised via language pragmas, as that can be used to control syntax highlighting, but if the text editor doesn't know whether that new syntax is allowed or not because it's not signalled via a {-# LANGUAGE #-} pragma, the syntax highlighter can't do its job of pointing out invalid syntax reliably. Other tooling may benefit from such an explicit pragma too (c.f. haskell-src-exts).

The proposed syntax is currently a parse error, so a package that used it could depend on a GHC new enough to support it (eg with a base version constraint). No older packages would cause any errors whatsoever.

*Currently*, you can indirectly depend on a GHC version (and thus available language extensions) by constraining on its associated `base` version (/if/ you depend on `base` directly), but that's more of workaround for lacking better means (which are not out of reach, see [1]), since by depending on the `base` library for /language/ features you assume that GHC and `base` will always have this direct correlation, but that's not guaranteed to remain so (and it would certainly solve quite a few GHC upgrade pains, if we could have a newer GHC install an older base major version.... but that's another story). And actually, you can also depend directly on a GHC version by using a cabal conditional construct of the kind if impl(ghc < 7.10) build-depends: base<0 However, it's semantically cleaner (and easier than to remember which GHC version introduced a given syntax extension) to state the syntax requirements in terms of other-extensions/default-extensions lists, rather than requesting a specific compiler (version), even if GHC is supposedly the only one left standing... Cheers, hvr [1]: https://github.com/haskell/cabal/issues/2644