On 21 September 2017 at 14:28, Joachim Breitner <mail@joachim-breitner.de> wrote:

Hi,

the vote seems to indicate acceptance so far; fine with me.

Am Donnerstag, den 21.09.2017, 08:46 +0100 schrieb Simon Marlow:
> However, if we do accept the proposal, it should have its own
> extension rather than being part of ExplicitNamespaces, for the
> reasons discussed earlier: code needs a way to declare that it is
> using a new extension, so that it can properly be rejected by older
> versions of the compiler that don't support the extension.

Earlier we discussed the question of whether we want to allow minor
changes to unextendd Haskell without extensions (and the consensus was
no). This does not imply that we forbid ourselves from extending the
range of existing GHC language pragmas.

>From a user point of view, having “ExplicitNamespaces” allow me to
explicitly name the namespaces of an identifier in identifier lists
such as export, import and fixity lists is very natural. It would be
strange if I need “ExplicitNamespaces” for export and import lists, but
“ExplicitNamespacesFixities” in fixitiy lists.

I am sure others can give concrete examples where the syntax of
language extensions has evolved without introducing a wealth of new
extensions (and having to support all combinations). TemplateHaskell
splices maybe? RebindableSyntax maybe?

It's a tradeoff and we could go either way, but I'll argue for being strict here. Suppose we have some code that uses the new extension and I compile it with GHC 8.2. The choice is between:

* without a new extension flag, GHC says "Parse error"

* with a new extension flag, GHC says "Extension not supported", and in fact we might not even get that far because our tooling might tell us that we can't compile this code before we even try. Or Cabal could choose a different (and supported) version of the package instead.

It's a choice between having metadata and a bit of extra work, vs. having no metadata and things sometimes failing.

So is there a sensible way we can avoid fringe language extension
pragma proliferation?

yes there is, it's called Haskell Prime :)

Cheers

Simon

Joachim

--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee