Operator-precedence parser: Difference between revisions

Revision as of 22:09, 5 April 2021

Revision as of 12:20, 4 May 2021

Line 9:

Operator-precedence parsers are not used often in practice; however they do have some properties that make them useful within a larger design. First, they are simple enough to write by hand, which is not generally the case with more sophisticated right shift-reduce parsers. Second, they can be written to consult an operator table at [[Run time (program lifecycle phase)|run time]], which makes them suitable for languages that can add to or change their operators while parsing. (An example is [[Haskell (programming language)|Haskell]], which allows user-defined infix operators with custom associativity and precedence; consequentially, an operator-precedence parser must be run on the program ''after'' parsing of all referenced modules.)

[[Raku (programming language)|Raku]] sandwiches an operator-precedence parser between two [[recursive descent parser]]s in order to achieve a balance of speed and dynamism. This is expressed in the virtual machine for Raku, [[Parrot virtual machine|Parrot]], as the [[Parser Grammar Engine]] (PGE). [[GNU Compiler Collection|GCC]]'s C and C++ parsers, which are hand-coded recursive descent parsers, are both sped up by an operator-precedence parser that can quickly examine arithmetic expressions. Operator precedence parsers are also embedded within [[compiler compiler]]-generated parsers to noticeably speed up the recursive descent approach to expression parsing.<ref name="Harwell2008">{{cite web| last=Harwell | first=Sam | date=2008-08-29 | title=Operator precedence parser | url=https://theantlrguy.atlassian.net/wiki/spaces/ANTLR3/pages/2687077/Operator+precedence+parser | publisher=ANTLR3 Wiki | access-date=2017-10-25}}</ref>

== Precedence climbing method ==