ANTLR may be superior in some way; it’s also strictly unnecessary.

I’d argue against noobs (the people ostensibly targeted by Mr. Bright’s original article) thinking that they need to buy a book to learn a…

ANTLR may be superior in some way; it’s also strictly unnecessary.

I’d argue against noobs (the people ostensibly targeted by Mr. Bright’s original article) thinking that they need to buy a book to learn a necessary technology in order to build a language. There’s too much mystification of language design as is.

My point, in the implementation section, is not that using YACC is a good idea (it isn’t) or that using LEX is necessary, but that (contra Mr. Bright) using standard UNIX dev tools isn’t some kind of huge portability concern.

Generally speaking, I think the best way to implement a parser is to design your syntax so that you don’t actually need something as complicated as LEX (let alone YACC) — avoid supporting infix if possible, and definitely avoid supporting implicit order of operations— and then use the simplest tech available (which may be as easy as a string split, or may involve several regex matches). But, threading logic through LEX is fine too, although it means you’re writing your interpreter in C which is probably a mistake.

Just as a personal quirk, I like to minimize the dependencies in any project I work on, favoring features that are either standard or exist in all dominant implementations. So, between ANTLR and LEX I’ll generally choose LEX, simply because it’s 70s tech that’s already on everybody’s computer. But, if you aren’t writing your initial implementation in a high level language with built-in support for extended regex, you’re going to have a bad time to begin with.