bd82

7 ms·

1.
by bd82 7y ago
Even the Antlr FAQ mentions that "almost no one uses parser generators to build commercial compilers." * https://github.com/antlr/antlr4/blob/master/doc/faq/general.... * See: &quot
2.
by bd82 7y ago
Some of the top of my Head: - Antlr (https://github.com/antlr/antlr4/blob/master/doc/javascript-target.md) - PegJS (https://github.com/pegjs/pegjs) - Nearley (https:&#x2F
3.
by bd82 7y ago
Luckily there are many Parsing Libraries in the JavaScript eco-system, So we won't have to find out if this convoluted approach is worthwhile :) - https://tomassetti.me/parsing-in-javascript/
4.
by bd82 7y ago
I develop a parsing library for fun and I don't think that would be an easy or useful interview question. Maybe it makes sense if you assume the input has already been tokenized so you are not expected to deal with the minutiae of stri
5.
by bd82 7y ago
You can find it At: https://github.com/SAP/chevrotain
6.
by bd82 8y ago
I've created a Parsing Toolkit (for JavaScript) which I believe fulfills 7/10 of the requirements described. Chevrotain - https://github.com/SAP/chevrotain The list of features can be found here: - https:&#
7.
by bd82 8y ago
I kept putting of switching from Travis to Circle-CI in one of my open source projects, But when I did get around to it the whole thing went pretty smoothly and easily and I regret not doing it earlier. 1.The builds are much faster now. 2.
8.
by bd82 8y ago
Thanks. Chevrotain is an LL(K) Parser library, or more precisely SLL(K), It looks up-to K fixed token ahead to choose the next alternative. Because it is just a library to assist in hand crafting recursive decent parsers, the same limitatio
9.
by bd82 8y ago
If you are looking for an alternative to standard parser generators you may wish to have a peek at Chevrotain. * https://github.com/SAP/chevrotain Instead of using an abstraction of a declarative grammar definition and
10.
by bd82 8y ago
Ohm has several impressive features, such as separation of grammar and semantics and incremental parsing capabilities. The base performance however very low, as in two orders of magnitude lower than most other parsing libraries in JavaScrip
11.
by bd82 8y ago
Have a look at this: https://tomassetti.me/parsing-in-javascript/#chevrotain This is Not exactly a parser generator but an internal JavaScript DSL for writing parsers, but it does meet the criteria for a more verbose s
12.
by bd82 8y ago
Maybe this example will help? https://github.com/SAP/chevrotain/blob/master/examples/gramm... It is implemented using a parsing library so the lookaheads are automatically performed by the library,
13.
Show HN: Chevrotain – Parser Building Toolkit for JavaScript(github.com)
2 points by bd82 9y ago|0 comments
14.
Show HN: Chevrotain – Parser Building Toolkit for JavaScript(github.com)
2 points by bd82 9y ago|0 comments
15.
Chevrotain – Fault-Tolerant Parser Building Toolkit for JavaScript(github.com)
1 points by bd82 9y ago|0 comments
16.
Chevrotain – Parser Building Toolkit for JavaScript(github.com)
1 points by bd82 9y ago|0 comments
17.
by bd82 9y ago
Perhaps Antlr?
18.
by bd82 9y ago
Incremental parsing is indeed amazing for IDE scenarios. But you still have to parse the entire file at least once. For example it takes 15 seconds to parse lodash.js with Ohm (on my machine) using the sample EcmaScript grammar. But what h
19.
by bd82 9y ago
I don't understand the question. I am not familiar with Haskell but from what I understand Pandoc is a group of hand crafted parsers (readers) for markup formats. How does this relate to a discussion on the relevance of parser generato
20.
by bd82 9y ago
Even the creator of Antlr (Terence Parr) Said: "In my experience, almost no one uses parser generators to build commercial compilers." https://github.com/antlr/antlr4/blob/master/doc/faq&#x
21.
by bd82 9y ago
It did not exactly went away. It is still possible to embed semantics inside an Antlr4 grammar. For example see the Antlr4 EcmaScript grammar sample: https://github.com/antlr/grammars-v4/tree/master/ecmas
22.
by bd82 9y ago
One option would be to use a Parser that supports fault tolerance and error recovery. In hand crafted parsers this error recovery may be added manually (but resulting in a-lot of work...) For example: search for the word "recovery&
23.
by bd82 9y ago
Ohm is very impressive. Specifically: 1. The separation of Grammar and Semantics. 2. Handling left recursion in a top down (peg) parser. 3. Incremental parsing. I think that the one feature missing to make it applicable for more
24.
by bd82 9y ago
That is a very good question because afaik many(most?) commercial (meaning "serious"...) programing languages are developed using hand crafted recursive decent parsers which usually mean that the first alternative takes precedence
25.
by bd82 9y ago
Acorn has a plugin system: https://github.com/ternjs/acorn#plugins But as far as I know Esprima does not: https://github.com/jquery/esprima/issues/1168 I have no idea about Cherow...
26.
by bd82 9y ago
beating Acorn & Esprima in raw performance is very very impressive. But please consider that performance is not the only factor when building parsers. Extensibility is a major concern. Afaik Babylon (used in babel) is a fork of Acorn pa
27.
Show HN: JavaScript Parsing Libraries Benchmark(sap.github.io)
2 points by bd82 9y ago|0 comments
28.
Show HN: JavaScript Parsing Libraries Benchmark(sap.github.io)
2 points by bd82 9y ago|0 comments
29.
by bd82 9y ago
I'm less familiar with ometa. Chevrotain shares two main ideas/concepts with Ohm. 1. Separation of grammar and semantics, but in a less opinionated manner as it does not enforce the separation as Ohm does (it is still possible t
30.
by bd82 9y ago
I'm not familiar with Smug, but I would guess that the combinator is implemented using LISP macros which are than expanded into "real" source code (lisp lists) which is evaluated directly and can halt on break points. In

More ›