Can you handle indexing inside ExpressionBuilder?

[toddobryan]

In languages with array/list indexing, an index into an array/list counts as an expression, so you should be able to index that thing and use it in other expression operations. Examples are things like:

a[0]
a[0][0]
[1, 2, 3][0] + [[1, 2], 1][0][0]

but it also needs to be the case that you can identify that, like a bare identifier, something like a[x] can be assigned to, which is the case for bare identifiers (like a), but not for expressions in general (like a + 2).

Should I try to handle this inside the ExpressionBuilder (by, say, creating a postfix group with a seq3(char('['), loopback, char(']')) parser or should I move this outside so that I have something like a listRef parser.

The issue with the first is that something of the form a[0] is just an expression, so determining if something is assignable would have to be a semantic check and can't be guaranteed by the parser.

The issue with the second is that any strings of the form a[0] would not automatically be part of the ExpressionBuilder and so handling the operations on expressions (like prefix, wrapping, and left and right associative operations) wouldn't be included automatically.

I checked the Dart example grammar, but it doesn't use ExpressionBuilder. The regexp parser uses postfix for the range, but you can only have numbers in the brackets, so there's no recursion. So I guess the other possibility is that I should just forgo using ExpressionBuilder and define the family of grammars that encodes all the operations separately and handle precedence and grouping and stuff manually.

Any insight appreciated.

[renggli]

Personally I would only put the "mathematical" operators inside the expression builder. The expression builder is supposed to make operator precedence and associativity simple to get right, but with the arrays and assignments the difficulty is elsewhere.

The code below parses your examples. The trick is to parse the assignment target as a variable followed by an optional repeated indexed access.

class AssignmentGrammar extends GrammarDefinition {
  @override
  Parser start() => (ref0(assignment) | ref0(expression)).end();
  Parser assignment() =>
      ref0(variable) & ref0(indexed).star() & char('=') & ref0(expression);
  Parser expression() {
    final expr = ExpressionBuilder<dynamic>();
    expr.primitive(ref0(number));
    expr.primitive(ref0(variable));
    expr.primitive(ref0(literalArray));
    expr.group().postfix(ref0(indexed), (a, b) => (a, b));
    expr.group().left(char('+'), (a, op, b) => (a, op, b));
    return expr.build();
  }
  Parser number() => digit();
  Parser variable() => letter();
  Parser literalArray() =>
      char('[') & ref0(expression).starSeparated(char(',')) & char(']');
  Parser indexed() => char('[') & ref0(expression) & char(']');
}

[toddobryan]

Ah. I left out another pertinent example. Function calls can also be expressions.

myFuncThatReturnsList()[3]

which could be a value or the left side of an assignment. The thing in front of the index need not be just a identifier.

(I'm not actually sure if something like

[1, 2, 3][1] = 0

would be legal. I'm implementing a pseudocode language for a course I'm teaching, so only a vague spec. If this is legal, it would be a statement with no observable side effect, so not super important, but something like

["a", varb, "c"][1][0] = 3

should work if varb is an assignable array.)