[ghc-steering-committee] Please review #601: Extension lifecycle, Shepherd: Simon PJ

[Adam Gundry]

I support acceptance. Clearly communicating the stability of extensions 
seems like a good step towards reducing uncertainty about their use.

The only reservation I have is that the proposal introduces warnings by 
default for all Experimental and Deprecated extensions, and with -Wall 
for all Legacy extensions. This seems like it could be quite noisy. It 
all hinges on which extensions fall into each category, though, which is 
not yet determined. So I'm content to wait for a follow-up proposal 
defining the categorisation (which will be quite a task in its own 
right!). We can always review the appropriate frequency of warnings when 
we know exactly which extensions will be warned about.

It also occurs to me that extensions like NoFieldSelectors may be 
awkward as we might want to say that FieldSelectors is Stable but 
NoFieldSelectors is Experimental. But I doubt that's insurmountable, and 
we can resolve it in the subsequent proposal.

Cheers,

Adam


On 24/08/2023 16:42, Simon Peyton Jones wrote:
> Dear GHC steering committee
> 
> A month ago I wrote to you concerning GHC Proposal 601 about GHC 
> extensions 
> <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>.
> 
>     We propose a categorization scheme for Haskell language extensions.
>     This scheme is simple, in that there are few categories that are
>     described in terms of the user-relevant aspects, and it is
>     actionable, in that it suggests concrete changes to the warning
>     system of GHC that allow users to express their own risk tolerance
>     and get guidance as they upgrade their compiler 
> 
> 
> It's holiday time I know, but still, I did not get a single reply.  Is 
> that because you all love it or you all hate it?  RSVP!
> 
> I propose acceptance, modulo a few clarifications which I have posted on 
> the discussion thread.
> 
> Please reply, yea or nay.
> 
> Simon
> 
> On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>     Dear GHC Steering Committee
> 
>     Proposal #601
>     <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md> says
> 
>     We propose a categorization scheme for Haskell language extensions.
>     This scheme is simple, in that there are few categories that are
>     described in terms of the user-relevant aspects, and it is
>     actionable, in that it suggests concrete changes to the warning
>     system of GHC that allow users to express their own risk tolerance
>     and get guidance as they upgrade their compiler
> 
>     I'm happy with this proposal: it seems simple, comprehensible, and
>     actionable.
> 
>     The only question in my mind is whether it is worth the bother.  I'd
>     love to hear from the practitioners on the committee.
> 
>     But I propose that we accept it.
> 
>     Simon
> 
> 
>     On Mon, 24 Jul 2023 at 14:39, Joachim Breitner
>     <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 
>         Dear Committee,
> 
>         David Thrane Christiansen suggested to categorize extensions into
>         Experimental, Mature, Deprecated and Legacy, and add warning flag to
>         GHC that allow users to be warned about (or shouted at for)
>         using such
>         extensions, if they choose so.
> 
>         https://github.com/ghc-proposals/ghc-proposals/pull/601
>         <https://github.com/ghc-proposals/ghc-proposals/pull/601>
>         https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>
> 
>         Because of the meta-like aspect of this proposal, I’d like to assign
>         this to Simon PJ.
> 
> 
>         Please guide us to a conclusion as outlined in
>         https://github.com/ghc-proposals/ghc-proposals#committee-process
>         <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> 
> 
>         Cheers,
>         Joachim
> 
> 
>         -- 
>         Joachim Breitner
>         mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>         http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England