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.k...@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...@gmail.com> > wrote: > > > > On Fri, Aug 28, 2020 at 7:48 PM Shayne Fletcher < > shayne.fletcher...@gmail.com> wrote: > >> >> >> On Fri, Aug 28, 2020 at 7:38 PM Vladislav Zavialov <vladis...@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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
