Related articles |
---|
RFC - VBS Grammar larlew@home.com (Larry Lewis) (2000-12-23) |
Re: RFC - VBS Grammar joachim_d@gmx.de (Joachim Durchholz) (2000-12-31) |
Re: RFC - VBS Grammar snicol@apk.net (Scott Nicol) (2000-12-31) |
Re: RFC - VBS Grammar snicol@apk.net (Scott Nicol) (2001-01-04) |
Re: RFC - VBS Grammar Arargh@Enteract.com (Arargh!) (2001-01-04) |
From: | "Scott Nicol" <snicol@apk.net> |
Newsgroups: | comp.compilers |
Date: | 31 Dec 2000 03:04:55 -0500 |
Organization: | APK Net |
References: | 00-12-104 |
Keywords: | Basic, parse |
Posted-Date: | 31 Dec 2000 03:04:55 EST |
"Larry Lewis" <larlew@home.com> wrote in message
> I have attached a simple grammar(lex/yacc) for VB script. There are
> still a few things missing but I am wondering if I'm on the right
> track here.
I see a few obvious problems.
Assignment is a statement, not an expression. You can't make it an
expression, because equality uses a single "=", just like assignment.
Don't let Microsoft's documentation fool you, assignment is definitely
not an operator, at least not in the traditional sense used in
computer science. For example, in VBS, a = b = 0 sets a to either 0
(if b isn't 0) or -1 (if b is 0), because the first "=" is an
assignment, and the second is a comparison.
Subroutine/function and variable/array identifiers are fundamentally
different, but there are many places where the syntax overlaps,
especially with regards to parenthesis. Parens are used in
expressions (to force order of operation), subroutine and function
calls, and array accesses. This overloading causes conflicts in the
grammar. For example:
x = y(3)
z(1)
In the first line, y(3) could be an array access or a function call.
In the second line, z(1) could be an array access, a function call, or
a subroutine call (the parens in this case being part of the
expression "(1)"). The easiest fix is to assign a different token for
each class of identifier
--
Scott Nicol
snicol@apk.net
Return to the
comp.compilers page.
Search the
comp.compilers archives again.