[Haskell-cafe] Proposal: Shorter Import Syntax

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

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