<div dir="ltr">> <span style="font-family:tahoma,sans-serif">We could, if we chose, just (continue to) not support "_" in TH.</span><div><span style="font-family:tahoma,sans-serif"><br></span></div><div><font face="tahoma, sans-serif">Do you mean supporting the feature in GHC but not in TH? E.g. if the programmer uses a TH quotation [d| type T @_ = ... |], the generated AST would actually be equivalent to [d| type T @_w1 = ... |] where _w1 is a fresh name? I think it'd be mostly fine, though it would be a lossy conversion, so if the user attempts to preprocess the TH AST before splicing it, they might be surprised to find that their wildcard is no longer a wildcard. In other words, the TH AST is not only produced but also sometimes consumed by user-written code, so I err on the side of representing things exactly rather than via an encoding.</font></div><div><font face="tahoma, sans-serif"><br></font></div><div><font face="tahoma, sans-serif">I'm not thrilled about taking such shortcuts because they tend to bite back later, but yes, it could work.</font></div><div><br></div><div>> <span style="font-family:tahoma,sans-serif">I'm still leaning towards "do nothing"</span></div><div><span style="font-family:tahoma,sans-serif"><br></span></div><div><span style="font-family:tahoma,sans-serif">By "do nothing" do you mean not implementing @_ which is already in the proposal? This would correspond to "do nothing" in implementation terms, but that'd be a conscious deviation from the spec. The intellectually honest thing to do in that case would be to update the spec to reflect this choice. So the proposal is no good in its current form: it is rather inconsistent to have @_ but not _. We need an amendment, but the question is which amendment: to add syntax or to remove it. Maybe your counterproposal is to remove @_ from the proposal? That would bring the spec in sync with the current impl.</span></div><div><br></div><div><font face="tahoma, sans-serif">Vlad</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 2, 2024 at 3:05 PM Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@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 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>
_______________________________________________<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>