[ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject

[Simon Marlow]

On 21 September 2017 at 14:28, Joachim Breitner <mail at 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170926/4ce0b033/attachment.html>