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

[Simon Peyton Jones]

|  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 at haskell.org] On Behalf Of Manuel M T Chakravarty
|  Sent: 19 October 2017 02:09
|  To: Richard Eisenberg <rae at cs.brynmawr.edu>
|  Cc: ghc-steering-committee at haskell.org; Joachim Breitner
|  <mail at 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 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-
|  committ
|  > ee
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee