Issue

Parsing multiple Expressions

expr 
	: matched_expr
	|  no_parens_expr
	|  unmatched_expr
	;

Has issues on the two parts of grammar below

matched_expr 
	: ...
	| unary_op_eol matched_expr {{}}
	| <at_op> 'op' matched_expr  {{}}
	| <capture_op> 'op' matched_expr {{}} 

unmatched_expr 
	: ...
	| unary_op_eol expr 'expression' {{}}
	| <at_op> 'op' expr 'expression' {{}}
	| <capture_op> 'op' expr 'expression' {{}} 
         ...
	;

The next parsed item drops the next identifier, unless if the next identifier is required for a valid following expression.

I believe this may be related to glr backtracking and actionsForCurrentToken. As changing expr to either unmatched_expr or matched_expr seems to create correct parses for their respective cases, and trying it out in the grammar tab (which seems not to be affected by actionsForCurrentToken) returns the proper value.

I'm not sure of the issue, as the scanner state is properly restored(?).

I.E.

&3
1

will properly display both expressions where as.

&3
foo()

will only have &3 and () as the expressions.

As a consequence, the following parses, when the following ) should be had.

@1
(3

Example with <at_op>

defmodule Nock do
  @spec nock(Noun.t(), Noun.t()) :: 1
  def nock(subject, formula) do
    nock(subject, formula, %Nock{})
  end

the def is missing and the nock( ... is next.

Example with <capture_op>

  &3
  foo()

The foo is missing and the next token is ()

Example with unary_op

not not 1

f  1

The next expression is 1

Analysis

It seems that putting the operator within a expression does not make a difference

4 * +1
f  1

will be treated as if it were

4 * +1
1

However, Putting a ; between the nodes make it work, as per

not not 1;

f  1

This may be related to #29, as the <unary_ops> seem to trigger similar errors

Debugging Information

To better debug what is going on I started to compare

4 * +1 # or not 1 ... doesn't particularly matter
f  1
# vs
4 * 1
f  1

The parser should mostly treat these the same, However, after the expr_list is made for both, the first one back tracks to be an unmatched_expression which is the next rule after matched_expression. Seems the glr back tracking kicks in.

One step later