<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">I see. So you are proposing</div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>PatternSignatures = SimplePatternSignatures + PatternSignatureBinds

</li></ul><div>That's fine with me.</div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 Jan 2024 at 21:30, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">John responded to some of this discussion on the proposal: <br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/608#issuecomment-1919413031" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/608#issuecomment-1919413031</a>.<br>
<br>
I think we should try to resolve this thread rather than leave it <br>
hanging. Given Simon's opposition to the idea of changing <br>
PatternSignatures, it seems to me the next best thing would be Joachim's <br>
observation that we could define a new extension SimplePatternSignatures <br>
(or however we call it) and modify #448 to use that instead. Perhaps <br>
that's a compromise we can live with? John indicates that he'd be happy <br>
with that outcome.<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
<br>
On 29/01/2024 15:30, Simon Marlow wrote:<br>
> On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg <br>
> <<a href="mailto:reisenberg@janestreet.com" target="_blank">reisenberg@janestreet.com</a> <mailto:<a href="mailto:reisenberg@janestreet.com" target="_blank">reisenberg@janestreet.com</a>>> wrote:<br>
> <br>
>  Â  Â Simon M:<br>
> <br>
>  Â  Â  Â  Â deciding that the stability principles don't apply to<br>
>  Â  Â  Â  Â pre-existing deprecations would not be in the right spirit, if<br>
>  Â  Â  Â  Â you ask me<br>
> <br>
> <br>
>  Â  Â To me, it's in the spirit of "deprecation", if not stability. That<br>
>  Â  Â is, what does it mean to deprecate a feature? I think it means that<br>
>  Â  Â users should expect the feature to disappear at some point in the<br>
>  Â  Â future; in other words, it explicitly labels a feature as<br>
>  Â  Â non-stable. Up until now, we hadn't settled on a meaning of<br>
>  Â  Â stability, and so by extension we hadn't settled on a meaning for<br>
>  Â  Â deprecation. So maybe we say "the feature wasn't actually deprecated<br>
>  Â  Â because we didn't know what /deprecated/ meant", but I think this<br>
>  Â  Â one has been labeled deprecated for long enough that we should feel<br>
>  Â  Â comfortable removing it / changing it.<br>
> <br>
> <br>
> This raises an interesting distinction that I hadn't realised before <br>
> (and sorry about the tangent but it seemed important to highlight). We <br>
> may actually want two different kinds of deprecation:<br>
> <br>
> 1. Deprecated and may change in a future GHC release (GR3-style <br>
> deprecation; we expect these to be rare)<br>
> 2. Deprecated and may change in a future language edition (no impact on <br>
> stability; doesn't require GR2 justification; more common)<br>
> <br>
> I kind of expected most existing deprecations would turn into (2) given <br>
> the new stability requirements.<br>
> <br>
> Cheers<br>
> Simon<br>
> <br>
> <br>
>  Â  Â ---------------<br>
> <br>
>  Â  Â My initial support for this proposal was based on the fact that it<br>
>  Â  Â made a few people happy. Now it's become clear that it also makes a<br>
>  Â  Â few people unhappy. I'm still hoping for a language-edition-based<br>
>  Â  Â future <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/628" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/628</a>><br>
>  Â  Â where this proposal doesn't matter, so I'm pretty agnostic. Maybe on<br>
>  Â  Â balance it's a better use of time debating that potential future<br>
>  Â  Â (I'll prepare a proper proposal this week) than to debate this finer<br>
>  Â  Â point?<br>
> <br>
>  Â  Â Richard<br>
> <br>
>  Â  Â On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a><br>
>  Â  Â <mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>>> wrote:<br>
> <br>
>  Â  Â  Â  Â Hmm, deciding that the stability principles don't apply to<br>
>  Â  Â  Â  Â pre-existing deprecations would not be in the right spirit, if<br>
>  Â  Â  Â  Â you ask me. I think we should apply the rules consistently to<br>
>  Â  Â  Â  Â every proposal going forward, being already deprecated doesn't<br>
>  Â  Â  Â  Â get you a pass. In this case we really don't have to break<br>
>  Â  Â  Â  Â existing code, so let's not do it.<br>
> <br>
>  Â  Â  Â  Â It's not that hard to make a new extension or to change the<br>
>  Â  Â  Â  Â behaviour in GHC2024 is it?<br>
> <br>
>  Â  Â  Â  Â Cheers<br>
>  Â  Â  Â  Â Simon<br>
> <br>
> <br>
> <br>
>  Â  Â  Â  Â On Mon, 29 Jan 2024 at 11:42, Joachim Breitner<br>
>  Â  Â  Â  Â <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a> <mailto:<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>>> wrote:<br>
> <br>
>  Â  Â  Â  Â  Â  Â Hi,<br>
> <br>
>  Â  Â  Â  Â  Â  Â well, we were more liberal at deprecating things in the past<br>
>  Â  Â  Â  Â  Â  Â than we<br>
>  Â  Â  Â  Â  Â  Â will be under the new regime, and we might not have invoked<br>
>  Â  Â  Â  Â  Â  Â GR2 here.<br>
> <br>
>  Â  Â  Â  Â  Â  Â But the extension already _is_ deprecated. If deprecating<br>
>  Â  Â  Â  Â  Â  Â (even for the<br>
>  Â  Â  Â  Â  Â  Â wrong reasons) and waiting multiple releases does not allow<br>
>  Â  Â  Â  Â  Â  Â us to break<br>
>  Â  Â  Â  Â  Â  Â the deprecated thing, then what is the point of GR3?<br>
> <br>
>  Â  Â  Â  Â  Â  Â I am quite fond of the new stability regime, it sets out<br>
>  Â  Â  Â  Â  Â  Â clear requirements on code (set a language flag, heed<br>
>  Â  Â  Â  Â  Â  Â deprecation<br>
>  Â  Â  Â  Â  Â  Â warnings, although the latter could be spelled out more<br>
>  Â  Â  Â  Â  Â  Â explicitly), in<br>
>  Â  Â  Â  Â  Â  Â return for clear promises. Let’s not water this down by not<br>
>  Â  Â  Â  Â  Â  Â taking the<br>
>  Â  Â  Â  Â  Â  Â set of requirements of requirements seriously ourselves.<br>
> <br>
>  Â  Â  Â  Â  Â  Â Cheers,<br>
>  Â  Â  Â  Â  Â  Â Joachim<br>
> <br>
>  Â  Â  Â  Â  Â  Â Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow:<br>
>  Â  Â  Â  Â  Â  Â  > "Only exceptionally would we fix a design flaw in a way<br>
>  Â  Â  Â  Â  Â  Â that breaks programs compiled with existing language<br>
>  Â  Â  Â  Â  Â  Â editions."<br>
>  Â  Â  Â  Â  Â  Â <a href="https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2</a> <<a href="https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2</a>><br>
>  Â  Â  Â  Â  Â  Â  ><br>
>  Â  Â  Â  Â  Â  Â  > This is not exceptional is it? It's just a regular design<br>
>  Â  Â  Â  Â  Â  Â flaw :) If we must fix it, let's do it in a way that<br>
>  Â  Â  Â  Â  Â  Â complies with the stability principle.<br>
>  Â  Â  Â  Â  Â  Â  ><br>
>  Â  Â  Â  Â  Â  Â  > Cheers<br>
>  Â  Â  Â  Â  Â  Â  > Simon<br>
>  Â  Â  Â  Â  Â  Â  ><br>
>  Â  Â  Â  Â  Â  Â  ><br>
>  Â  Â  Â  Â  Â  Â  > On Mon, 29 Jan 2024 at 11:15, Joachim Breitner<br>
>  Â  Â  Â  Â  Â  Â <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a> <mailto:<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>>><br>
>  Â  Â  Â  Â  Â  Â wrote:<br>
>  Â  Â  Â  Â  Â  Â  > > Hi,<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon<br>
>  Â  Â  Â  Â  Â  Â Marlow:<br>
>  Â  Â  Â  Â  Â  Â  > > > I might be a bit confused, but doesn't this proposal<br>
>  Â  Â  Â  Â  Â  Â change the meaning of an existing<br>
>  Â  Â  Â  Â  Â  Â  > > > extension (PatternSignatures)?<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > > a long-ago deprecated one:<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > > ~ $ ghci<br>
>  Â  Â  Â  Â  Â  Â  > > GHCi, version 9.4.8: <a href="https://www.haskell.org/ghc/" rel="noreferrer" target="_blank">https://www.haskell.org/ghc/</a><br>
>  Â  Â  Â  Â  Â  Â <<a href="https://www.haskell.org/ghc/" rel="noreferrer" target="_blank">https://www.haskell.org/ghc/</a>>  :? for help<br>
>  Â  Â  Â  Â  Â  Â  > > ghci> :set -XPatternSignatures<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > > <no location info>: warning: [-Wdeprecated-flags]<br>
>  Â  Â  Â  Â  Â  Â  > > Â  Â  -XPatternSignatures is deprecated: use<br>
>  Â  Â  Â  Â  Â  Â -XScopedTypeVariables or pragma {-# LANGUAGE<br>
>  Â  Â  Â  Â  Â  Â ScopedTypeVariables #-} instead<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > > Hopefully our stability principles does not require us<br>
>  Â  Â  Â  Â  Â  Â to heed programs<br>
>  Â  Â  Â  Â  Â  Â  > > that ignored deprecation flags for a while?<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > > My understanding of<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â <a href="https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles</a> <<a href="https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles</a>><br>
>  Â  Â  Â  Â  Â  Â  > > is that, despite â€œstable package” not saying â€œdoes not<br>
>  Â  Â  Â  Â  Â  Â use features<br>
>  Â  Â  Â  Â  Â  Â  > > deprecated long ago”, it’s still ok to break such<br>
>  Â  Â  Â  Â  Â  Â programs, as this is<br>
>  Â  Â  Â  Â  Â  Â  > > our mechanism GR3?<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > > Of course we could side-step this procedural question<br>
>  Â  Â  Â  Â  Â  Â about repurposing<br>
>  Â  Â  Â  Â  Â  Â  > > an old extension and introduce<br>
>  Â  Â  Â  Â  Â  Â `SimplePatternSignatures` instead. Not<br>
>  Â  Â  Â  Â  Â  Â  > > in favor, simply because as a user I more than once<br>
>  Â  Â  Â  Â  Â  Â intuitively reached<br>
>  Â  Â  Â  Â  Â  Â  > > for `PatternSignatures` to get the proposed behavior.<br>
>  Â  Â  Â  Â  Â  Â  > ><br>
>  Â  Â  Â  Â  Â  Â  > > Cheers,<br>
>  Â  Â  Â  Â  Â  Â  > > Joachim<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>