Related articles |
---|
And yet another compiler compiler ( Newbie alert )... markagr@aol.com (1997-01-12) |
Re: And yet another compiler compiler ( Newbie alert )... d.sand@ix.netcom.com (Duane Sand) (1997-01-14) |
From: | markagr@aol.com |
Newsgroups: | comp.compilers |
Date: | 12 Jan 1997 11:27:36 -0500 |
Organization: | AOL, http://www.aol.co.uk |
Keywords: | question, parse, C, comment |
I have recently written a syntax analyser for yet another strain of
EBNF, the product from which is a recursive descent syntax recogniser
in C. I call it SYN.
i.e input a type of EBNF .... output C
Why? Because it gives me something to do for my SYNs ( uhh! Just take
it as read that's what I've done. )
Obviously it has a number of flaws ... like it produces recursive
descent, so the grammar must be factored to the LEFT and recurse to
the RIGHT. The lexical analyser has only a one lexeme "pushback"
buffer. It has no concept of the Eta transition ( empty clause ).
These facts alone make it impossible to parse ...
prod ::== ( prod "a" | empty ) ; 0 or more "a"s
however I get around that with ...
prod := { "a" }* ; 0 or more "a"s
One of the options when creating the C recogniser is to count lexeme
absorbtion, and therefore recognise when non-absorbing recursion has
taken place.
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? or in GDMO/asn.1 x208 the defintions
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.
[A lot of the time it's easier to build the parse tree first, then go back
and decide what it meant. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.