<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1. If the proposed amendment is rejected, we /still/ have to change
 template-haskell to implement 425 in its current form. The 
specification allows invisible wildcards `@_`, which can't be 
represented in template-haskell at the moment. So I'd like to ask voting
 members to take that into consideration: this is not an "unforced 
change" because there is a change coming either way.</blockquote><div><br></div><div>Are you sure?  We could, if we chose, just (continue to) not support "_" in TH.   People generating TH code can always use a fresh variable instead.</div><div><br></div><div>I'm still leaning towards "do nothing"; and if we don't want that, then "do the minimum" (ie the non-recursive form).  We have so much complexity already, I don't want to add more.</div><div><br></div><div>Simon</div><div><br></div><div>PS sorry to be slow on this<br></div><div><br></div>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 22 Apr 2024 at 21:26, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">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">I find Vlad's argument convincing: if we are already adding support for <br>
@_ then at the very least it's worth adding _ at the same time, and it <br>
seems to involve no more breakage or implementation cost than #425 <br>
unamended. So I vote to accept.<br>
<br>
I'm on the fence as to whether to prefer the recursive version (more <br>
general and consistent with term syntax) or the non-recursive version <br>
(since it is simpler, and in practice the more general forms seem <br>
unlikely to be useful).<br>
<br>
Adam<br>
<br>
<br>
On 19/04/2024 17:17, Vladislav Zavialov wrote:<br>
> That's exactly right. We are not choosing between change / no change, we <br>
> are choosing between three possible changes:<br>
> <br>
> 1. Current proposal: only add support for @_<br>
> 2. Amendment sans recursion (if revised): add support for @_, @(_ :: k), <br>
> _, and (_ :: k)<br>
> 3. Amendment with recursion: add support for arbitrary combinations <br>
> of @, _, ::, and ( ... )<br>
> <br>
> It's going to be breaking in all three scenarios, unless we come up with <br>
> a compatibility layer using pattern synonyms as Adam suggests (I have <br>
> not investigated the feasibility of that).<br>
> <br>
> Vlad<br>
> <br>
> On Fri, Apr 19, 2024 at 5:59 PM Malte Ott <<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a> <br>
> <mailto:<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a>>> wrote:<br>
> <br>
>     Thanks for the input Vlad. Regarding the breaking change to TH:<br>
>     Do I understand you correctly that the required changes from 425<br>
>     have not landed<br>
>     in 9.10 and therefor accepting this proposal will not create anymore<br>
>     breakage,<br>
>     even between 9.10 and 9.12?<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>