Re: VB/VBA: Creating list of variables and parsing statements

Scott Nicol <snicol@apk.net>
1 Dec 2000 13:17:59 -0500

          From comp.compilers

Related articles
VB/VBA: Creating list of variables and parsing statements kaikow@standards.com (Howard Kaikow) (2000-11-26)
Re: VB/VBA: Creating list of variables and parsing statements vbdis@aol.com (2000-11-30)
Re: VB/VBA: Creating list of variables and parsing statements snicol@apk.net (Scott Nicol) (2000-12-01)
Re: VB/VBA: Creating list of variables and parsing statements vbdis@aol.com (2000-12-03)
| List of all articles for this month |

From: Scott Nicol <snicol@apk.net>
Newsgroups: comp.compilers
Date: 1 Dec 2000 13:17:59 -0500
Organization: APK Net
References: 00-11-160 00-11-169
Keywords: Basic, parse
Posted-Date: 01 Dec 2000 13:17:59 EST

VBDis wrote:


> Finding and parsing declarations of variables is not very
> complicated.


I agree with you on this point, at least for global- and module-level
declarations.


> If you want to parse statements, I
> suggest that you start with an existing parser or syntax for any (not
> too sophisticated) language, and add the VB/VBA extensions
> yourself.


Yikes!


VB is a very difficult language to parse correctly. It's not as bad
as Fortran, but it makes a valiant attempt. There are silly things
like:


- 3(!) pass compilation: global/module variables and
      procedures, procedure variables, statements.
      Variables declared anywhere with a procedure are
      accessible anywhere within a procure, so you have to
      parse all variables first (or patch up later, but
      this can make things more difficult).


- reserved words that are reserved only in certain
      contexts (i.e. "access", "append" and "binary"
      are reserved words in an Open statement, but are
      identifiers in most other contexts).


- scoping rules that are _very_ complicated. It
      took me a few months to get these correct.


- parenthesis are significant, and not just for
      evaluation order. Parenthesis also remove
      reference, so you can force pass-by-value when
      a procedure wants pass-by-reference.


- lots of places where more-than-one lookahead is
      needed. End vs. End If, End While, etc are
      fairly easy to fix in the scanner, but the
      "." notation when mixed with arrays is a bit more
      difficult. For instance, save your work (in all
      applications if you are using Win95/98/me), then
      enter the following into VB's editor:


redim x(1 to 5).y(2)


      When you press enter, VB will crash, because MS
      didn't handle the (complicated) parsing of arrays
      within types in redim statements correctly. Yes,
      I realize the line is a syntax error.


In general, to do it right, you are going to have lots of interaction
between the parser and the scanner. This makes using Lex/YACC tricky.


To top it off, there is no language spec. The official "Language
Reference" is a start, but it is incomplete, inaccurate, and poorly
organized.
--
Scott Nicol
snicol@apk.net


Post a followup to this message

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