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

[Simon Marlow]

On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg <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> 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>
>> 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
>>>
>> _______________________________________________
>> 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/ded576ee/attachment.html>