|BNF for a BASIC compiler email@example.com (Michael Ness) (2002-09-29)|
|Re: BNF for a BASIC compiler firstname.lastname@example.org (Scott Nicol) (2002-10-13)|
|Re: BNF for a BASIC compiler email@example.com (Michael Haardt) (2002-10-13)|
|Re: BNF for a BASIC compiler firstname.lastname@example.org (antoine) (2002-10-13)|
|From:||"Scott Nicol" <email@example.com>|
|Date:||13 Oct 2002 15:53:30 -0400|
|Posted-Date:||13 Oct 2002 15:53:30 EDT|
"Michael Ness" <firstname.lastname@example.org> wrote in message
> Here is my first attempt at a defining a grammer using BNF. Is this the
> way BNF should look? Can anyone point out any mistakes I'm making? One
> thing that I am concerned about is the two token statment "END IF". Is
> this legal in a LALR(1) parser? What about the <identifier> =
> <expression> assignment with a single "="? Is it possible to not
> confuse this with the <expression> = <expression> boolean test?
The BNF looks good. The "END IF" isn't going to work, but only
because END is a legal statement, so when you see END you don't know
if it is the "END" statement or the first half of END IF. The
simplest fix is to mess with the lexical analyzer to figure out if it
is "END" or "END IF" so you can handle ENDIF as a single token.
The '=' won't cause confusion because there is a clear separation
between expressions and statements - an expression, by itself, is not
a statement in Basic. Of course, the following would trip up many
programmers (including me) accustomed to languages that allow
expressions to be statements:
A = B = 5
In Basic, the value of B is unchanged, A is either true or false.
Return to the
Search the comp.compilers archives again.