Abstract:
A dynamically extensible approach to parsing textual input consisting of a predictive parser and associated predictive parser generator is provided. The combination, together with a plug-in/resolver architecture, provides the ability to handle a set of languages that is vastly larger that that conventionally handled by predictive parsing techniques. The generator accepts extended BNF language specifications containing embedded reverse polish plug-in call specifications giving the plug-in number to be called as well as an arbitrary textual parameter to be passed to the plug-in. The parser supports the ability to register a ‘resolver’ function as well as one or more custom reverse-polish plug-in handlers which are passed the textual parameter(s) specified in the extended BNF as well as having full control over the parsing and evaluation stacks. The ‘resolver’ is with a ‘no action’ parameter when the parser first encounters a token in the input stream and may modify the token as necessary. The resolver is also called when the parser must evaluate or assign an entry on the evaluation stack at which time it can implement additional behaviors depending on the language or environment. Finally the ‘resolver’ is called when the parse terminates. The ‘resolver’ is the primary mechanism whereby more complex languages can be handled and is also a key part of connecting to external systems or storage when the parser is used in an interpreted context. The reverse polish plug-in functions are provided with an API to allow full control over and access to the parser stacks and can rapidly be configured to implement almost any language constructs.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    The analysis and parsing of textual information is a well-developed field of study, falling primarily within what is commonly referred to as ‘compiler theory’. At its most basic, a compiler requires three components, a lexical analyzer which breaks the text stream up into known tokens, a parser which interprets streams of tokens according to a language definition specified via a meta-language such as Backus-Naur Form (BNF), and a code generator/interpreter. The creation of compilers is conventionally a lengthy and off-line process, although certain industry standard tools exist to facilitate this process such as LEX and YACC from the Unix world. There are a large number of textbooks available on the theory of predictive parsers and any person skilled in this art would have basic familiarity with this body of theory.  
           [0002]    Parsers come in two basic forms, “top-down” and “bottom-up”. Top-down parsers build the parse tree from the top (root) to the bottom (leaves), bottom-up parsers build the tree from the leaves to the root. For our purposes, we will consider only the top-down parsing strategy known as a predictive parser since this most easily lends itself to a table driven (rather than code driven) approach and is thus the natural choice for any attempt to create a configurable and adaptive parser. In general, predictive parsers can handle a set of possible grammars referred to as LL(1) which is a subset of those potentially handled by LR parsers (LL(1) stands for ‘Left-to-right, using Leftmost derivations, using at most 1 token look-ahead’). Another reason that a top-down algorithm is preferred is the ease of specifying these parsers directly in BNF form, which makes them easy to understand by most programmers. Compiler generators such as LEX and YACC generally use a far more complex specification methods including generation of C code which must then be compiled, and thus is not adaptive or dynamic. For this reason, bottom-up table driven techniques such as LR parsing (as used by YACC) are not considered suitable.  
           [0003]    What is needed is a process that can rapidly (i.e., within seconds) generate a complete compiler from scratch and then apply that compiler in an adaptive manner to new input, the ultimate goal being the creation of an adaptive compiler, i.e., one that can alter itself in response to new input patterns in order to ‘learn’ to parse new patterns appearing in the input and to perform useful work as a result without the need to add any new compiled code. This adaptive behavior is further described Appendix 1 with respect to a lexical analyzer (referred to in the claims as the “claimed lexical analyzer”). The present invention provides a method for achieving the same rapid, flexible, and extensible generation in the corresponding parser.  
         SUMMARY OF INVENTION  
         [0004]    The present invention dislcoses a parser that is totally customizable via the BNF language specifications as well as registered functions as described below. The are two principal routines: (a) PS_MakeDB( ), which is a predictive parser generator algorithm, and (b) PS_Parse( ), which is a generic predictive parser that operates on the tables produced by PS_MakeDB( ). The parser generator PS_MakeDB( ) operates on a description of language grammar, and constructs predictive parser tables that are passed to PS_Parse( ) in order to parse the grammar correctly. There are many algorithms that may be used by PS MakeDB( ) to generate the predictive parser tables, as described in many books on compiler theory. It consists essentially of computing the FIRST and FOLLOW sets of all grammar symbols (defined below) and then using these to create a predictive parser table. In order to perform useful action in response to inputs, this invention extends the BNF language to allow the specification of reverse-polish plug-in operation specifiers by enclosing such extended symbols between ‘&lt;’and ‘&gt;’ delimiters. A registration API is provided that allows arbitrary plug-in functions to be registered with the parser and subsequently invoked as appropriate in response to a reverse-polish operator appearing on the top of the parser stack. The basic components of a complete parser/interpreter in this methodology are as follows:  
           [0005]    The routine PS_Parse( ) itself (described below)  
           [0006]    The language BNF and LEX specifications.  
           [0007]    A plug-in ‘resolver  400 ’ function, called by PS_Parse( ) to resolve new input (described below)  
           [0008]    One or more numbered plug-in functions used to interpret the embedded reverse-polish operators.  
           [0009]    The ‘langLex’ parameter to PS_Parse( ) allows you to pass in the lexical analyzer database (created using LX_MakeDB( )) to be used to recognize the target language. There are a number of restrictions on the token numbers that can be returned by this lexical analyzer when used in conjunction with the parser. These are as follows:  
           [0010]    1) The parser generator has it&#39;s own internal lexical analyzer which reserves token numbers 59 . . . 63 for recognizing certain BNF symbols (described below) therefore these token numbers cannot be used by the target language recognizer. Token numbers from 1 . . . 63 are reserved by the lexical analyzer to represent ‘accepting’ states in the ‘catRange’ token recognizer table, these token numbers are therefore not normally used by a lexical analyzer ‘oneCat’ token recognizer. What this means then is that instead of having capacity for 63 variable content tokens (e.g., names, numbers, symbols etc) in your target language, you are restricted to a maximum of 58 when using the parser.  
           [0011]    2) If there are multiple names for a give symbol, then the multiplicity should be restricted to the lexical analyzer description, only one of the alternatives should be used in the parser tables.  
           [0012]    3) In order to construct predictive parser tables, it is necessary to build up a 2 dimensional array where one axis is the target language token number and the other axis is the non-terminal symbols of the BNF grammar. The parser-generator is limited to grammars having no more than 256 non-terminal grammar symbols, however in order to avoid requiring MASSIVE amounts of memory and time to compute the parsing table, the number of terminal symbols (i.e., those recognized by the lexical analyzer passed in ‘langLex’) should be limited to 256 also. This means that the lexical analyzer should never return any token number that is greater than ‘kMaxTerminalSym’. For example, token numbers 1 . . . 59 are available for use as accepting states for the ‘catRange’ recognizer while tokens 64 . . . 255 are available for use with the ‘oneCat’ recognizer.  
           [0013]    The invention also provides a solution for applications in which a language has token numbers that use the full 32-bits provided by LEX. Immediately after calling the ‘langLex’ lexical analyzer to fetch the next token in the input stream, PS_Parse( ) calls the registered ‘resolver  400 ’ function with a ‘no action’ parameter, (normally no action is exactly what is required) but this also provides an opportunity to the plug-in code to alter the token number (and token size etc.) to a value that is within the permitted range.  
           [0014]    There are also many other aspects of the invention that allow the parser to accept or process languages that are considerably more complex than LL(1). For example, suppose a recognizer is programmed to recognize the names of people (for which there are far more than 256 possibilities) so when a ‘no-action’ call is initiated, the function PS_SetCurrToken( ) could be used to alter the token number to 58 say. Then in your BNF grammar, you specify a token number of 58 (e.g., &lt;58:Person Name&gt;) wherever you expect to process a name. The token string will be available to the plug-in and resolver  400  functions on subsequent calls and could easily reconstitute the original token number and the plug-in code could be programmed to call ‘langLex’ using PS_LangLex( ). Other applications and improvements are also disclosed and claimed in this application as described in further detail below.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0015]    [0015]FIG. 1 provides a sample BNF specification;  
         [0016]    [0016]FIG. 2 is a block diagram illustrating a set of operations as performed by the parser of the present invention;  
         [0017]    [0017]FIG. 3 provides a sample code fragment for a predefined plug-in that can work in conjunction with the parser of the present invention; and  
         [0018]    [0018]FIG. 4 provides sample code for a resolver of the present invention. 
     
    
       [0019]    Appendix A provides code for a sample Application Programming Interface (API) for the parser of the present invention.  
       DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0020]    As described above, the parser of this invention utilizes the lexical analyzer described in Appendix 1, and the reader may refer to this incorporated patent application for a more detailed explanation of some of the terms used herein. For illustration purposes, many of the processes described in this application are accompnaied by samples of the computer code that could be used to perform such functions. It would be clear to one skilled in the art that these code samples are for illustration purposes only and should not be interepreted as a limitation on the claimed inventions.  
         [0021]    The present invention dislcoses a parser that is totally customizable via the BNF language specifications as well as registered functions as described below. The are two principal routines: (a) PS_MakeDB( ), which is a predictive parser generator algorithm, and (b) PS Parse( ), which is a generic predictive parser that operates on the tables produced by PS_MakeDB( ). The parser generator PS_MakeDB( ) operates on a description of language grammar, and constructs predictive parser tables that are passed to PS_Parse( ) in order to parse the grammar correctly. PS_MakeDB( ) has the following function prototype:  
                                                                                                                                   ET_ParseHdl PS_MakeDB   (   // Make a predictive parser for       PS_Parse( )                charPtr   bnf,   // I:C string specifying grammar&#39;s BNF                ET_LexHdl   langLex,   // I:Target language lex (from            LX_MakeDB)                int32   options,   // I:Various configuration options                int32   parseStackSize,// I:Max. depth of parser stack, 0=default           int32   evalStackSize  // I:Max. depth of evaluation stack, 0=default                )   // R:handle to created DB,                      
 
         [0022]    The ‘bnf’ parameter to PS_MakeDB( ) contains a series of lines that specify the BNF for the grammar in the form:  
                                                       non_terminal   ::= production_1 &lt;or&gt; production_2 &lt;or&gt; . . .                      
 
         [0023]    Where production — 1 and production — 2 consist of any sequence of Terminal (described in lexical analyzer passed in to PS_MakeDB), or Non-Terminal (langLex) symbols provided that such symbols are greater than or equal to 64. Productions may continue onto the next line if required but any time a non-blank character is encountered in the first position of the line, it is assumed to be the start of a new production list. The grammar supplied must be unambiguous and LL(1).  
         [0024]    The parser generator uses the symbols ::=, &lt;or &gt;, and &lt;null&gt; to represent BNF productions. The symbols &lt;opnd&gt;, &lt;bkup&gt;, and the variable (‘catRange’) symbols &lt;@nn:mm[:hint text]&gt;and &lt;nn:arbitrary text&gt;also have special meaning and are recognized by the built in parser-generator lexical analyzer. The parser generator will interpret any sequence of upper or lower case letters (a . . . z) or numbers (0 . . . 9) or the underscore character ‘_’, that begins with a letter or underscore, and which is not recognized by, or which is assigned a token number in the range 1-63 by, the lexical analyzer passed in ‘langLex’, as a non-terminal grammar symbol (e.g., program, expression, if statement etc.), these symbols are added to the parser generators grammar symbol list (maximum of 256 symbols) and define the set of non-terminals that make up the grammar. There is no need to specify this set, it is deduced from the BNF supplied. One thing that is very important however, is that the first such symbol encountered in the BNF becomes the root non-terminal of the grammar (e.g., program). This symbol is given special meaning by the parser and thus it must appear on the left hand side of the first production specified in the BNF. The &lt;endf&gt;symbol is used to indicate where the expected end of the input string will occur and its specification cannot be omitted from the BNF. Normally, as in the example below &lt;endf&gt; occurs at the end of the root non-terminal production.  
         [0025]    Referring now to FIG. 1, a sample BNF specification is provided. This BNF gives a relatively complete description of the C language expression syntax together with enforcement of all operator precedence specified by ANSI and is sufficient to create a program to recognize and interpret C expressions. As FIG. 1 demonstrates, the precedence order may be specified simply by choosing the order in which one production leads to another with the lowest precedence grammar constructs/operators being refined through a series of productions into the higher precedence ones. Note also that many productions lead directly to themselves (e.g., more_statements ::=&lt;null&gt; &lt;or &gt; statement more_statements); this is the mechanism used to represent the fact that a list of similar constructs is permitted at this point.  
         [0026]    The syntax for any computer language can be described either as syntax diagrams or as a series of grammar productions similar to that above (ignoring the weird ‘@’ BNF symbols for now). Using this syntax, the code illustrated in FIG. 1 could easily be modified to parse any progams in any number of different computer languages simply by entering the grammar productions as they appear in the language&#39;s specification. The way of specifying a grammar as illustrated in FIG. 1 is a custom variant of the Backus-Naur Form (or BNF). It is the oldest and easiest to understand means of describing a computer language. The symbols enclosed between ‘&lt;‘ ’&gt;’ pairs plus the ‘::=’ symbol are referred to as “meta-symbols”. These are symbols that are not part of the language but are part of the language specification. A production of the form (non_terminal ::=production — 1 &lt;or &gt; production — 2) means that there are two alternative constructs that ‘non-terminal’ can be comprised or, they are ‘production — 1’ or ‘production — 2’.  
         [0027]    The grammar for many programming languages may contain hundreds of these productions, for example, the definition of Algol 60 contains 117. An LL(1) parser must be able to tell at any given time what production out of a series of productions is the right one simply by looking at the current token in the input stream and the non-terminal that it currently has on the top of it&#39;s parsing stack. This means, effectively, that the sets of all possible first tokens for each production appearing on the right hand side of any grammar production must not overlap. The parser must be able to look at the token in the input stream and tell which production on the right hand side is the ‘right one’. The set of all tokens that might start any given non-terminal symbol in the grammar is known as the FIRST set of that non-terminal. When designing a language to be processed by this package, it is important to ensure that these FIRST sets are not defined consistently. In order to understand how to write productions for an LL(1) parser, it is important to understand recursion in a grammar and the difference between left and right recursion in particular.  
         [0028]    Recursion is usually used in grammars to express a list of things separated by some separator symbol (e.g. comma). This can be expressed either as “&lt;A&gt;::=&lt;A&gt;, &lt;B&gt;” or “&lt;A&gt;::=&lt;B&gt;, &lt;A&gt;”. The first form is left recursive the second form is known as right recursive. The production “more_statements ::=&lt;null&gt; &lt;or &gt; statement more_statements” above is an example of a right recursive production. Left recursive statements are not permitted because of the risk of looping during parsing. For example, if the parser tries to use a production of the form ‘&lt;A&gt;::=&lt;A&gt;anything’ then it will fall into an infinite loop trying to expand &lt;A&gt;. This is known as left recursion. Left recursion may be more subtle, as in the pair of productions ‘&lt;S&gt;::=&lt;X&gt;a &lt;or&gt; b’ and ‘&lt;X&gt;::=&lt;S&gt; c &lt;or&gt; d’. Here the recursion is indirect; that is the parser expands ‘&lt;S&gt;’ into ‘&lt;X&gt;a’, then it subsequently expands ‘&lt;X&gt;’ into ‘&lt;S&gt;c’ which gets it back to trying to expand ‘&lt;S&gt;’, thereby creating an infinite loop. This is known as indirect left recursion. All left recursion of this type must be eliminated from grammar before being processed by the parser. A simple method for accomplishing this proceeds as follows: replace all productions of the form ‘&lt;A&gt;::=&lt;A&gt; anything’ (or indirect equivalents) by a set of productions of the form “&lt;A&gt;::=t1 more_t1 &lt;or &gt; . . . &lt;or &gt; tn more_tn” where t1 . . . tn are the language tokens (or non-terminal grammar symbols) that start the various different forms of ‘&lt;A&gt;’.  
         [0029]    A second problem with top down parsers, in general, is that the order of the alternative productions is important in determining if the parser will accept the complete language or not. On way to avoid this problem is to require that the FIRST sets of all productions on the right hand side be non-overlapping. Thus, in conventional BNF, it is permissible to write:  
                                   expression ::= element&lt;or&gt;element + expression&lt;or&gt;element*expression                  
 
         [0030]    To meet the requirements of PS_MakeDB( ) and of an LL(1) parser, this BNF statement may be reformulated into a pair of statements viz:  
                                                   expression ::= element rest_of_expression           rest_of_expression ::= &lt;null&gt; &lt;or&gt; * expression &lt;or&gt; * expression                      
 
         [0031]    As can be seen, the ‘element’ token has been factored out of the two alternatives (a process known as left-factoring) in order to avoid the possibility of FIRST sets that have been defined more than once. In addition, this process has added a new symbol to the BNF meta-language, the &lt;null&gt; symbol. A&lt;null&gt; symbol is used to indicate to the parser generator that a particular grammar non-terminal is nullable, that is, it may not in fact be present at all in certain input streams. There are a large number of examples of the use of this technique in the BNF grammar illustrated in FIG. 1 such as statement  100 .  
         [0032]    The issues above discuss the manner in which LL(1) grammars may be created and used. LL(1) grammars, however, can be somewhat restrictive and the parser of the present invention is capable of accepting a much larger set by the use of deliberate ambiguity. Consider the grammar:  
                                                   operand ::= expression &lt;or&gt; ( address_register )                      
 
         [0033]    This might commonly occur when specifying assembly language syntax. The problem is that this is not LL(1) since expression may itself start with a ‘(’ token, or it may not, thus when processing operand, the parser may under certain circumstances need to look not at the first, but at the second token in the input stream to determine which alternative to take. Such a parser would be an LL(2) parser. The problem cannot be solved by factoring out the ‘(’ token as in the expression example above because expressions do not have to start with a ‘(’. Thus without extending the language beyond LL(1) the nornal parser be unable to handle this situation. Consider however the modified grammar fragment:  
                                                                     operand   ::= .... &lt;or&gt; ( expr_or_indir &lt;or&gt; expression                expr_or_indir   ::= Aregister ) &lt;or&gt; expression)                      
 
         [0034]    Here we have a production for operand which is deliberately ambiguous because it has a multiply defined first set since ‘(’ is in FIRST of both of the last two alternatives. The modified fragment arranges the order of the alternatives such that the parser will take the “( expr_or_indir” production first and should it fail to find an address register following the initial ‘(’ token, the parser will then take the second production which correctly processes “expression )” since expression itself need not begin with a ‘(’ token. If this case were pmeritted, the parser would have the equivalent of a two token look-ahead hence the language it can accept is now LL(2).  
         [0035]    Alternatively, an options parameter ‘kIgnoreAmbiguities’ could be passed to PS_MakeDB( ) to cause it to accept grammars containing such FIRST set ambiguities. On problem with this approach, however, is that it can no longer verify the correctness of the grammar meaning that the user must ensure that the first production can always be reduced to the second production when such a grammatical trick is used. As such, such a paramter should only be used when the grammar is well-understood.  
         [0036]    Grammars can get considerably nastier than LL(2). Consider the problem of parsing the complete set of 68K assembly language addressing modes, or more particularly the absolute, indirect, pre-decrement and post-increment addressing modes. The absolute and indirect syntax was presented above, however the pre-decrement addressing mode adds the form “−(Aregister)”, while the post-increment adds the form “(Aregister )+”. An LL(3) parser would be needed to handle the predecrement mode since the parser cannot positively identify the predecrement mode until it has consumed both the leading ‘−’ and ‘(’ tokens in the input stream. An LL(4) parser is necessary to recognize the postincrement form. One option is to just left-factor out the “(Aregister )” for the postincrement form. This approach would work if the only requirement was recognition of a valid assembly syntax. To the extent that the parser is being used to perform some useful function, however, this approach will not work. Instead, this can be accomplished by inserting a reverse polish plug-in operator. The polish plug-in operator calls for the form &lt;@n:m[:hint text]&gt;into the grammar. Whenever the parser is exposed to such an operator on the top of the parsing stack, it calls it in order to accomplish some sort of semantic action or processing. Assuming a different plug-in is called in order to handle each of the different 68K addressing modes, it is important to know what addressing mode is presented in order to ensure that the proper plug-in is called. In order to do this, the present invention extends the parser language set to be LL(n) where ‘n’ could be quite large.  
         [0037]    The parser of the present invention extend the parser language in this fashion by providing explicit control of limited parser back-up capabilities. One way to provide these capabilities is by adding the &lt;bkup&gt; meta-symbol. Backing up a parser is complex since the parsing stack must be repaired and the lexical analyzer backed-up to an earlier point in the token stream in order to try an alternative production. Nonetheless, the PS_Parse( ) parser is capable of limited backup within a single input line by use of the &lt;bkup&gt; flag. Consider the modified grammar fragment:  
                                                           operand   ::= . . . &lt;or&gt; ( Aregister &lt;bkup&gt; areg_indirect &lt;or&gt;           abs_or_displ &lt;or&gt; . . .            abs_or_displ   ::= − ( ARegister &lt;bkup&gt; ) &lt;@1:1&gt; &lt;or&gt; expression           &lt;@1:2&gt;       areg_indirect   ::= ) opt_postinc            opt_postinc   ::= &lt;@1:3&gt; &lt;or&gt; + &lt;@1:4&gt;                  
 
         [0038]    A limited backup is provided through the following methodology. Let us assume that &lt;@1:1&gt; is the handler for the predecrement mode, &lt;@1:2&gt; for the absolute mode, &lt;@1:3&gt; for the indirect mode, and &lt;@1:4&gt; for the postincrement mode. When the parser encounters a ‘(’ token it will push on the “(Aregister &lt;bkup&gt; areg_indirect” production. Whenever the parser notices the presence of the &lt;bkup&gt; symbol in the production being pushed, however, it saves it&#39;s own state as well as that of the input lexical analyzer. Parsing continues and the ‘(’ is accepted. Now lets assume instead that the input was actually an expression so when the parser tries to match the ‘ARegister’ terminal that is now on the top of it&#39;s parsing stack, it fails. Without the backup flag, this is considered a syntax error and the parser aborts. Because the parser has a saved state, however, the parser restores the backup of the parser and lexical analyzer state to that which existed at the time it first encountered the ‘(’ symbol. This time around, the parser causes the production that immediately follows the one containing the &lt;bkup&gt;flag to be selected in preference to the original. Since the lexical analyzer has also been backed up, the first token processed is once again ‘(’ and parsing proceeds normally through “abs or displ” to “expression” and finally to invokation of plugin &lt;@1:2&gt; as appropriate for the absolute mode.  
         [0039]    Note that a similar but slightly different sequence is caused by the &lt;bkup&gt; flag in the first production for “abs_or_displ” and that in all cases, the plug-in that is appropriate to the addressing mode encountered will be invoked and no other. Thus, by using explicit ambiguity plus controlled parser backup, the present invention provides a parser capable of recognizing languages from a set of grammars that are considerably larger than those normally associated with predictive parsing techniques. Indeed the set is sufficiently large that it can probably handle practically any computer programming language. By judicious use of the plug-in and resolver  400  architectures described below, this language set can be further extended to include grammars that are not context-free (e.g., English,) and that cannot be handled by conventional predictive parsers.  
         [0040]    In order to build grammars for this parser, it is also important to understand is the concept of a FOLLOW set. For any non-terminal grammar symbol X, FOLLOW(X) is the set of terminal symbols that can appear immediately to the right of X in some sentential form. In other words, it is the set of things that may come immediately after that grammar symbol. To build a predictive parser table, PS_MakeDB( ) must compute not only the FIRST set of all non-terminals (which determines what to PUSH onto the parsing stack), but also the FOLLOW sets (which determine when to POP the parsing stack and move to a higher level production). If the FOLLOW sets are not correct, the parser will never pop its stack and eventually willf ail. For this reason; unlike for FIRST sets, ambiguity in the FOLLOW sets is not permitted. What this means is that for any situation in a grammar, the parser must be able to tell when it is done with a production by looking at the next token in the input stream (i.e., the first token of the next production). PS_MakeDB( ) will reject any grammar containing ambiguous FOLLOW sets.  
         [0041]    Before illustrating how the parser of the present invention can be used to accomplish specific tasks, it is important understand how PS_Parse( )  205  actually accomplishes the parsing operation. Referring now to FIG. 2, the parsing function of the present invention is shown. PS_Parse( )  205  maintains two stacks, the first is called the parsing stack  210  and contains encoded versions of the grammar productions specified in the BNF. The second stack is called the evaluation stack  215 . Every time the parser accepts/consumes a token in the input stream in the range 1 . . . 59, it pushes a record onto this evaluation stack  215 . Records on this stack  215  can have values that are either integer, real, pointer or symbolic. When the record is first pushed onto the stack  215 , the value is always ‘symbolic’ since the parser itself does not know how to interpret symbols returned by the lexical analyzer  250  that lie in this range. A symbolic table entry  220  contains the token number recognized by the ‘langLex’ lexical analyzer  250 , together with the token string. In the language defined in FIG. 1, the token number for identifier is 1 (i.e. line  110 ) while that for a decimal integer is 3 (i.e., line  115 ), thus if the parser  205  were to encounter the token stream “A+10”, it would add two symbol records to the evaluation stack  215 . The first would have token number 1 and token string “A” and, the second would have token number 3 and token string “10”. At the time the parser  205  processes an additive expression such as “A+10”, it&#39;s parsing (not evaluation) stack  210  would appear as “mult_expr +mult_expr &lt;@0:15&gt;” where the symbol on the left is at the top of the parsing stack  210 . As the parser  205  encounters the ‘A’ in the string “A+10”, it resolves mult_expression until it eventually accepts the ‘A’ token, pops it off the parsing stack  210 , and pushes a record onto the evaluation stack  215 . So now the parsing stack  210  looks like “+mult_expr &lt;@0:15&gt;” and, the evaluation stack  215  contains just one element “[token=1, String=‘A’ ]”. The parser  205  then matches the ‘+’ operator on the stack with the one in the input and pops the parsing stack  210  to obtain “mult_expr &lt;@0:15&gt;”. Parsing continues with the input token now pointing at the 10 until it too is accepted. This process yields a parsing stack  210  of “&lt;@0:15&gt;” and an evaluation stack  215  of “[token=3,String=‘10’][token=1,String=‘A’ ]” where the left hand record is considered to be the top of the stack.  
         [0042]    At this point, the parser  205  recognizes that it has exposed a reverse-polish plug-in operator on the top of its parsing stack  210  and pops it, and then calls the appropriate plug-in, which, in this case, is the built in add operation provided by PS_Evaluate( )  260 , a predefined plug-in called plug-in zero  260 . When the parser  205  calls plug-in zero  260 , the parser  205  passes the value 15 to the plug-in  260 . In this specific case, 15 means add the top two elements of the parsing stack, pop the stack by one, and put the result into the new top of stack. This behavior is exactly analogous to that performed by any reverse polish calculator. This means that the top of the evaluation stack  215  now contains the value A+10 and the parser  205  has actually been used to interpret and execute a fragment of C code. Since there is provision for up to 63 application defined plug-in functions, this mechanism can be used to perform any arbitrary processing as the language is parsed. Since the stack  215  is processed in reverse polish manner, grammar constructs may be nested to arbitrary depth without causing confusion since the parser  205  will already have collapsed any embedded expressions passed to a higher construct. Hence, whenever a plug-in is called, the evaluation stack  215  will contain the operands to that plug-in in the expected positions.  
         [0043]    To illustrate how a plug-in might look, FIG. 3 provides a sample code fragment from a predefined plug-in that handles the ‘+’ operator (TOF_STACK is defined as 0, NXT_STACK as 1). As FIG. 3 illustrates, this plug-in first evaluates  305  the values of the top two elements of the stack by calling PS_Evalldent( ). This function invokes the registered ‘resolver  400 ’ function in order to convert a symbolic evaluation stack record to a numeric value (see below for description of resolver  400 ). Next the plug-in must determine  310  the types of the two evaluation stack elements (are they real or integer?). This information is used in a case statement to ensure that C performs the necessary type conversions on the values before they are used in a computation. After selecting the correct case block for the types of the two operands, the function calls PS_SetiValue( ) or PS_SetfValue( )  315  as appropriate to set the numeric value of the NXT_STACK element of the evaluation stack  215  to the result of adding the two top stack elements. Finally, at the end of the routine, the evaluation stack  215  is popped  220  to move the new top of the stack to what was the NXT_STACK element. This is all it takes to write a reverse polish plug-in operator. This aspect of the invention permits a virtually unlimited number of support routines that could be developed to allow plug-ins to manipulate the evaluation stack  215  in this manner.  
         [0044]    Another problem that has been addressed with the plug-in architecture of the present invention is the problem of having the plug-in function determine the number of parameters that were passed to it; for instance, a plug-in would need to know the number of parameters in order to process the C printf( ) function (which takes a variable number of arguments). If a grammar does not force the number of arguments (as in the example BNF above for the production “&lt;opnd&gt;(parameter_list )&lt;@1:1&gt;”, then a &lt;opnd&gt; meta-symbol can be added at the point where the operand list begins. The parser  205  uses this symbol to determine how many operands were passed to a plug-in in response to a call requesting this information. Other than this purpose, the &lt;opnd&gt; meta-symbol is ignored during parsing. The &lt;opnd&gt; meta-symbol should always start the right hand side (RHS) of a production in order to ensure correct operand counting. For example, the production:  
                                                       primary   ::= &lt;9:Function&gt; &lt;opnd&gt; ( parameter_list) &lt;@1:1&gt;                      
 
         [0045]    Will result in an erroneous operand count at run time, while the production pair below will not:  
                                                                     primary   ::= &lt;9:Function&gt; rstof_fn_call &lt;@1:1&gt;                restof_fn_call   ::= &lt;opnd&gt; ( parameter_list )                      
 
         [0046]    The last issue is how to actually get the value of symbols into the parser  205 . This is what the symbols in the BNF of the form “&lt;n:text string&gt;” are for. The numeric value of ‘n’ must lie between 1 and 59 and it refers to the terminal symbol returned by the lexical analyzer  250  passed in via ‘langLex’ to PS_MakeDB( ). It is assumed that all symbols in the range 1 . . . 59 represent ‘variable tokens’ in the target language. That is, tokens whose exact content may vary (normally recognized by a LEX catRange table) in such a way that the string of characters within the token carry additional meaning that allows a ‘value’ to be assigned to that token. Examples of such variable tokens are identifiers, integers, real numbers etc. A routine known as a ‘resolver  400 ’ will be called whenever the value of one of these tokens is required or as each token is first recognized. In the BNF illustrated in FIG. 1, the lexical analyzer  250  supplied returns token numbers 3, 7, 8, 9, 10 or 11 for various types of C integer numeric input; 4, 5, and 6 for various C real number formats; 1 for a C identifier (i.e., non-reserved word); and 2 for a character constant.  
         [0047]    Referring now to FIG. 4, a simple resolver 400 which converts these tokens into the numeric values required by the parser  205  (assuming that identifiers are limited to single character values from A . . . Z or a . . . z) is shown. As FIG. 3 illustrates, when called to evaluate a symbol, the resolver  400  determines which type of symbol is involved by the lexical analyzer token returned. It then calls whatever routine is appropriate to convert the contents of the token string to a numeric value. In the example above, this is trivial because the lexical analyzer  250  has been arranged to recognize C language constructs. Hence we can call the C I/O library routines to make the conversion. Once the value has been obtained, the resolver  400  calls the applicable routine and the value is assigned to the designated evaluation stack  215  entry. The resolver  400  is also called whenever a plug-in wishes to assign a value to a symbolic evaluation stack  215  entry by running the ‘kResolver Assign’ case block code. In this case, the value is passed in via the function parameters and the resolver  400  uses the token string in the target evaluation stack  215  entry to determine how and where to store the value.  
         [0048]    The final purpose of the resolver function  400  is to examine and possibly edit the incoming token stream in order to effectively provide unlimited grammar complexity. For example, consider the problem of a generalized query language that uses the parser. It must define a separate sub-language for each different container type that may be encountered in a query. In such a case, a resolver function  400  could be provided that recognizes the beginning of such a sub-language sequence (for example a SQL statement) and modifies the token returned to consume the entire sequence. The parser  205  itself would then not have to know the syntax of SQL but would simply pass the entire SQL statement to the selected plug-in as the token string for the symbol returned by the recognizer. By using this approach, an application using PS_Parse( ) is capable of processing virtually any grammar can be built.  
         [0049]    The basic Application Programming Interface (API) to the parser  205  of this invention is given below. The discussion that follows describes the basic purpose of these various API calls. Sample code for many of these functions is provided in Appendix A.  
         [0050]    PS_SetParserTag( ), PS_GetParserTag( ). These functions get and permit modification of a number of numeric tag values associated with a parser  205 . These values are not used by internal parser  205  code and are available for custom purposes. This is often essential when building custom parsing applications upon this API.  
         [0051]    PS_Pop( ), PS_Push( ). The functions pop or push the parser  205  evaluation stack  215  and are generally called by plug-ins.  
         [0052]    PS_PushParserState( ), PS_PopParserState( ). Push/Pop the entire internal parser  205  state. This capability can be used to implement loops, procedure calls or other similar interpreted language constructs. These functions may be called within a parser plug-in in order to cause a non-local transfer of the parser state. The entire parser state, including as a minimum the evaluation stack  215 , parser stack  210 , and input line buffer must be saved/restored.  
         [0053]    PS_ParseStackElem( ). This function returns the current value of the specified parsing stack  210  element (usually the top of the stack). This stack should not be confused with the evaluation stack  215  to which most other stack access functions in this API refer. As described above, the parser stack  210  is used internally by the parser  205  for predictive parsing purposes. Values below 64 are used for internal purposes and to recognize complex tokens such as identifiers or numbers, values above 64 tend to be either terminal symbols in the language being parsed, or non-terminals that are part of the grammar syntax definition (&gt;=32256). Plug-ins have no direct control of the parsing stack  210 , however they may accomplish certain language tricks by knowing the current top of stack and altering the input stream perceived by the parser  205  as desired.  
         [0054]    PS_PopTopOfParseStack( ),PS_PushTopOfParseStack( ). PS PopTopOfParseStack( ) pops and discards the top of the parsing stack  210  (see PS_TopOfParseStack). This is not needed under normal circumstances, however this technique can be used to discard unwanted terminal symbols off the stack  210  in cases where the language allows these to be optional under certain circumstances too complex to describe by syntax.  
         [0055]    PS_WillPopParseStack( ). In certain circumstances, it may be necessary for a parser recognizer function to determine if the current token will cause the existing parser stack  210  to be popped, that is “is the token in the FOLLOW set of the current top of the parse?” This information can be used to terminate specialized modes where the recognizer loops through a set of input tokens returning −3, which causes the parser  205  to bulk consume input. A parameter is also provided that allows the caller to determine where in the parsing stack  210  the search can begin, normally this would be the top of the stack i.e., parameter=0.  
         [0056]    PS_IsLegalToken( ). This function can be used to determine if a specific terminal token is a legal starting point for a production from the specified non-terminal symbol. Among other things, this function may be used within resolver  400  functions to determine if a specific token number will cause a parsing error if returned given the current state of the parsing stack. This ability allows resolver  400  functions to adjust the tokens they return based on what the parse state is.  
         [0057]    PS_GetProduction( ). This function obtains the parser production that would replace the specified non-terminal on the stack  210 ,  215  if the specified terminal were encountered in the input. This information can be used to examine future parser  205  behavior given the current parser  205  state and input. The [0] element of each element of the production returned contains the terminal or non-terminal symbol concerned and can be examined using routines like PS_IsPostFixOperator( ).  
         [0058]    PS_IsPostFixOperator( ) determines if the specified parse stack element corresponds to the postfix operator specified.  
         [0059]    PS_MakeDB( ). This function creates a complete predictive parsing database for use with PS_Parse( ). If successful, returns a handle to the created DB, otherwise returns zero. The algorithm utilized by this function to construct a predictive parser  205  table can be found in any good reference on compiler theory. The parser  205  utilizes a supplied lexical analyzer as described in Appendix 1. When no longer required, the parser  205  can be disposed using PS_KilIDB( ).  
         [0060]    PS_DisgardToken( ). This function can be called from a resolver  400  or plug-in to cause the current token to be discarded. In the case of a resolver  400 , the normal method to achieve this effect is to return −3 as the resolver  400  result, however, calling this function is an alternative. In&#39;the case of a plug-in, a call to this function will cause an immediate call to the resolver  400  in order to acquire a new token.  
         [0061]    PS_RegisterParser( ), PS_DeRegisterParser( ), PS_ResolveParser( ), PS_CloneDB( ). These routines are all associated with maintaining a cache of recently constructed parsers so that subsequent invocations of parsers for identical languages can be met instantaneously. The details of this cache are not pertinent to this invention.  
         [0062]    PS_LoadBNF( ), PS_LoadBlock( ), PS_ListLanguages( ). These routines are all associated with obtaining the BNF specification for a parser  205  from a text file containing a number of such specifications. The details of this process are not pertinent to this invention.  
         [0063]    PS_StackCopy( ). This function copies one element of a parser stack 210 to another.  
         [0064]    PS_SetStack( ) sets an element of a parsing stack  210  to the designated type and value.  
         [0065]    PS_CalBuiltInLex( ). This function causes the parser to move to the next token in the input stream. In some situations, a resolver  400  function may wish to call it&#39;s own lexical analyzer prior to calling the standard one, as for example, when processing a programming language where the majority of tokens appearing in the input stream will be symbol table references. By calling it&#39;s own analyzer first and only calling this function if it fails to recognize a token, a resolver  400  can save a considerable amount of time on extremely large input files.  
         [0066]    PS_GetLineCount( ). This function returns the current line count for the parse. It is only meaningful from within the parse itself (i.e., in a plug-in or a resolver  400  function).  
         [0067]    PS_GetStackDepth( ). This function returns the current depth of the parsing evaluation stack. This may be useful in cases where you do not want to pay strict attention to the popping of the stack during a parse, but wish to ensure that it does not overflow by restoring it to a prior depth (by successive PS_Pop( )&#39;s) from a plug-in at some convenient synchronizing grammatical construct.  
         [0068]    PS_SetOptions( ), PS_ClrOptions( ), PS_GetOptions( ). The function PS_SetOptions( ) may be used to modify the options for a parse DB (possibly while it is in progress). One application of such a function is to turn on full parse tracing (from within a plug-in or resolver 400) when the line count reaches a line at which you know the parse will fail. PS_ClrOptions performs the converse operation, that is, it clears the parsing options bits specified. The function PS_GetOptions( ) returns the current options settings.  
         [0069]    PS_FlagError( ). In addition to invoking an underlying error logging facility if something goes wrong in a plug-in or resolver  400 , this routine can be called to force the parser to abort. If this routine is not called, the parse will continue (which may be appropriate if the erroneous condition has been repaired).  
         [0070]    PS_ForceReStart( ). This function causes the parse to re-start the parse from scratch. It is normally used when plug-ins or resolver  400 s have altered the source text as a result of the parsing process, and wish the parser to re-scan in order to force a new behavior. This function does not alter the current lexical analyzer position (i.e., it continues from where it left off). If you wish to do this also you must call PS_SetTokenState( ).  
         [0071]    PS_StackType( ) This function gets the contents type of a parser stack element and return the stack element type. PS_GetOpCount( ) gets the number of operands that apply to the specified stack element which should be a plug-in reverse polish operator, it returns the number of operands passed to the plug-in or −1 if no operand list is found. PS_GetValue( ) gets the current value of a parser stack element and returns a pointer to the token string, or NULL if not available.  
         [0072]    PS_SetElemFlags( ), PS_ClrElemFlags( ), PS_GetElemFlags( ). The first two routines set or clear flag bits in the stack element flag word. PS_GetElemFlags( ) returns the whole flags word. These flags may be used by resolver  400 s and plug-ins to maintain state information associated with elements on the evaluation stack  215 .  
         [0073]    PS_SetiValue( ), PS_SetfValue( ), PS_SetpValue( ), PS_SetsValue( ). These routines set the current value and type of a parser stack element to the value supplied where:  
         [0074]    PS_SetiValue( )—sets the element to a 64 bit integer  
         [0075]    PS_SetfValue( )—sets the element to a double  
         [0076]    PS_SetpValue( )—sets the element to a pointer value  
         [0077]    PS_SetsValue( )—sets the element to a symbol number  
         [0078]    PS_GetToken( ). Gets the original token string for a parsing stack element. If the stack element no longer corresponds to an original token (e.g., it is the result of evaluating an expression) then this routine will return NULL, otherwise it will return the pointer to the token string.  
         [0079]    PS_AssignIdent( ). This routine invokes the registered identifier resolver  400  to assign a value of the specified type to that identifier; it is normally called by plug-ins in the course of their operation.  
         [0080]    PS_EvalIdent( ). This routine invokes the registered identifier resolver  400  to evaluate the specified identifier, and assign the resulting value to the corresponding parser stack element (replacing the original identifier record); it is normally called by plug-ins in the course of their operation. Unlike all other assignments to parser stack elements, the assignment performed by the resolver  400  when called from this routine does not destroy the original value of the token string that is still available for use in other plug-in calls. If a resolver  400  wishes to preserve some kind of token number in the record, it should do so in the tag field that is preserved under most conditions.  
         [0081]    PS_SetResolver  400 ( ),PS_SetPlugIn( ). These two functions allow the registration of custom resolver  400  and plug-in functions as described above. Note that when calling a plug-in, the value of the ‘pluginHint’ will be whatever string followed the plug-in specifier in the BNF language syntax (e.g., &lt;@1:2:Arbitrary string&gt;). If this optional string parameter is not specified OR if the ‘kPreserveBNFsymbols’ option is not specified when creating the parser, ‘pluginHint’ will be NULL. This capability is very useful when a single plug-in variant is to be used for multiple purposes each distinguished by the value of ‘pluginHint’ from the BNF. One special and very powerful form of this that will be explored in later patents is for the ‘pluginHint’ text to be the source for interpretation by an embedded parser, that is executed by the plug-in itself.  
         [0082]    PS_SetLineFinder( ). Set the line-finder function for a given parser database. Line-finder functions are only required when a language may contain embedded end-of-line characters in string or character constants, otherwise the default line-finder algorithm is sufficient.  
         [0083]    PS_SetContextID( ),PS_GetContextID( ). The set function may be called just once for a given parser database and sets the value for the ‘aContextID’ parameter that will be passed to all subsequent resolver  400  and plug-in calls, and which is returned by the function PS_GetContextID( ). The context ID value may be used by the parser application for whatever purpose it requires, it effectively serves as a global common to all calls related to a particular instance of the parser. Obviously an application may chose to use this value as a pointer to additional storage.  
         [0084]    PS_AbortParse( ). This function can be called from a resolver 400 or plug-in to abort a parse that is in progress.  
         [0085]    PS_GetSourceContext( ). This function can be used to obtain the original source string base address as well as the offset within that string corresponding to the current token pointer. This capability may be useful in cases where parser  205  recognizers or plug-ins need to see multiple lines of source text in order to operate.  
         [0086]    PS_GetTokenState( ), PS_SetTokenState( ). These routines are provided to allow a resolver  400  function to alter the sequence of tokens appearing at the input stream of the parser  205 . This technique is very powerful in that it allows the grammar to be extended in arbitrary and non-context-free ways. Callers to these functions should make sure that they set all the three token descriptor fields to the correct value to accomplish the behavior they require. Note also that if resolver  400  functions are going to actually edit the input text (via the token pointer) they should be sure that the source string passed to PS_Parse( )  205  is not pointing to a constant string but is actually in a handle for which source modification is permissible. The judicious use of token modification in this manner is key to the present invention&#39;s ability to extend the language set that can be handled far beyond LL(1).  
         [0087]    PS_SetFlags( ), PS_ClrFlags( ), PS_GetFlags( ). Set or clear flag bits in the parsers flag word. PS_GetFlags( ) returns the whole flags word. These flags may be used by resolver  400 s and plug-ins to maintain state information.  
         [0088]    PS_GetIntegerStackValue( ), PS_GetRealStackValue( ). These functions obtain an integer or real value from the parse evaluation stack  215 .  
         [0089]    PS_Sprintf( ). This function implements a standard C library sprintf( ) capability within a parser  205  for use by embedded languages where the arguments to PS_Sprintf( ) are obtained from the parser evaluation stack  215 . This function is simply provided as a convenience for implementing this common feature.  
         [0090]    PS_Parse( ). This function parses an input string according to the grammar provided, as set forth above. Sample code illustrating one embodiment of this function is also provided in Appendix A.  
         [0091]    The foregoing description of the preferred embodiments of the invention has been presented for the purposes of illustration and description. For example, the term “parser” throughout this description is addressed as it is currently used in the computer arts related to compiling. This term should not be narrowly construed to only apply to compilers or related technology, however, as the method and system could be used to enhance any sort of data management system. The descriptions of the header structures should also not be limited to the embodiments described. While the sample code provides examples of the code that may be used, the plurality of implementations that could in fact be developed is nearly limitless. For these reasons, this description is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto.