I'm personally quite fine with mutating extensions.

In this particular case (ha!) I am in favour of expaning the meaning of the current extension (I thought I'd opine in that sense on the thread already, but I appear not to have done so, ah well).

On Tue, Sep 14, 2021 at 10:03 AM Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,

I don’t think language pragmas are about choice in that sense. Either
we don’t want the feature (then we’d reject it), or we want it to
eventually become a viable default (at least for add-on extensions like
this). So at some day I expect GHC20xx to allow both \case and \cases.
Nobody forces to to _use_ \cases in your code, however!

The question is more about: do we want extensions to evolve over time,
or be more immutable (I don’t think we want to commit to full
immutability).

Cheers,
Joachim

Am Dienstag, dem 14.09.2021 um 10:55 +0300 schrieb Vladislav Zavialov
(int-index):
> We should give our users the option to keep using LambdaCase without enabling LambdaCases. I, for one, do not like the flavor we ended up choosing, so I’d keep using LambdaCase alone in my programs. I imagine other users might want to do so as well.
>
> - Vlad
>
> > On 14 Sep 2021, at 10:38, Joachim Breitner <mail@joachim-breitner.de> wrote:
> >
> > Hi,
> >
> >
> > on the multiway-lambda story, we have voted to add \cases alongside
> > \case. But one open question is still: Do we
> > (1) add -XLambdaCases (which would imply -XLambdaCase) or
> > (2) simply expand the meaning of -XLambdaCase.
> >
> > On the Github thread at
> > https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-895080031
> > we see that I lean towards (1), but SPJ leands towards (2).
> >
> > It doesn’t matter that much, but we need to make a decision. Can I
> > please get some opinions from the rest of the committee on this point?
> >
> > Cheers,
> > Joachim
> >
> >
> > --
> > Joachim Breitner
> >  mail@joachim-breitner.de
> >  http://www.joachim-breitner.de/
> >
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee@haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee@haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

--
Joachim Breitner
  mail@joachim-breitner.de
  http://www.joachim-breitner.de/


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee