| 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. I'm much happier with this than with -XStaticPointers1 -XStaticPointers2 etc. Once we had such categories, we could use the GHC proposals process itself to allow people to propose moving a flag from 'experimental' to 'stable' or whatever. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Manuel M T Chakravarty | Sent: 19 October 2017 02:09 | To: Richard Eisenberg <rae@cs.brynmawr.edu> | Cc: ghc-steering-committee@haskell.org; Joachim Breitner | <mail@joachim-breitner.de> | Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), | Consensus: accept, own language extension? | | 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@cs.brynmawr.edu>: | >> On Oct 18, 2017, at 4:49 PM, Joachim Breitner <mail@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@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committ | > ee | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee