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

[Simon Peyton Jones]

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 <vlad.z.4096 at gmail.com>
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 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/cf3de8a6/attachment-0001.html>