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

[Vladislav Zavialov]

> 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 at 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 at 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 at maralorn.de
>> > <mailto:malte.ott at 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240502/d561d8d0/attachment.html>