Re: BNF for a BASIC compiler

"Scott Nicol" <snicol@apk.net>
13 Oct 2002 15:53:30 -0400

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.