<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>