[ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension?

[Richard Eisenberg]

Manuel, I agree with everything you've just said. Thanks for articulating it so clearly.

> On Oct 18, 2017, at 9:08 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> If I may summarise the last few messages on this thread, it seems to me that, so far, everybody agrees that it would be beneficial to have two or more categories of extensions that come with different expectations of stability. (Whether that is by marking them as stable or annotating them with versions or years are details we will figure out.)
> 
> Richard, I do understand your fear about not being able to move quickly, and I think, we all want to preserve that property of Haskell. However, I would like us to think about how we can preserve agility, while providing sufficient stability. (I know that is hard, but easy problems are boring, so let’s rise to the challenge.)
> 
> As I said, in my previous message, I consider Haskell Prime to be dead (for all practical purposes). There will be no more Haskell standard. The closest thing to a Haskell standards committee —namely, the ”GHC Haskell” standards committee— is this group!
> 
> The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process.
> 
> Now, we can discuss the details:
> 
> * What categories are there?
> * How long do extensions remain agile?
> * How do we make the determination when to promote an extension to a more stable category?
> 
> Before we get too tied up in the details, I would like to discuss two higher-order points:
> 
> * Do we all agree that we need categories of stabilities for extensions (for the reasons outlined above)?
> * Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.)
> 
> Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job.
> 
> Cheers,
> Manuel
> 
> PS: There is also the issue of libraries, but that is really the responsibilities of the Core Libraries Committee (and maybe we have to have a chat with them).
> 
> PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.)
> 
>> Richard Eisenberg <rae at cs.brynmawr.edu>:
>>> On Oct 18, 2017, at 4:49 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>> 
>>> The way out there might be to try our best, and if we get it wrong and
>>> mark an extension as stable too early, we’ll just have to add a new
>>> pragma for the improved ones… so that seems like a good compromise.
>>> 
>> 
>> Yes, this is exactly what I was thinking. For example, TypeFamilies might have been marked as stable before closed type families came about... but then we would just have -XClosedTypeFamilies -- not so horrible.
>> 
>>> The other failure mode would be that we will have _too strict_
>>> requirements for marking extensions as stable, so that production code
>>> will inevitably have to use non-stable extensions, and not much is
>>> gained.
>> 
>> This, too, is exactly what I was thinking. Industrial users and book authors have the most to gain from an extension being marked as stable. I would expect that proposals would come from these groups marking extensions as stable, and then we could have a debate.
>> 
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>