<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg <<a href="mailto:reisenberg@janestreet.com">reisenberg@janestreet.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">Simon M:<div><br></div><blockquote style="margin:0px 0px 0px 40px;border:medium;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></blockquote><div><br></div><div>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:</div><div><br></div><div>1. Deprecated and may change in a future GHC release (GR3-style deprecation; we expect these to be rare)</div><div>2. Deprecated and may change in a future language edition (no impact on stability; doesn't require GR2 justification; more common)<br></div><div><br></div><div>I kind of expected most existing deprecations would turn into (2) given the new stability requirements.</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div> </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><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" target="_blank">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" target="_blank">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>
</blockquote></div></div>