I think this makes it sound a lot more difficult than it has to be, with the formal theory.

When it's really one of the most simple things if you divide it in parts and look at it from a tokenizer (string to list of tokens) and parser on top. Where the tokenizer can usually be very simple: a loop, large switch on the current character, where a choice is made on "what can this be", and making it into a formal token or error. Then a simple recursive parser that can almost be a 1 to 1 copy of the (E)BNF.

▲

jrop a year ago | parent | next [-]

I love writing parsers like this. Add in Pratt Parsing for operator precedence and writing parsers can be really easy.

▲

detourdog a year ago | parent | prev | next [-]

I got the impression the author was trying to add higher level reasoning to the chosen term for string to AST parsing.

I felt that they were pointing out how the cognitive load of understanding is effected by word choice.

	▲	a year ago \| parent [-]
		[deleted]

▲

joz1-k a year ago | parent | prev | next [-]

I had exactly the same feeling as you after reading the article. And interestingly, all production parsers for all major languages are hand-written recursive descent parsers. On the other hand, if you inspect the actual code for these production parsers (even for newer languages like Swift, Scala, Kotlin, or Rust), the complexity and amount of code is still quite staggering.

▲

taeric a year ago | parent [-]

Isn't a large portion of the code to get friendlier messages for the user?

	▲	joz1-k a year ago \| parent [-]
		Yes, that explains a lot of the complexity. Another reason is type checking/inferring and making the AST detailed enough for code analysis tools, such as code hinting in IDEs.

▲

antononcube a year ago | parent | prev | next [-]

It seems you are describing how functional parsers (aka parser combinators) work.

(BTW, there is a "Parser combinators" section in the featured post/article.)

	▲	ckok a year ago \| parent \| next [-]
		I believe the proper term for what i am describing is a recursive descent parser. With which it is also quite doable to generate proper error handling and even recovery. Some form of this is used in almost every production language I think. It has been years since I've written a proper parser but before that every time I had to write one I tried the latest and greatest first. ANTLR, coco/r, combinators. All the generated ones seemed to have a fatal flaw that hand writing didnt have. For example good error handling seemed almost impossible, very slow due to Infinite look ahead or they were almost impossible to debug to find an error in the input schema. In the end hand crafting seems to be faster and simpler. Ymmv. My point about the article was mostly that all the formal theory is nice but all it does is scare away people, while parsing is probably the simplest thing about writing a compiler.
	▲	marcosdumay a year ago \| parent \| prev [-]
		The bad news about those is that it's easy to mindlessly create a parser that runs on exponential time. The good news is that this happens in the grammar definition. So once you define your language well, you don't have to watch for it anymore.

▲

DemocracyFTW2 a year ago | parent | prev | next [-]

IMHO it gets even better when you can use regular expressions and write a 'modal' parser where each mode is responsible for a certain sub-grammar, like string literals. JavaScript added the sticky flag (y) to make this even simpler.

	▲	rurban a year ago \| parent [-]
		It gets much worse. It's a huge anti-pattern to use regex within parsers.

▲

a year ago | parent | prev [-]

[deleted]