recommending a parser for ide extension

[samuelstroschein]

From Discord

[openscript]

Do we want a Parser Builder (Runtime) or Parser Generator?

[samuelstroschein]

Under the assumption that most people will consume a parser via a plugin, a parser generator that yields less runtime overhead seems preferrable. But, as mentioned in #381 (comment), recommending a parser should optimize for building grammars

[samuelstroschein]

From Chevrotain's docs:

A Parser Generator adds an (unnecessary) level of abstraction between the grammar implementation and the actual parser. This is because the grammar is written in a different language than the target runtime.

Chevrotain looks really good #381 (comment)

[samuelstroschein]

inlang <0.3

I chose peggy.js very much because one can write plain JavaScript.

The requirements were:

1. The grammar can be stored in another file to fetch the grammar file dynamically e.g. define your grammar, provide a link to the grammar and inlang will execute the grammar during runtime. THIS IS NOT A REQUIREMENT ANYMORE. The parser will likely be a plugin that contains the grammar or even the generated parser

2. Make it easy to write grammar. Using JavaScript in the grammer was easier than writing custom syntax that needs to be learned (even though a performance penalty is likely).

Inlang >0.3

Developers should be free to choose the parser they desire. The requirements for a reference parser a la "hey, use this parse to get going" are likely:

1. Optimized for ease of use rather than performance.

Developers need to get started quickly using inlang. If performance issues occur, the parser can be switched at some point. Since inlang is unopinionated about the parser, a switch can be conducted with a plugin update.

Peggy was great because JavaScript can be used, but the learning resources are not comprehensive. Thus, someone should compare current JS parsers for ease of use.

[openscript]

Which other Inlang components need to use the parser? Linter? Editor?

[samuelstroschein]

In the future, likely all components.

But, inlang should be unopinionated and do not include a parser as part of inlang itself.

[samuelstroschein]

Chevrotain does indeed look really promising.

• everything in JavaScript makes building grammars easier
• no parser generator required, increases the DX
• fast

[openscript]

• Seems to be maintained

[samuelstroschein]

Further progress is tracked in #746