REVMEDIA FKB Articles - AREV, OI, REV G, jREV, JCDC, LIVEWATER,ADVANCED REVELATION, OPENINSIGHT, REVELATION G

RevMedia FKB

Document	V4I9A4
Title	Symbol Table Structure
Keywords	SYMBOL TABLE VARIABLE
Text	At Eastside Management SYSTEMS recently Mike Taylor bemoaned the lack of any tools for enquiring about variable usage within an AREV program In an effort to explore more about this subject we investigated the subject and the information presented below is the fruit of that research Whenever an R/Basic program is compiled without the (C (Cutoff Symbol Table)) option a record having the same name but preceded by an asterix is placed in the Source file This is a record of the NAMES of all the VARIABLES used/declared in the program It is worth remembering that R/Basic does not actually see VARIABLES by name rather it sees them by position the first common variable the second common variable etc So this table is used by the debugger when displaying variable contents by name The user types \WC_Is% and the debugger locates WC_Is% in the symbol table establishes that the user means the 74th common variable and displays this (This explains why a previous REVMEDIA tip about USING SY to load a Window_Common% symbol table (to examine Window_Common when WINDOW falls over with VNAV) works) The Symbol table is Carriage Return/Line Feed delimited and has the following structure (Using the familiar < > nomenclature to indicate CrLfs not @Fms) < 1 > Name of the record which was compiled to create this symbol table Note that this does not reflect the subroutine/function name (which does not have to be the same as the record i e the subroutine ProcessInvoice could have a Subroutine header on line 1 of "Subroutine Wombat" and the symbol table would still contain ProcessInvoice) Nor does it reflect the Catalog pointer name (which does not have to be the same as the record i e the subroutine ProcessInvoice could have a Catalog pointer called PI in VOC The Symbol table would still contain ProcessInvoice Note though that when the system enters the debugger the name of the Catalog pointer is displayed not the name of the original source record < 2 > et seq One entry per variable Each entry is in three parts comma separated where (again USING < > to indicate commas) < 1 > Is the variable name < 2 > Is the variable type WITH four values having been identified thus far these being 1 local variable 1 common variable 2 LABELLED common variable 3 name of the LABELLED common block < 3 > Is the sequential position of this variable within the variable type or in the case of type 2 VARIABLES (labelled common) within that LABELLED common block Thus a code segment as follows Subroutine InvoiceProcess(InvId Options) Common Main1% Main2% Common /Params/ Var1@ Var2@ Var3@ Common /Scratch/ S1@ S2@ S3@ Common Additional1% Additional2% SaveId = InvId NewVar = "" Return would produce a symbol table as follows or where the Char(13) : Char(10) have not been shown but where each LINE is shown separately TEST Note the record compiled was called TEST so the subroutine name was not used INVID 1 1 1 local VARIABLES Note that as VARIABLES are entered into the symbol table as they are encountered the first local variable entries for a subroutine will be the VARIABLES that are passed to that subroutine OPTIONS 1 2 MAIN1% 1 1 1 common VARIABLES Note that "like" VARIABLES are not "grouped" so there will be more common variables later in the table MAIN2% 1 2 PARAMS 3 1 The first LABELLED common name VAR1@ 2 1 The first LABELLED common variable within the preceding LABELLED common name VAR2@ 2 2 VAR3@ 2 3 SCRATCH 3 2 The second LABELLED common name S1@ 2 1 The first LABELLED common variable within the preceding LABELLED common name S2@ 2 2 S3@ 2 3 ADDITIONAL1% 1 3 The NEXT set of common VARIABLES Note the sequential FROM the last set of common VARIABLES declared earlier in the program ADDITIONAL2% 1 4 SAVEID 1 3 And finally back to the local VARIABLES NEWVAR 1 4 (Volume 4 Issue 9 Pages 12 13)

[revmedia/copyrigh.htm]

Page last modified: 31/01/03