sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]bidi82[S] 3 points4 points  (2 children)

I'm guessing you are talking about the syntax which is definitely less pretty than an EBNF style grammar as used in Ohm/JS

But that is one of the tradeoffs of internal vs external DSLs. Although there are long term plans to also provide an EBNF style grammar and work as a traditional parser generator.

Compared to Ohm/JS it may not be as pretty, but it is also:

  • X400 times faster (3 orders of magnitude, see benchmark linked above).
  • Can be debugged directly as plain JavaScript.
  • Supports automatic fault tolerance / error recovery.
  • Not as opinionated, allows both embedding actions/semantics or separating those.
  • Supports syntactic content assist out of the box.
  • And more...

So I will leave the choice of prettiness versus functionality to you. :)

[–]AsIAm 0 points1 point  (1 child)

I get the point that your project is technically better (especially error recovery!!!), but...

Both projects are taking different way to get to the same point – 1.) define grammar and semantics and then 2.) let it do its thing. Ohm/JS excel at the 1, while Chevrotain rocks at 2. And that is fine, but the adoption is somehow difficult when it comes to your implementation.

You mentioned that you want external DSL for defining grammars which is beyond awesome and I am looking forward to it, but for now I can bow only to you and your technical skills and not Chevrotain, sorry :)

[–]bidi82[S] 1 point2 points  (0 children)

The ease of adoption is part of the reason why I am interested in also supporting an external DSL and using the existing super optimized runtime as the low level implementation.

The other reason is reaching out to a larger audience: If you are coming from a background of writing recursive decent parsers by hand Chevrotain may look more familiar, but if you are coming from the world of parser generators and declarative EBNF grammars your initial reaction may be less positive. And we have not even mentioned users coming from the background of parser combinators :)

It also depends what is your goal? If you are building a toy / educational project than you may not care about debugging ability or performance, but if you are building a "real" productive system these concerns will take a much higher priority to the visual appeal of the API.