Related articles |
---|
BNF for a BASIC compiler mness1978@hotmail.com (Michael Ness) (2002-09-29) |
Re: BNF for a BASIC compiler snicol@apk.net (Scott Nicol) (2002-10-13) |
Re: BNF for a BASIC compiler michael@moria.de (Michael Haardt) (2002-10-13) |
Re: BNF for a BASIC compiler the-xogos@ifrance.com (antoine) (2002-10-13) |
From: | "Scott Nicol" <snicol@apk.net> |
Newsgroups: | comp.compilers |
Date: | 13 Oct 2002 15:53:30 -0400 |
Organization: | APK Net |
References: | 02-09-171 |
Keywords: | Basic |
Posted-Date: | 13 Oct 2002 15:53:30 EDT |
"Michael Ness" <mness1978@hotmail.com> 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.
--
Scott Nicol
snicol@apk.net
Return to the
comp.compilers page.
Search the
comp.compilers archives again.