<div dir="ltr">Responding to a few points above:<div><br></div><div>Simon PJ:</div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><br></div><div><span class="gmail-im" style="color:rgb(80,0,80)"><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Does this one have a purpose?</blockquote></span></div><div><span class="gmail-im" style="color:rgb(80,0,80)"><div><br></div></span></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Well, yes.   It allows people who want pattern signatures that do not bind to have pattern signatures that do not bind.</div></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></blockquote><font face="tahoma, sans-serif">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.</font></div><div><font face="tahoma, sans-serif"><br></font></div><div><font face="tahoma, sans-serif">Adam:</font></div><div><font face="tahoma, sans-serif"><br></font></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>I respectfully disagree with Richard's characterisation of</div><div>this proposal as merely promoting a warning to be an extension. [See <a href="https://gist.github.com/adamgundry/5446f390ee84254c43a0425e821dc930" rel="noreferrer" target="_blank">https://gist.github.com/adamgundry/5446f390ee84254c43a0425e821dc930</a>]</div><div><br></div></blockquote>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!)<div><br></div><div>Simon M:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>deciding that the stability principles don't apply to pre-existing deprecations would not be in the right spirit, if you ask me</div></blockquote><div><br></div><div>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 <i>deprecated</i> meant", but I think this one has been labeled deprecated for long enough that we should feel comfortable removing it / changing it.</div><div><br></div><div>---------------</div><div><br></div><div>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 <a href="https://github.com/ghc-proposals/ghc-proposals/pull/628">language-edition-based future</a> 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?</div><div><br></div><div>Richard</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.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"><div dir="ltr"><div>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.</div><div><br></div><div>It's not that hard to make a new extension or to change the behaviour in GHC2024 is it?<br></div><div><br></div><div>Cheers</div><div>Simon<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 29 Jan 2024 at 11:42, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</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">Hi,<br>
<br>
well, we were more liberal at deprecating things in the past than we<br>
will be under the new regime, and we might not have invoked GR2 here.<br>
<br>
But the extension already _is_ deprecated. If deprecating (even for the<br>
wrong reasons) and waiting multiple releases does not allow 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 deprecation<br>
warnings, although the latter could be spelled out more explicitly), in<br>
return for clear promises. Let’s not water this down by not 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 that breaks programs compiled with existing language editions." <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 flaw :) If we must fix it, let's do it in a way that complies with the stability principle.<br>
> <br>
> Cheers<br>
> Simon<br>
> <br>
> <br>
> On Mon, 29 Jan 2024 at 11:15, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
> > Hi,<br>
> > <br>
> > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:<br>
> > > I might be a bit confused, but doesn't this proposal 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>  :? for help<br>
> > ghci> :set -XPatternSignatures<br>
> > <br>
> > <no location info>: warning: [-Wdeprecated-flags]<br>
> >     -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables #-} instead<br>
> > <br>
> > Hopefully our stability principles does not require us to heed programs<br>
> > that ignored deprecation flags for a while?<br>
> > <br>
> > My understanding of<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><br>
> > is that, despite “stable package” not saying “does not use features<br>
> > deprecated long ago”, it’s still ok to break such programs, as this is<br>
> > our mechanism GR3?<br>
> > <br>
> > <br>
> > Of course we could side-step this procedural question about repurposing<br>
> > an old extension and introduce `SimplePatternSignatures` instead. Not<br>
> > in favor, simply because as a user I more than once intuitively reached<br>
> > for `PatternSignatures` to get the proposed behavior.<br>
> > <br>
> > Cheers,<br>
> > Joachim<br>
> > <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>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><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>
_______________________________________________<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>