Implemented mapping syntax in peg grammars

[QaDeS]

This PR enables direct mapping of string literals without using const maps, removing duplication in the grammar files.

Before:

{{
const DIRS = {
  l: "left",
  r: "right"
}
}}

start =
  ( "l"i
  /  "r"i
  ) { return DIRS[text()] }

After:

{{
// Nothing to see here
}}

start
  = "l"i:"left"
  /  "r"i:"right"

I chose the : as separator so you can translate your existing maps with minimal effort, another one that might make sense for reducing ambiguity might be % or even ->. Awaiting your feedback on possible improvements :)

[Mingun]

What's wrong with:

{{
// Nothing to see here
}}

start
  = "l"i { return "left";  }
  / "r"i { return "right"; }

?

[QaDeS]

Generally nothing, but it's so verbose that you tend to use a const instead and ignore the repetition. I think that it promotes the use of a bad pattern.
The way I implemented it also saves a method call (or map lookup, respectively) in the resulting parser, with marginal overhead in the compilation step.

[hildjj]

I'm not terribly excited about this one. I don't think it's generally-useful enough to add syntax for.

I'm willing to think about it some more, though.

[QaDeS]

I'm all in for exploring if/how a syntax for mapping can be so useful that it justifies an addition to the grammar. Or maybe there's a way to implement this as a plugin? Don't have a lot of experience with the whole parsing shebang, so I'm going to trust your judgment on this.

Currently, I am working on a Tailwind-like CSS creation mechanism, which requires a lot of expanding letters to keywords and mapping in general. In some of your example grammars, and also the core peggy one, I spotted similar patterns. Mapping characters like & and ! to node types, or (un-)escaping seem to be very common use cases.

So the ideas I am now playing around with are:

• simple string-to-string mappings (working)
• string-to-array mapping (kinda working)
• escaping / embedding via template strings (soon to be working, especially useful for choice and class expressions)
• directly using const maps inside the parser, hopefully with appropriate expectation and error handling

Generally, I'm just fiddling and learning about the inner workings of Peggy right now. If something useful comes out of it, even better.

Settled on % instead of : for now, btw. Makes it more clear that something very different is happening there.

[hildjj]

I don't find this easier to read or maintain. Are there other examples you think might benefit from this approach? Maybe add a new example that shows the full power?

[Mingun]

Agree. In any case it is better to use -> or =>

[hildjj]

Oh, if it was => I might be able to get excited about this.

[hildjj]

Particularly if we also added &=> and !=> at the same time...

[hildjj]

I'm going to close this for now. If we come up with better use cases, I'm open to further discussion.