Operator-precedence parser: Difference between revisions

Revision as of 09:01, 11 March 2019

Revision as of 18:40, 24 October 2019

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.)

[[PerlRaku 6(programming language)|Raku]] sandwiches an operator-precedence parser between two [[Recursiverecursive descent parser]]s in order to achieve a balance of speed and dynamism. This is expressed in the virtual machine for Perl 6Raku, [[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 | accessdate=2017-10-25}}</ref>

== Precedence climbing method ==