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