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

Plan to throw one away

garethrees.org

Post reply on HN
Print view View original

41–50 of 88 posts

Re: Plan to throw one away

#41

Post by dang »

legulere wrote: post #38

Wow, this seems quite idiotic to me. Sure, recursive descent parsers have some theoretically inferior properties to other techniques, but in reality they're much better because you can actually handle errors in a user-friendly way. That's why basically every bigger compiler uses handwritten recursive descent parsers.

> this seems quite idiotic to me

Please don't be uncharitably dismissive. The author didn't throw away the parser because it was recursive descent—in fact he explicitly excludes that as a reason.

(The rest of your comment is fine.)

Re: Plan to throw one away

#43

Post by Athas »

jhallenworld wrote: post #9
jaytaylor wrote: post #4

Are Lex and Yacc still the state of the art 20 years later?

Be prepared to just use the generated tables and forget the generated code: The generated code is not so great if you have an event driven environment: I mean I want to push 50 bytes into the compiler, instead of having it request the next input character. This means it's not so great for a repl, unless some other pre-parser gives complete translation units to lex/yacc. I think Yacc has a pretty primitive conflict re…

> The generated code is not so great if you have an event driven environment: I mean I want to push 50 bytes into the compiler, instead of having it request the next input character. This means it's not so great for a repl, unless some other pre-parser gives complete translation units to lex/yacc.

This actually works quite well in [Happy](https://www.haskell.org/happy/), the Yacc-alike for Haskell, so it is not a fundamental limitation of Yacc-style tools. In Happy, it works by generating monadic code and using a monadic action for token reading, which you can then make event-driven.

Re: Plan to throw one away

#45

Post by mcv »

I would like to know how the CTO responded to the idea of throwing away the code he'd been slaving on at the very last minute, and replacing it with something that someone cobbled together in two weeks (but worked).

Re: Plan to throw one away

#46

Post by dvirsky »

hinkley wrote: post #34

As a corollary: https://en.wikipedia.org/wiki/Ship_of_Theseus You can replace all the parts of your crappy v1.0 code and still call it the same code base. That's what the smart ones go around doing quietly.

While in most cases it's probably a better option, I think that in this case there wasn't time to do that. I would probably explore the option to still use the parser, and have it generate an AST first, and from there go pretty much in the direction of the author.

Re: Plan to throw one away

#47

Post by drothlis »

legulere wrote: post #38

Wow, this seems quite idiotic to me. Sure, recursive descent parsers have some theoretically inferior properties to other techniques, but in reality they're much better because you can actually handle errors in a user-friendly way. That's why basically every bigger compiler uses handwritten recursive descent parsers.

There's a really gorgeous technique for implementing good error messages with LR parsers: http://lambda-the-ultimate.org/node/4781#comment-76724

(I haven't used the above personally, but the Golang parser does.)

Personally I have used PEG parsers and I was able to provide great error messages, by using the "cut" operator in the appropriate places in the grammar (see comments earlier in the thread I linked above).

Re: Plan to throw one away

#48

Post by scotty79 »

mcv wrote: post #45

I would like to know how the CTO responded to the idea of throwing away the code he'd been slaving on at the very last minute, and replacing it with something that someone cobbled together in two weeks (but worked).

I bet he welcomed one less responsibility.

Re: Plan to throw one away

#49

Post by tankenmate »

mcv wrote: post #45

I would like to know how the CTO responded to the idea of throwing away the code he'd been slaving on at the very last minute, and replacing it with something that someone cobbled together in two weeks (but worked).

From the sound of the description the original CTO authored code was cobbled together and its replacement was properly engineered (for some value of properly).
Post reply on HN