[ghc-steering-committee] Proposal #608, -XPatternSignatureBinds. Rec: accept

[Simon Marlow]

Hmm, deciding that the stability principles don't apply to pre-existing
deprecations would not be in the right spirit, if you ask me. I think we
should apply the rules consistently to every proposal going forward, being
already deprecated doesn't get you a pass. In this case we really don't
have to break existing code, so let's not do it.

It's not that hard to make a new extension or to change the behaviour in
GHC2024 is it?

Cheers
Simon



On Mon, 29 Jan 2024 at 11:42, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> well, we were more liberal at deprecating things in the past than we
> will be under the new regime, and we might not have invoked GR2 here.
>
> But the extension already _is_ deprecated. If deprecating (even for the
> wrong reasons) and waiting multiple releases does not allow us to break
> the deprecated thing, then what is the point of GR3?
>
> I am quite fond of the new stability regime, it sets out
> clear requirements on code (set a language flag, heed deprecation
> warnings, although the latter could be spelled out more explicitly), in
> return for clear promises. Let’s not water this down by not taking the
> set of requirements of requirements seriously ourselves.
>
> Cheers,
> Joachim
>
> Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow:
> > "Only exceptionally would we fix a design flaw in a way that breaks
> programs compiled with existing language editions."
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2
> >
> > This is not exceptional is it? It's just a regular design flaw :) If we
> must fix it, let's do it in a way that complies with the stability
> principle.
> >
> > Cheers
> > Simon
> >
> >
> > On Mon, 29 Jan 2024 at 11:15, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> > > Hi,
> > >
> > > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:
> > > > I might be a bit confused, but doesn't this proposal change the
> meaning of an existing
> > > > extension (PatternSignatures)?
> > >
> > > a long-ago deprecated one:
> > >
> > > ~ $ ghci
> > > GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
> > > ghci> :set -XPatternSignatures
> > >
> > > <no location info>: warning: [-Wdeprecated-flags]
> > >     -XPatternSignatures is deprecated: use -XScopedTypeVariables or
> pragma {-# LANGUAGE ScopedTypeVariables #-} instead
> > >
> > > Hopefully our stability principles does not require us to heed programs
> > > that ignored deprecation flags for a while?
> > >
> > > My understanding of
> > >
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
> > > is that, despite “stable package” not saying “does not use features
> > > deprecated long ago”, it’s still ok to break such programs, as this is
> > > our mechanism GR3?
> > >
> > >
> > > Of course we could side-step this procedural question about repurposing
> > > an old extension and introduce `SimplePatternSignatures` instead. Not
> > > in favor, simply because as a user I more than once intuitively reached
> > > for `PatternSignatures` to get the proposed behavior.
> > >
> > > Cheers,
> > > Joachim
> > >
> > >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/282de1e6/attachment.html>