The Great Syntax Regularization

[sebastianriese]

The current syntax has some irregularites (e.g. some block directives use colons others don't). We aim to make the syntax regular to improve usability.

[sebastianriese]

While we break the syntax, we might change the semantics of the stack references $$, $1 and so on. Instead of referencing the stack object they should reference what is now $x.sem (as they do in yacc/bison). While we do not want to supply @$, @1, and so on for position marks (reason: python uses @), we shall supply an API to access positions/stack objects explicitly, e.g. self.res, self.at(n). An alternative is to supply $@$, $@1, etc.

Rationale: the .sem is useless boilerplate, due to automatic position tracking position references are seldom (other than to assign a position to a syntax tree object).

[horazont]

First of all, is it feasible (and worth the effort) to provide something like %version to support the old syntax? Just as an suggestion, I don’t think it’s particularly needed.

With regard to the syntax to access positions, I don’t care too much. It would also be fine to simply use something along the lines of self.at(n).pos or self.pos[n] or something like that. It’s only ever needed to attach it to an AST node.

[sebastianriese]

Using a version tag is problematic (unless we require it to be in the first line and scan for the version tag to select the parser), using a command-line switch is easy (just keep the old parser unchanged, add the new parser). One can also think about an automatic conversion/patch generation tool. Otherwise the old parser would have to be shipped forever.

[horazont]

I was just thinking because syntax changes might come up again in the future. I don’t think it makes sense to do this in such a pre-release state.

[sebastianriese]

Symbol lists should allow parentheses for line continuation, for example it should be possible to write

%x (
      FOO,
      BAR,
      BAZ
)