Lexical State Analyzer

Researchers have designed grammar analyzers with many different purposes. Identifying ambiguity of context free grammars has received a fair amount of attention [Gorn63, amber, BrabrandGigerichMoller10, BastenStorm10, VasudevanTratt12]. Similarly, there have been prior works on verifying [BarthwalNorrish09] and validating parsers [JourdanPottierLeroy12]; these focus on ensuring that the semantics of the parser matches that of the grammar. None of these papers deal with lexical states and erroneous situation arising in such a context. In contrast, our paper aims at identifying errors in grammars that use lexical states.

The use of context to improve the precision of program analysis is a well known technique. The trade-offs between context-sensitive (improved precision) and context-insensitive (faster) are well studied [Muchnick97, NielsonNielsonHankin99]. In this paper, we use the notion of context-sensitive and context-insensitive analysis to present two analyses that help identify errors and warnings in context free grammars (CFGs) that use tokens with lexical states.

We first discuss a representative scheme for token and grammar specification that we will use to explain our techniques. We will assume that the input grammar follows this specification. Our specification can be used to generate grammars in JavaCC format trivially. Details about the JavaCC syntax can be found in the manual [javacc].

A typical definition of lexical tokens is of the form: {tightcode} ¡I1, I2 …In¿ TOKEN : { ¡Token1:RegEx1¿ : Os ¡Token2:RegEx2¿ } It defines two tokens Token1 and Token2 corresponding to two regular expressions RegEx1 and RegEx2. Given a string matching RegEx1 (or RegEx2), the scanner returns the token Token1 (or Token2) if its current state $s\in \left\{\text{I1,I2,...In}\right\}$. If the scanner returns the token Token2, the scanner will remain in state $s$. If the scanner returns the token Token1, the scanner will switch to state Os. Thus every lexical token have a non-empty set of in-states and a corresponding set of out-states.

We will assume that the input grammar can be derived from the following representative grammar:

We use $T$ to denote terminals and $N_i$ to denote non terminals in the grammar. We expect that $N_e$ is the only non-terminal whose production string is $ϵ$. We will also assume that every non-terminal must have a unique production associated with it. Note that our grammar is general enough to derive any LL (and hence JavaCC) grammar. And our actual implementation can deal with the complete JavaCC grammar.

A context-free grammar can be specified using the four tuple ($N,T,P,S$), where $N$ is a set of non-terminals, $T$ is a set of terminals, $P$ is a set of productions in the above described form and $S\in N$ is the initial non-terminal symbol.

We next present a naive algorithm to identify and eliminate useless productions (UPs) in the grammar. We call a production as useless, if it cannot be reached from the start non-terminal. Figure 2 presents a sketch of the algorithm. Starting with the start non-terminal $S$, we “visit” all the non-terminals and mark the non-terminals used in the corresponding productions. We make a post-pass to collect and return all the unmarked non-terminals (in variable $D$). As it can be seen this algorithm does not take into consideration the lexical states of the terminals in use. And thus the effectiveness of this algorithm is limited.

We now present our context insensitive lexical state analysis. The analysis populates two different maps inStates and outStates (Figure 3) for its internal use. For each non terminal, the inStates and outStates maps store the in-states and out-states, respectively. For all the non terminals, these two maps are initialized to contain empty sets. We use $P\left(X\right)$ to denote the power set of $X$. We assume that the out-state map for terminals ($O$) and in-state map for terminals ($I$) are trivially precomputed (code not shown) from the rules given for lexical tokens.

Figure 4 presents a sketch of our context insensitive analysis. The main function Main-CInsensitive takes the grammar ($G=(N,T,P,S)$) as input and first calls Find-Useless-Productions to identify all the useful productions. It follows a worklist based approach to compute the out- and in-states for all the non terminals. We say that a non terminal $N_2$ uses a non terminal $N_1$, if $N_1$ appears on the right side of the production corresponding to $N_2$.

CI-BuildOutStates: The out-state of a non-terminal depends on the exact production corresponding to the non-terminal. If the production is of the form $N_0\to N_1|N_2$, then out-states of $N_0$ includes the out-states of $N_1$ and $N_2$. If the production is of the form $N_0\to N_1{N}_2$, then out-states of $N_0$ includes the out-states of $N_2$ and optionally that of $N_1$, if $N_2$ derives the empty string $ϵ$.

CI-BuildInStates: Similar to the construction of outStates, we update the inStates map for each production depending on its form. One main difference between the two is that when the production is of the form $N_0\to N_1{N}_2$: the in-states of $N_0$ includes the in-states of $N_1$ and optionally that of $N_2$, if $N_1$ derives the empty string $ϵ$.

CI-Analyze: After the in- and out-states of all the non terminals are computed, we first check if the start non terminal ($G.S$) can be parsed in the default lexical state (DEFAULT). We then invoke the CI-Analyze method to check if the lexical states ($S$) in which a non terminal $N_0$ can be accessed matches that of its in-states (inStates[$N_0$]). If there are no common elements between $S$ and inStates[$N_0$], then it is flagged as an error. If $S$ includes lexical states that are not part of inStates[$N_0$], then it is a possible error and hence marked as a warning. A context insensitive error/warning consists of just the non-terminal in which the error/warning is identified.

Example: Figure 5 shows a sample grammar with two lexical states (DEFAULT and LX1). The in-, out-states computed using the context insensitive analysis along with identified errors and warnings are shown in columns 2-4 of Figure 6. For example, it says that non terminal E will always lead to an error state.

Complexity: We will use $L$ to denote the number of lexical states, $N$ to denote the grammar size; in the worst case $L=O\left(N\right)$, but in practise it rarely happens. The complexity of CI-BuildOutStates and CI-BuildInStates functions is $O\left(1\right)$. Each of the while loops in Main-CInsensitive is at most invoked $O(N\times L)$ times – in each iteration, size of the outStates map of at least one non terminal increases by one.

We now describe our context sensitive analysis. Here the set of lexical states LS, contains an additional error state $E$. If a terminal or non-terminal cannot be parsed in a specific lexical state (including the error state $E$), then we consider the resulting lexical state to be $E$. Compared to the context insensitive analysis, the outStates map contains more detailed information. It stores the out-states for each non terminal for each possible lexical state – outStates: NT $\times$ LS $\to$ $P$(LS). For all the non terminals, for each lexical token, this map is initialized to contain empty sets. For the outStates map, we use a specialized union operator ($\bigsqcup$) to do an element wise union of all the elements of the operands.

$\begin{array}{c}S=\text{tt outStates}\left[N_1\right]\bigsqcup \text{tt outStates}\left[N_2\right]\\ \equiv \\ \forall i\in \text{LT}:S\left[i\right]=\text{tt outStates}\left[N_1\right]\left[i\right]\cup \text{tt outStates\%}\left[N_2\right]\left[i\right]\end{array}$

Figure 7 presents a sketch of our context sensitive analysis. The main function Main-CSensitive takes the grammar ($G=(N,T,P,S)$) as input and first calls Find-Useless-Productions to identify all the useful productions. It follows a worklist based approach to compute the out-states for all the non terminals. The CS-BuildOutStates function is similar to that described in the context insensitive analysis (Figure 4). One main variation being the current version maintains separate set of out-states for each lexical state. Once the out-states are computed it calls the CS-Analyze to analyze the grammar, starting with the start non-terminal ($G.S$) and default lexical state as the in-states set ({DEFAULT}).

CS-Analyze: We first check if the current non-terminal ($N$) has already been analyzed for the in-states $S$. If it has been already analyzed for all the member states in $S$, then we return the non error out-states of $N$ over all the in-states. We use a two dimensional boolean array (isAnalyzed), all elements initialized to false, to check whether a production has already been analyzed or not. For a given lexical state, if the out-states of $N$ consists of only the error state $E$, then it is marked as an error. A context sensitive error consists of the non-terminal and the lexical state in which the error is identified. Note that, we avoid issuing any warnings for any non-terminal $N$ and lexical state $l$ (when $E\in \text{tt outStates}\left[N\right]\left[l\right]$), because the source of the warning would anyway be reported as an error; thereby, we avoid too many messages. If $N$ has not been analyzed for a subset of input states we recursively analyze the non-terminals used by $N$.

Example For the example program shown in Figure 5, the out-states of each non terminal for each lexical state computed using the context sensitive analysis, along with the identified errors (note, the error is specific to a non terminal and a lexical token) are shown in columns 5-7 of Figure 6. For example, it says that non terminal D leads to an error state when it is matched in lexical state DEF or LX1. As it can be seen the context sensitive analysis reports all the errors including those that are otherwise not reported by the context insensitive analysis.

Complexity: The complexity of the $\bigsqcup$ operator is $O\left(N\right)$. The complexity of CS-BuildOutStates function is $O\left(L^2\right)$. The while loop in Main-CSensitive is at most invoked $O(N\times L^2)$ times – in each iteration, size of the outStates map for at least one non-terminal for at least one in-state increases by one. The CS-Analyze function can be called at most $O(N\times L)$ times and in each invocation the work done is bound by $O\left(L\right)$. This leads to an overall complexity of Main-CSensitive as $O(N\times L^4)$. In practise, size of $L$ is a small number and that makes it almost linear.

We now discuss, how we can generate example strings that can be used to establish errors in a grammar. We represent the grammar as a graph, and reduce the problem of generating “error” examples, as that of computing an annotated path from the start node to the error node.

Given a context free grammar that uses tokens with lexical states, we represent as a forest (called lexical-transition-graph), where each connected component corresponds to a different production (labeled by that non terminal). To avoid the problem of too many edges we keep the forest sparse and omit the edges between the use of a non-terminal and the graph corresponding to its production, in our figures shown in this manuscript; such edges depict parent-child (use of a non-terminal - its corresponding production) relationship. Each connected component can be seen as a graph $G=(N,E)$, where $N$ is the set of nodes consisting of all the non-terminals, terminals and a set of special operators $\Pi$ present in the production. For the subset of grammar presented in Section 2.1, $\Pi =\{\bullet ,or\}$, representing the sequencing and choice operators²²2The complete JavaCC grammar syntax allows strings of the form $X\ast$, $X+$ and $\left[X\right]$; thus $\Pi$ consists of additional operators “$\ast$”, “$+$” and “[]”.. Such graph admits a natural parent-child relationship – each terminal and non-terminal on the right side of a production for a non-terminal are marked as its children. Similarly, each special operator works a parent for each non-terminal and other special operators contained with in. Each node has an attached set of in-states and out-states. The set of in-states of an operator node are connected to the corresponding in-states of all its children. Similarly the set of out-states of an operator node are connected to the corresponding out-states of its children. The set of in- and out-states of a token are connected as per the state transitions defined in the grammar. They basically represent the lexical state transitions that are taking place in the grammar.

Given a particular context sensitive error $(N_1,l)$, we find a path from $N_1$ to the root (start non terminal); this path in reverse ensures that we reach $N_1$ in state $l$. Figure 8 presents the algorithm. We recursively visit the parents of the current node till we reach the graph for the start node (root). Next we retrace the path (from the root to $N_1$) and at each intermediate node $N_i$ in the path, whose production is of the form $N_i\to t_i$, we output a part of the example string.

Example: For the grammar shown in Figure 5, Figure 9 shows the generated lexical transition graph for two production rules E and H. The red marked box shows that there are no “out” edges from D thus indicating an error in E. The graph for node H suffers from no such problems. Our counter example generation routine would generate the string bcbcbcbcc as an example that cannot be parsed. Note that, we have deliberately skipped the box corresponding to the“$\bullet$” in the graph for E to avoid clutter of rectangles.

In this section, we compare the precision of the context sensitive and insensitive analysis. Say $E_i\subseteq$ NT and $E_s\subseteq$ NT $\times$ LS are the sets of errors identified by context insensitive and context sensitive analysis, respectively. Say, the set of non-terminals present in $E_s$ are given by $N_{es}$.

We present a sketch of the proof in Appendix A. This theorem ensures that context sensitive analysis identifies all the errors shown in the context insensitive analysis and may be more.

It can be noted that our context sensitive and insensitive algorithms are essentially identifying “useless” non terminals in different productions. Thus it can be argued that we should be able to use the discussed useless production removal procedure (Figure 2) to identify “useless” non-terminals, if the grammar with lexical states can be converted to an equivalent grammar with no lexical states. A grammar with lexical states converted to a grammar with non-lexical states by duplicating terminals and non-terminals such that each one has an unique in-state and unique out-state; However, such a translation (from grammar with lexical states to one without) can lead to exponential blow up. One such example is given below:

Say, we have $n$ number of lexical states ($L{s}_1,L{s}_2,\dots L{s}_n$), and each terminal $a_i$ is declared as: $<$L1, L2, …Ln$>$ TOKEN : <$a_i$: $Rege{x}_i$>. Thus, each token $a_i$ has $n$ in-states and an unique out state $L{s}_i$. A translation as suggested above would lead to $O\left(n^w\right)$ productions, rendering the overall analysis impractical.

Given an input grammar, LSA invokes our analyses to find warnings and errors. Next, as described in Section 2.5, it creates a lexical transition graph for the input grammar (in DOT [dot] format), along with the lexical states. This graph represents the lexical state transitions that are taking place in the grammar. We then highlight the edges which can lead to error states. Figure 10 shows a part of the graph generated for the motivating example shown in Figure 1. It shows that there are no edges from the out-states of Field (BR_DATA and QT_DATA) to in-states of the “*” sub-production (FIELDS). Thus we cannot use this production to parse more than one Field.

We briefly discuss some of the limitations of our implementation. We analyze the lexical state transitions only in the BNF productions (not Javacode productions) and only with respect to the TOKEN regular expression specifications. JavaCC constructs such as SKIP, MORE and SPECIAL TOKENS are not handled as they do not appear directly in BNF productions. Similarly, we do not handle inlined Java code; JavaCC allows the inlined code to change the scanner state using a specialized function SwitchTo. This function takes an integer argument representing the state to change to. Thus precise lexical state transition analysis would depend on identifying the value that flows into these arguments. Analyzing lexical state transitions involving SwitchTo functions is left as a future work.