> We could, if we chose, just (continue to) not support "_" in TH.

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.

I'm not thrilled about taking such shortcuts because they tend to bite back later, but yes, it could work.

> I'm still leaning towards "do nothing"

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.

Vlad

On Thu, May 2, 2024 at 3:05 PM Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:

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.

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.

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.

Simon

PS sorry to be slow on this

On Mon, 22 Apr 2024 at 21:26, Adam Gundry <adam@well-typed.com> wrote:

I find Vlad's argument convincing: if we are already adding support for
@_ then at the very least it's worth adding _ at the same time, and it
seems to involve no more breakage or implementation cost than #425
unamended. So I vote to accept.

I'm on the fence as to whether to prefer the recursive version (more
general and consistent with term syntax) or the non-recursive version
(since it is simpler, and in practice the more general forms seem
unlikely to be useful).

Adam


On 19/04/2024 17:17, Vladislav Zavialov wrote:
> That's exactly right. We are not choosing between change / no change, we
> are choosing between three possible changes:
>
> 1. Current proposal: only add support for @_
> 2. Amendment sans recursion (if revised): add support for @_, @(_ :: k),
> _, and (_ :: k)
> 3. Amendment with recursion: add support for arbitrary combinations
> of @, _, ::, and ( ... )
>
> It's going to be breaking in all three scenarios, unless we come up with
> a compatibility layer using pattern synonyms as Adam suggests (I have
> not investigated the feasibility of that).
>
> Vlad
>
> On Fri, Apr 19, 2024 at 5:59 PM Malte Ott <malte.ott@maralorn.de
> <mailto:malte.ott@maralorn.de>> wrote:
>
>     Thanks for the input Vlad. Regarding the breaking change to TH:
>     Do I understand you correctly that the required changes from 425
>     have not landed
>     in 9.10 and therefor accepting this proposal will not create anymore
>     breakage,
>     even between 9.10 and 9.12?


--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee