[ghc-steering-committee] Proposal #608, -XPatternSignatureBinds. Rec: accept
Simon Peyton Jones
simon.peytonjones at gmail.com
Thu Feb 1 12:37:29 UTC 2024
I see. So you are proposing
- PatternSignatures = SimplePatternSignatures + PatternSignatureBinds
That's fine with me.
Simon
On Wed, 31 Jan 2024 at 21:30, Adam Gundry <adam at well-typed.com> wrote:
> John responded to some of this discussion on the proposal:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/608#issuecomment-1919413031
> .
>
> I think we should try to resolve this thread rather than leave it
> hanging. Given Simon's opposition to the idea of changing
> PatternSignatures, it seems to me the next best thing would be Joachim's
> observation that we could define a new extension SimplePatternSignatures
> (or however we call it) and modify #448 to use that instead. Perhaps
> that's a compromise we can live with? John indicates that he'd be happy
> with that outcome.
>
> Cheers,
>
> Adam
>
>
>
> On 29/01/2024 15:30, Simon Marlow wrote:
> > On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg
> > <reisenberg at janestreet.com <mailto:reisenberg at janestreet.com>> wrote:
> >
> > Simon M:
> >
> > deciding that the stability principles don't apply to
> > pre-existing deprecations would not be in the right spirit, if
> > you ask me
> >
> >
> > To me, it's in the spirit of "deprecation", if not stability. That
> > is, what does it mean to deprecate a feature? I think it means that
> > users should expect the feature to disappear at some point in the
> > future; in other words, it explicitly labels a feature as
> > non-stable. Up until now, we hadn't settled on a meaning of
> > stability, and so by extension we hadn't settled on a meaning for
> > deprecation. So maybe we say "the feature wasn't actually deprecated
> > because we didn't know what /deprecated/ meant", but I think this
> > one has been labeled deprecated for long enough that we should feel
> > comfortable removing it / changing it.
> >
> >
> > This raises an interesting distinction that I hadn't realised before
> > (and sorry about the tangent but it seemed important to highlight). We
> > may actually want two different kinds of deprecation:
> >
> > 1. Deprecated and may change in a future GHC release (GR3-style
> > deprecation; we expect these to be rare)
> > 2. Deprecated and may change in a future language edition (no impact on
> > stability; doesn't require GR2 justification; more common)
> >
> > I kind of expected most existing deprecations would turn into (2) given
> > the new stability requirements.
> >
> > Cheers
> > Simon
> >
> >
> > ---------------
> >
> > My initial support for this proposal was based on the fact that it
> > made a few people happy. Now it's become clear that it also makes a
> > few people unhappy. I'm still hoping for a language-edition-based
> > future <https://github.com/ghc-proposals/ghc-proposals/pull/628>
> > where this proposal doesn't matter, so I'm pretty agnostic. Maybe on
> > balance it's a better use of time debating that potential future
> > (I'll prepare a proper proposal this week) than to debate this finer
> > point?
> >
> > Richard
> >
> > On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow <marlowsd at gmail.com
> > <mailto:marlowsd at gmail.com>> wrote:
> >
> > 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 <mailto: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
> <
> 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 <mailto: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/
> > <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
> <
> 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
>
>
> --
> 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
>
> _______________________________________________
> 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/20240201/f19d1eb0/attachment.html>
More information about the ghc-steering-committee
mailing list