|VB/VBA: Creating list of variables and parsing statements firstname.lastname@example.org (Howard Kaikow) (2000-11-26)|
|Re: VB/VBA: Creating list of variables and parsing statements email@example.com (2000-11-30)|
|Re: VB/VBA: Creating list of variables and parsing statements firstname.lastname@example.org (Scott Nicol) (2000-12-01)|
|Re: VB/VBA: Creating list of variables and parsing statements email@example.com (2000-12-03)|
|Date:||30 Nov 2000 12:07:01 -0500|
|Organization:||AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com|
|Posted-Date:||30 Nov 2000 12:07:01 EST|
"Howard Kaikow" <firstname.lastname@example.org> 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
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,
You can send me an e-mail, if you have more questions.
Return to the
Search the comp.compilers archives again.