Re: And yet another compiler compiler ( Newbie alert )...

markagr@aol.com wrote:
>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
distinctions.


>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 comp.compilers page.
Search the comp.compilers archives again.