Related articles |
---|
Q: Parsing operands & operators rwaldrop@clark.net (Randy Waldrop) (1998-09-05) |
From: | Randy Waldrop <rwaldrop@clark.net> |
Newsgroups: | comp.compilers |
Date: | 5 Sep 1998 01:27:01 -0400 |
Organization: | Verio Mid-Atlantic |
Keywords: | parse, SQL, question |
Here is a question for you compiler gurus.
I am writing, in java, a parser for SQL92-like conditional
statements. However, I am having trouble getting the tokens
parsed and ordered correctly.
Method:
1. Parse the statement into operands & operators. Parentheses
are handled as operators.
2. Process the tokens, putting them into Reverse Polish Notation
sequence and eliminating the parentheses. Paren levels,
operator precedence and associativity levels are honored.
The trouble I'm having is with unary operators, like 'NOT'.
They are binding to the wrong operand. For example:
input: (a NOT = b)
my rpn: a NOT b = (this is wrong)
rpn should be: a b = NOT (this is right)
The question: What is the logical rule which should cause the
'NOT' to apply to the result of the following operator (not
to the preceeding operand)?
I have a guess - that unary operators should be designated as
'prefix' or 'postfix', and 'NOT' should be 'prefix'. Does
this make sense?
TIA, Randy
[In the parser, I'd treat NOT = as an operator, since there aren't that many
relationals you'd have to special case, or else make it a meta-operator
that puts a flag bit on the operator it affects to tell the output
routine to emit a NOT after it emits the operator. Yes, this is a hack.
Welcome to the wonderful world of compilers. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.