[ghc-steering-committee] Proposal #608, -XPatternSignatureBinds. Rec: accept
Adam Gundry
adam at well-typed.com
Wed Jan 31 21:30:32 UTC 2024
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
More information about the ghc-steering-committee
mailing list