Hacker News new | past | comments | ask | show | jobs | submit login

I don't recognise the architecture despite it saying x86, but it reminds me of ARM.

Recursive descent seems to be the go-to parsing technique for compilers both big and small now. I like how all the repetitive functions for each level have been refactored into a "general_recursion" function, but if you want to make it even simpler and yet more extendable, table-driven precedence climbing would be ideal:

http://www.engr.mun.ca/~theo/Misc/exp_parsing.htm#climbing




> Recursive descent seems to be the go-to parsing technique for compilers both big and small now ... if you want to make it even simpler and yet more extendable, table-driven precedence climbing would be ideal

I think the fact that everyone just writes recursive descent parers tells us in practice that there isn't sufficient value in using more techniques like table-driven variants and they don't make anything practically simpler.


I agree about table-driven LR and the like (LALR, LLR, SLR, etc) which were the "traditional YACC" generated parsers, but precedence climbing is just a simple refactoring of recursive descent that eliminates needing multiple almost-the-same functions for each precedence level. This is most applicable to languages like C which have many levels, which could be why it isn't so common for others.


That depends on what you are parsing. For in-fix expressions shunting yard algorithm is significantly more clear (ie. you don't have to resort to left-right recursion tricks and invent labels like "product") and allows you to extend the set of supported operators by simply adding table entry (which you can do even while parsing and thus support user-defined operators)


> For in-fix expressions shunting yard algorithm is significantly more clear

If it was significantly more clear, people would use it in practice! This makes me think it is not in fact significantly more clear.

I did research work in parsers, and I work professionally in compilers now, and guess what when I need a parser for in-fix expressions I just write a recursive descent one manually, it's never an issue.


It is significantly more clear if you only parse infix expressions which is why it is used for many introductory "lets write a calculator" examples.

In context of more complex language with small set of infix operators and their precedence classes it is probably not worthwhile unless you really want user-defined operators.


My very fuzzy recollection is there's long-ago work compiling user-defined mixfix operator precedence parsing down to recursive descent, but yes, opp implementation is pretty for large complex user-defined operator sets.


That is because it is compiling for x86. It is the Knight Architecture, designed for TTL implementation




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: