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

Mon Jan 29 13:56:20 UTC 2024

Responding to a few points above:

Simon PJ:

Does this one have a purpose?

Well, yes.   It allows people who want pattern signatures that do not bind
to have pattern signatures that do not bind.

But this already exists; it's called -Werror=pattern-signature-binds. So
this proposal adds no new expressiveness. It just changes a warning to be
an extension.

Adam:

I respectfully disagree with Richard's characterisation of
this proposal as merely promoting a warning to be an extension. [See
https://gist.github.com/adamgundry/5446f390ee84254c43a0425e821dc930]

Your example indeed demonstrates that -XScopedTypeVariables is
non-conservative, but it is silent on pattern signature bindings. My
enthusiasm for my warning-to-extension claim remains, unabated. (But please
do keep trying to convince!)

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.

---------------

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/053831b6/attachment-0001.html>