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

vbdis@aol.com (VBDis)
30 Nov 2000 12:07:01 -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: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 30 Nov 2000 12:07:01 -0500
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 00-11-160
Keywords: Basic, parse
Posted-Date: 30 Nov 2000 12:07:01 EST

"Howard Kaikow" <kaikow@standards.com> schreibt:


I have written parsers for VB, and remember some problems.


>1. Create a list of all variables in a module, perhaps identifying the type.
>2. Create a list of all variables, identifying the type of each, in a
>project.


The missing grammar is not the problem, though almost all versions of
VB/VBA have their slightly different grammar. More problems arise with
such a parser, even if an existing grammar is used.


Finding and parsing declarations of variables is not very
complicated. You only should handle global and local variables
separately, and either ignore local variables, or keep these in
separate lists (scopes). Simple data types can be indicated also by
the type characters ("%" etc.). If no explicit type is given in a
declaration, then the DefInt etc. statements must be used, in order to
determine the type of the variable. If none applies, the default type
always is Variant.


Type declarations can be somewhat recursive, since a User Defined Type
(UDT) can contain members of other Types, which are declared in other
modules. That's no special restriction, but the size of an UDT can be
determined only after all UDTs in the project have been
parsed. Therefore I suggest to always parse whole projects for type
declarations. You also should distinguish between global and
module-relative declarations, since types of the same name can be
declared differently in multiple modules.


>3. Parse each statement into its components.


My parsers only had to extract all declarations (of variables,
subroutines...), and only looked at the first token on every line, to
determine how to handle the line. 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. It's a good idea to remember the VB version in a global
variable, so that the parser can use the version specific syntax,
where required.


You can send me an e-mail, if you have more questions.


DoDi


Post a followup to this message

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