Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ohm: Parsing Made Easy

nextjournal.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Ohm: Parsing Made Easy

#71

Post by nerdponx »

tomp wrote: post #10
shalabhc wrote: post #8

Earlier quoted context omitted.

Is this a limitation of the PEG syntax itself? IOW, is it possible to identify ambiguities in grammars defined as PEGs?

Possible? Maybe. But the problem is more that, (according to Wikipedia), the choice operator in PEGs (i.e. e1 | e2 ) is in fact defined as ordered choice, i.e. it prefers the first alternative. They try to sell this as a "solution" to ambiguous grammars, as an advantage, but they're just ... wrong . It's as if Java, when resolving method overloading, arbitrarily prefered the method that's declared first in the source…

Is ordered a choice a necessary property for PEG parsing? Maybe PEG parser generators should have an "unordered mode".

Re: Ohm: Parsing Made Easy

#72

Post by swsieber »

iamleppert wrote: post #66

I've really tried to get on with parser generators, but I've found they are hard to use, hard to debug and the languages/DSLs are clunky and weird. Except for cleanroom academic implementations, or for language designers who can afford the time and resources to learn and get good at a parser generator, I've found its better to simply use regular expressions to do matching and a functional language that can build up a…

Agreed.

They still do have there place though. I, for instance, was able to import the MySQL grammar for Antlr4 from the github Antlr4 grammar repository and got it working. I use it to mangle table names of all mysql requests during tests to be able to easily isolate tests within a single database that would otherwise stomp on each other.

But I don't think I'd use one for any custom parsing, like my own compiler or any grammar I get to define.

Re: Ohm: Parsing Made Easy

#73

Post by nerdponx »

bd82 wrote: post #68
iamleppert wrote: post #66

I've really tried to get on with parser generators, but I've found they are hard to use, hard to debug and the languages/DSLs are clunky and weird. Except for cleanroom academic implementations, or for language designers who can afford the time and resources to learn and get good at a parser generator, I've found its better to simply use regular expressions to do matching and a functional language that can build up a…

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/general.... . (no anchors for direct link).

Does Pandoc count? IIRC it implements CommonMark in a PEG.

Re: Ohm: Parsing Made Easy

#74

Post by rwmj »

derriz wrote: post #56

Sorry to be negative and this comment probably doesn't belong in a discussion about a specific parsing toolkit but I've become unconvinced that parser generators are useful. My experience is limited to Yacc/lex back in the old days (quickly jumped to Bison/flex), more recently Antlr and a couple of functional parser combinator libraries. In nearly all case it was to deal with "real world" (i.e. not toy) programming l…

I was surprised when I revisited the GCC code after 20 years to find that GCC switched from using flex/bison to using a hand-written recursive descent parser (even for C++ which is reputed to be "impossible" to parse).

Here's the C parser: https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-parser...

and the C++ parser: https://raw.githubusercontent.com/gcc-mirror/gcc/master/gcc/...

Re: Ohm: Parsing Made Easy

#75

Post by bd82 »

nerdponx wrote: post #73
bd82 wrote: post #68

Earlier quoted context omitted.

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/general.... . (no anchors for direct link).

Does Pandoc count? IIRC it implements CommonMark in a PEG.

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 generators / libraries?

https://github.com/jgm/pandoc/tree/master/src/Text/Pandoc

Re: Ohm: Parsing Made Easy

#76

Post by kvlr »

wybiral wrote: post #20

Those popup chats on articles like this gross me out... I'm just trying to read something, stop phishing for my email address.

Sorry about that. We didn't mean to show it to visitors and a bug prevented us from quickly disabling it. We've now removed it completely.

Re: Ohm: Parsing Made Easy

#77

Post by bd82 »

pdubroy wrote: post #65
bd82 wrote: post #39

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 than rapid prototyping and teaching purposes is performance . In this benchmark I've authored: http://sap.github.io/chevrotain/performance/ Which uses the simple JSON grammar it is about two…

Thanks! Yes, we are aware that Ohm's batch parsing performance is not great. In practice, it has been fast enough for our uses -- especially since we implemented incremental parsing. With incremental parsing, Ohm's ES5 parser can be as fast as hand-optimized parsers like Acorn. But you're right, there is definitely room for improvement. So far, we have been much more concerned with making Ohm easy to learn and pleasa…

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 happens if my IDE has 200 files and 400KLOC of code?

From my personal experience, if you want high performance you have to treat it as an ongoing feature, this could mean:

  * Inspect each new version for performance regressions.

  * Reinspect previous feature implementations for possible 
    performance optimizations.

  * keep track of underlying performance characteristics of your 
    runtime, for example V8 hidden class changes and other 
    de-optimization causes. These characteristics may (and do!) 
    change over time with newer releases of V8...
It would be interesting to try and optimize Ohm.js I even contributed some optimizations to Nearley.js in the past. But I'm afraid I just don't know when I will get around to trying this with too many projects and ideas competing for my time. :(

Re: Ohm: Parsing Made Easy

#78

Post by corndoge »

iamleppert wrote: post #66

I've really tried to get on with parser generators, but I've found they are hard to use, hard to debug and the languages/DSLs are clunky and weird. Except for cleanroom academic implementations, or for language designers who can afford the time and resources to learn and get good at a parser generator, I've found its better to simply use regular expressions to do matching and a functional language that can build up a…

I find them pretty useful, the DSLs are generally just slightly modified version of BNF which is pretty straightforward to pick up. Bison + flex is my tool of choice for extensive CLI interfaces in C projects. Regex is useful (hence flex) but for higher level constructs without reinventing the wheel I think it's hard to do much better than a parser generator.

Re: Ohm: Parsing Made Easy

#79

Post by richard_shelton »

I really liked what was done in STEPS project. I learned a lot from their repors. For example, this Ian Piumarta's paper is absolutely beautiful [1]. I also spent a lot of time learning oMeta [3] system by Alessandro Warth.

And, honestly, now I see nothing really new in Ohm. Basically, it's just some tweaking of the same tech. Moreover, Ohm was made for isolated parsing task. For me it's a step back. My point is that the parsing alone is not very interesting thing, for making DSLs you need to have other tools too. In the Ian Piumarta's paper we had a minimalistic program transformation system [2]. Remember original META II [4]? It was a compiler-compiler (metacompiler), not just a parser generator. I'm really curious to know why the authors decided this time to limit themselves by only parsing.

[1] http://www.vpri.org/pdf/tr2010003_PEG.pdf

[2] https://en.wikipedia.org/wiki/List_of_program_transformation...

[3] http://www.vpri.org/pdf/tr2008003_experimenting.pdf

[4] http://www.ibm-1401.info/Meta-II-schorre.pdf

Re: Ohm: Parsing Made Easy

#80

Post by yazaddaruvala »

pdubroy wrote: post #33
simplify wrote: post #27

I've had great experience using PEG.js, another PEG-based parser generator. How does Ohm compare?

It's somewhat similar, but the main difference is that Ohm has a strict separation between syntax and semantics. We think this has several benefits, which we describe a bit here: https://github.com/harc/ohm/blob/master/doc/philosophy.md Another difference is that Ohm grammars can contain left recursion -- both direct and indirect. IMHO this is a pretty big deal, but I know that some people don't agree, and think that…

Any thoughts on https://github.com/nikomatsakis/lalrpop, and it's first priority being "Nice error messages"?

Sidenote: I created this issue a while ago, but never got a response: https://github.com/nikomatsakis/lalrpop/issues/180

Post reply on HN