Re: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations

By "do nothing" do you mean not implementing @_ which is already in the proposal? Sorry to be ambiguous. I mean that the GHC Steering Committee does nothing -- i.e. leaves the spec as-is. So then it still has to be implemented. So the proposal is no good in its current form: it is rather inconsistent to have @_ but not _. Ah, I had not realised that. Thanks for pointing it out. I have responded on the discussion thread (this committee thread is too easily lost/missed.) Simon On Thu, 2 May 2024 at 14:35, Vladislav Zavialov wrote:

...

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