Related articles |
---|
dynamic yacc-tables? canver@cyborg.informatik.uni-ulm.de (1991-08-12) |
Re: dynamic yacc-tables? pardo@gar.cs.washington.edu (1991-08-13) |
Re: dynamic yacc-tables? rekers@cwi.nl (1991-08-13) |
Re: dynamic yacc-tables? joshua@veritas.com (1991-08-13) |
Re: dynamic yacc-tables? salomon@ccu.umanitoba.ca (1991-08-13) |
Re: dynamic yacc-tables? kjell@cs.ucsc.edu (Kjell Post) (1991-08-14) |
Re: dynamic yacc-tables? markh@csd4.csd.uwm.edu (1991-08-16) |
Newsgroups: | comp.lang.c,comp.compilers |
From: | markh@csd4.csd.uwm.edu (Mark William Hopkins) |
Keywords: | parse, yacc |
Organization: | University of Wisconsin - Milwaukee |
References: | 91-08-043 |
Date: | 16 Aug 91 06:23:18 GMT |
In article 91-08-043 canver@cyborg.informatik.uni-ulm.de (Ercument Canver) writes:
>I got the following problem: I need to extend the parse tables generated
>by yacc dynamically during parsing a text...
>
>Background: I'm posting this request because I have to write a parser
>suitable for declaring mixfix operators and overloading.
Your real problem is not a need for a dynamic parser: your syntax remains the
same throughout the parse, it's the conflict resolution (precedences) and
symbol table interpretation that differ.
You'd like to write an expression syntax as simple as this:
%token unary_operator binary_operator
...
expression:
expression binary_operator expression |
unary_operator expression |
...
and use symbol table lookup's to distinguish what symbol/identifier is what
kind of operator during the parse. The scanner does all the work.
The real problem is that you'd also like to wrest direct control of YACC's
precedence declarations, so that you can alter them at run-time, and determine
them on the fly *from the lexical scanner* during the above-mentioned symbol
table lookup.
I don't know if YACC allows you to declare precedences dynamically. There may
be a some easy way of hacking the YACC source to get that feature.
All the above is standard fare for Prolog, whose expression syntax is
completely dynamic in just the way you describe above.
Avoiding YACC in the first place (which is regressive technology anyhow), you
could probably have an easier time doing the parser by hand, especially
considering you now have direct control over the operator precedence conflict
resolution.
Another way to resolve the problem (if the expression sub-syntax is
self-contained), is to declare an expression to YACC as a LEXICAL item, and
write up your own predecence parser, putting it in with rest of the lexical
scanner. Then you can exercise direct run-time control over precedence
conflicts and operator "fixity"-s.
[If you only want to change precedences and you have a moderate number of
possible precedences, it's not very hard in yacc. You declare a lexical token
per precedence, and write the grammar using those tokens as the operators.
The lexer passes the actual operator name as the semantic value that goes with
the token, so the lexer in effect assigns the precedence of each operator,
most likely by looking it up in a runtime table. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.