Shorthand for Semantic Actions

It would be nice to add shorthand for semantic actions.

Say, instead of writing { return value }, we write, for example { extract } which is defined in the initializer.

For example:

{
  function extract(value) {
    return value;
  }
  function concat(head, tail) {
    return head ? [head].concat(tail) : [];
  }
  function toAddExpr(head, tail) {
    return { type: 'addExpr', expressions: concat(head, tail) };
  }
}

List
  = '(' _ head:Item? tail:( _ ',' _ value:Item { extract } )* _ ')' { concat }

// Another kind of list
Add
  = '(' _ head:Multiply? tail:( _ '+' _ value:Multiply { extract } )* _ ')' { toAddExpr }

First, this will make us able to reuse functions… in a nicer way 😄 Second, this will make our grammar a bit more readable.

I believe it also will be more useful when the expression contained in the action shorthand is a member expression { foo.bar.baz } instead of just identifier { foo }. So that grammar writers can organize their functions inside of an object or even a module.

[futagoza]

Actually, I have been thinking, these changes might just work:

CodeBlock "code block"
  = "=>" _ expession:CallExpression {
       return `return ${ expession };`;
     }
  / "{" @Code "}"
  / "{" { error("Unbalanced brace."); }

// Will be based on ECMAScript's CallExpression
CallExpression
  = ...
  / MemberExpression

// Will be based on ECMAScript's MemberExpression
MemberExpression
  = ...
  / ValidIdentifier

// Change `LabelIdentifier` into `ValidIdentifier`

This way will still require to integrate some stuff like ECMAScript’s primary expressions (numbers, booleans, arrays, etc) to be used as arguments, so will need to carefully figure out what to add.

---

balancing brackets and braces

This won’t be fixed until a proper JavaScript parser is built into the PEG.js parser, but to be honest I’m slightly hesitant about this as there are a few plugin projects that generate parsers in other languages (C, PHP, TypeScript, etc), and I also am working on a computer language that I hope to one day generate parsers in.

---

Alongside PEG.js v0.12, I will be working on OpenPEG, which will offer an NPM package that is essentially a stripped down version of PEG.js without any JavaScript and parser generation involved, but enough features so that JavaScript-based projects like PEG.js can use it as a backend. When v0.12 comes out I will try and ensure any plugin projects that generate custom parsers are notified of OpenPEG, and before v1 implement a full ECMAScript 2015 parser into the PEG.js grammar parser.

[StoneCypher]

None of this should happen. There should be no short syntax.

None of this is necessary if we just parse arrows normally, instead of trying to shim them in sideways.

Whereas this is a neat idea, it sets up extensive grammar ambiguities versus JavaScript. Anyone who’s parsed JS and remembers what a debacle with was knows that this will basically murder a parser.

Instead of trying to create fancy new stuff, we should just support Javascript. Arrow functions are older than ES6 and ES6 is from 2015. This was solved six years ago. No invention should happen here.

The pipe operator is badly flawed and probably won’t actually make it into Javascript, and the both the language that it originally comes from (F#) and the language that popularized it (Elixir) are backing away from it. Besides, this isn’t piping in any sense.

The reason PEG was so successful was that it was minimal, and stayed close to the language, allowing it to be fast, small, and predictable.