Hi Brandon, I’m afraid your analysis is not entirely correct. The shift/reduce
conflict is not on @ but after it.
- Vlad
> On 29 Aug 2020, at 14:42, Brandon Allbery wrote:
>
> Another way to figure it out is the shift/reduce conflict on @, which tells
> you it had two ways to recognize it.
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.
Thanks once again for your detailed analysis, it's really helpful.
Especially the forall example - I did try constructing some string that would
parse, but I was shooting in the dark.
Best,
Csongor
> On 29 Aug 2020, at 09:05, Vladislav Zavialov wrote:
>
> The lexer produces only as many
The lexer produces only as many tokens as the parser requires. In the
‘lexerDbg’ dump that you included in the message, there were these lines:
token: ITvarid "m"
token: ITvarid "b"
token: ITsemi
So I knew that the parser consumed the entire string, up to the virtual
semicolon. I also
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
