|And yet another compiler compiler ( Newbie alert )... firstname.lastname@example.org (1997-01-12)|
|Re: And yet another compiler compiler ( Newbie alert )... email@example.com (Duane Sand) (1997-01-14)|
|From:||Duane Sand <firstname.lastname@example.org>|
|Date:||14 Jan 1997 20:09:54 -0500|
|Keywords:||practice, C, comment|
>The problems I have are ...
> In complex expressions where the recursion is not obvious
>.... eg. Have you seen C's expression evaluation syntax? ... especially
>"assignops" How can you determine whether an expression is an lvalue
>or a rvalue one lexeme at a time?
In general, you can't, except by a bottom-up analysis using the symbol
table. A simple id could be a named constant, or a register var, or a
read-only var, or an addressible, modifiable var, or a function name.
When a semantic check is needed anyway for some cases, it's best to
put all cases into the semantic check and not into the BNF syntactic
>or in GDMO/asn.1 x208 the definitions
>of "value" and "type" are so inextricably recursive that left
>factoring and making it right recursive is a nightmare. How do I go
>about creating a "turn the handle and out it comes" solution to this
>.... preferably using SYN.
Figure out how you'd do it with hand-written top-down parsing rules,
and then translate that hack back into your preferred BNF notation.
If it can't be coded by hand, it can't be done by your notation either.
>[A lot of the time it's easier to build the parse tree first, then go back
>and decide what it meant. -John]
I.e. have the grammar describe a looser, more general language that
syntactically allows any random mixture of values & types anywhere.
Then handle the wanted semantic distinctions by semantic checks,
not grammar rules.
[This has the added advantage that you can give useful error messages like
"cannot assign to expression" rather than just "syntax error" -John]
Return to the
Search the comp.compilers archives again.