3 ms·
I took a DB implementation class my senior year of college (I still giggle at our team name: "YourSQL"). I wrote our parsers. First was the DDL, and I wrote the
by jjice 4y ago
I took a DB implementation class my senior year of college (I still giggle at our team name: "YourSQL"). I wrote our parsers. First was the DDL, and I wrote the lexer and parser by hand (this is all in C). It's not necessarily a hard task, but dealing with where the hell that segfault is coming from takes a lot more time. I convinced the professor (after a short essay) to let us use lex and yacc since even PostgreSQL uses them. Made the job so much easier to write and modify.
I often see people saying parser generators are a waste of time for various reasons. There are a good few cases I'd agree in:
- Performance is critical
- You want lots of power for error reporting
- You really want to learn about recursive descent parsers by writing on by hand
Personally, the least interesting part of a compiler after the first time is lexing and parsing for me. Code gen, type checking, optimization, etc are all the real meat and potatoes for me, and I find parser generators to be a great time saver.
In general, I see generated code becoming less common (could just be me), which I don't think is a bad thing. I see a lot less CFG parsing tools these days too, aside from parser combinators. Could just be me not paying attention, but it's in interesting way we've progressed.
If I was working on a new language - hobby or professional - I'd start with parsing tools and swap them out when it became worthwhile.