Parsing funny arrows

[Brandon Allbery]

Another way to figure it out is the shift/reduce conflict on @, which tells
you it had two ways to recognize it. "Reduce" here means returning to your
parser rule, so "shift" means btype wanted to recognize the @. Inspecting
btype would then have shown that it was looking for a type application.

On Sat, Aug 29, 2020, 03:17 Csongor Kiss <kiss.csongor.kiss at gmail.com>
wrote:

> Thanks a lot Vlad and Shayne, that indeed did the trick!
>
> Out of curiosity, how could I have figured out that this was the culprit?
> The parse
> error I got was a bit puzzling, and I couldn't find any flags that would
> give more information
> (I think I was looking for the parser equivalent of -ddump-tc-trace).
>
> Best,
> Csongor
>
> On 29 Aug 2020, at 00:51, Shayne Fletcher <shayne.fletcher.50 at gmail.com>
> wrote:
>
>
>
> On Fri, Aug 28, 2020 at 7:48 PM Shayne Fletcher <
> shayne.fletcher.50 at gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 28, 2020 at 7:38 PM Vladislav Zavialov <vladislav at serokell.io>
>> wrote:
>>
>>> Hi Csongor,
>>>
>>> I believe the reason for this failure is that  a -> @m b  gets parsed
>>> as  a -> @(m b).
>>> Why is that? Because a ‘btype’ includes type-level application.
>>>
>>> If you replace the ‘btype’ after PREFIX_AT with an ‘atype’, this
>>> particular issue should go away. At least that’s my hypothesis, I haven’t
>>> tested it.
>>>
>>>
>> I confirm that this is correct and with that change the example string
>> reduces as hoped.
>>
>>
>> - Vlad
>>>
>>
> Also, with that correction there are no new shift/reduce conflicts. The
> original rule gave rise to 3.
>
> --
> Shayne Fletcher
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200829/4aeed3b8/attachment.html>