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
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
> 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
On Fri, Aug 28, 2020 at 7:38 PM Vladislav Zavialov
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’,
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
Hello devs,
I am trying to modify GHC's parser to allow the following syntax in types:
a -> @m b
but my naive attempt was unsuccessful:
type :: { LHsType GhcPs }
: btype{ $1 }
| btype '->' PREFIX_AT btype ctype ...
For example when I try to parse the
