|Q: Operator Precedence Parser firstname.lastname@example.org (Sander Hahn) (1998-03-07)|
|Re: Q: Operator Precedence Parser email@example.com (1998-03-12)|
|Re: Q: Operator Precedence Parser firstname.lastname@example.org (1998-03-12)|
|Re: Q: Operator Precedence Parser email@example.com (1998-03-12)|
|Re: Q: Operator Precedence Parser firstname.lastname@example.org (1998-03-15)|
|Re: Q: Operator Precedence Parser email@example.com (1998-03-15)|
|From:||firstname.lastname@example.org (Joseph H Allen)|
|Date:||15 Mar 1998 00:22:36 -0500|
|Organization:||The World Public Access UNIX, Brookline, MA|
>Sander Hahn (email@example.com) wrote:
>: i want to learn more about operator precedence parsers. The operators
>: should be dynamically overloadable, like in Prolog. Where can i find
>: more information about this subject? (preferably online)
User fs29 <firstname.lastname@example.org> wrote:
>When implementing my T2 compiler, I was looking for a way to speed up
>expression parsing (it used recursive procedure calls at that time).
>Finally, I have managed to do almost the entire expression parsing
>in a single procedure driven by a table containing integers to
>represent the operator precedences. Because of the table-driven
>approach, it should be easy to add, remove, and modify operators.
I've used a similar approach in Ivy
(ftp://ftp.worcester.com/pub/joe/ivy.tar.Z). The table indicates
associativity as well as precidence. Also I use two hash tables
initialized from this table to scan the operators. One hash table
contains an entry for each full operator, and the other only indicates
whether there are operators which match the current scanned
For example, if the operator is '>>=', there will be a hash entry for
>>= and left sub-string entries for '>' and '>>'. So to scan for an
operator, you read input for as long as you have a match in the left
sub-string table and note any matches in the full-string hash table.
You return the longest matching operator and unget any unmatching
readahead (which is just a pointer change in Ivy's scanner).
You could make a language with user defined operators with this
approach... I'm don't actually allow that in Ivy and I'm not going to
allow it in the language I'm currently working on- I'm trying to make
an N-pass header-file-less language, so parsing is not allowed to
depend on declarations (like C's typedefs).
/* email@example.com (220.127.116.11) */ /* Joseph H. Allen */
Return to the
Search the comp.compilers archives again.