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

[Joachim Breitner]

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?

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

Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170921/2c8b7b46/attachment.sig>