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

[Richard Eisenberg]

What if extensions had an optional version number? This would be feature supported only in cabal, not really in GHC. For example, a cabal file could include

  other-extensions: TypeOperators >= 2

to say that it needs version 2 of the TypeOperators extension. GHC would need a way of telling cabal which versions of which extension it supports, but that’s it. (In other words, users couldn’t say “-XTypeOperators-1” as separate from “-XTypeOperators-2” or anything.)

That would seem to solve the problem in a way that’s unobtrusive to most users and yet convenient enough for people who want fine-grained control. Is it too heavy, though?

Richard

> On Sep 26, 2017, at 7:22 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> 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/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee