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

[Joachim Breitner]

Hi,

Am Dienstag, den 26.09.2017, 20:10 +0100 schrieb Simon Marlow:
> 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.

it is also a choice between

* extensions are testbeds and playgrounds for language extensions
* extensions are what people build their products with

I guess at some point, the former was true, and it was so successful
that the second became true.

I’d be sad if this leads to language extensions having to live up to
the expectations to be perfect right from the start, and not be allowed
to improve over a few releases. But I see the benefit of stability. Is
it feasible to communicate their stability somehow?

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/20170926/4d11fca1/attachment.sig>