Add something like `=+` to match the existing `+=`

Currently, += prepends a PEG to the supergrammar’s rule.

We have been building a parser that uses inheritance to extend a grammar with error recovery productions, and find ourselves wishing for something like a =+ that appends to the supergrammar’s rule:

SomeNT =+ SomeErrorRecoveryPEG
// ... would be nice if it expanded to...
SomeNT = Rules | From | The | SuperGrammar | SomeErrorRecoveryPEG

Would a patch implementing a =+ operator be welcome?

Building on this question, if it were considered valuable to have both += and =+, would it make any sense to have += append and =+ prepend?

Finally, if =+ is a bad choice of operator, perhaps |= is a better choice for the appending variant?

[pdubroy]

Closing this since the super-splice operator has landed. @tonyg, have you had a chance to give this a try?

[elgertam]

@pdubroy I have been working with @tonyg on the project he mentioned.

I really love the ... syntax! I just tested it out on our parser, and it has cleaned up the one particularly hairy case where we had to copy-paste several lines from the parent grammar into the child grammar.

Unfortunately, most of the candidates for clean up couldn’t be change due to arity checks on the semantics methods.

For example, let a parent grammar be

FooGrammar {
  Foo = Bar+

  Bar = "<" Baz ">"

  Baz = letter+                   -- name
      | digit+ ("." digit+)?      -- number
}

with semantics

const fooSemantics = {
  Foo(bar) {
    return bar.ast();
  },
  Bar(_oBrace, baz, _cBrace) {
    return baz.ast();
  },
  Baz_name(id) {
    return id.sourceString;
  },
  Baz_number(whole, _dot, frac) {
    return parseFloat(this.sourceString);
  }
};

.

I would like to define a child grammar

SonOfFooGrammar <: FooGrammar {
  Bar := ...
       | errorLine   -- error

  Baz := ...
       | (~">" any)+ -- error

  errorLine = nonnl+ (lineTerminator | end)

  nonnl = ~lineTerminator any
  lineTerminator = "\n" | "\r"
}

with semantics

const sonOfFooSemantics = {
  ...fooSemantics,
  Bar_error(_err){
    console.warn(`Parse error: Bar: \`${this.sourceString}\``);
  },
  Baz_error(_err){
    console.warn(`Parse error: Baz: \`${this.sourceString}\``);
  },
};

.

However, because of the arity rules, I have to instead define SonOfFooGrammar as

SonOfFooGrammar <: FooGrammar {
  Bar := "<" Baz ">" -- nonError
       | errorLine   -- error

  Baz := ...
       | (~">" any)+ -- error

  errorLine = nonnl+ (lineTerminator | end)

  nonnl = ~lineTerminator any
  lineTerminator = "\n" | "\r"
}

with semantics

const { Bar: _Bar, ...sonOfFooSemantics } = {
  ...fooSemantics,
  Bar_nonError: fooSemantics.Bar,
  Bar_error(_err){
    console.warn(`Parse error: Bar: \`${this.sourceString}\``);
  },
  Baz_error(_err){
    console.warn(`Parse error: Baz: \`${this.sourceString}\``);
  },
};

.

This isn’t so bad (though I find this usage of ES6’s destructuring assignment to be a bit too clever).

I personally would find it quite elegant for the extension to work as in the former case, though I don’t (yet) know enough about Ohm’s internals to know how feasible this change would be. If there’s no reason why this wouldn’t work, I could begin working on a PR.

Regardless, I love the new super-slice feature and I think it can be quite useful going forward.

I’m also curious about the Schärli-style traits mentioned above. Tony and I had independently discussed something like “traits” for Ohm, and both of us thought a feature like that would be useful.