% Chapter Template

\chapter{Regular Expressions and POSIX Lexing} % Main chapter title

\label{Inj} % In chapter 2 \ref{Chapter2} we will introduce the concepts

%and notations we 

%use for describing the lexing algorithm by Sulzmann and Lu,

%and then give the algorithm and its variant, and discuss

%why more aggressive simplifications are needed. 

\section{Basic Concepts and Notations for Strings, Languages, and Regular Expressions}

We have a primitive datatype char, denoting characters.

\[			char ::=  a

			 \mid b

			 \mid c

			 \mid  \ldots

			 \mid z       

\]

(which one is better?)

\begin{center}

\begin{tabular}{lcl}

$\textit{char}$ & $\dn$ & $a | b | c | \ldots$\\

\end{tabular}

\end{center}

They can form strings by lists:

\begin{center}

\begin{tabular}{lcl}

$\textit{string}$ & $\dn$ & $[] | c  :: cs$\\

& & $(c\; \text{has char type})$

\end{tabular}

\end{center}

And strings can be concatenated to form longer strings:

\begin{center}

\begin{tabular}{lcl}

$[] @ s_2$ & $\dn$ & $s_2$\\

$(c :: s_1) @ s_2$ & $\dn$ & $c :: (s_1 @ s_2)$

\end{tabular}

\end{center}

A set of strings can operate with another set of strings:

\begin{center}

\begin{tabular}{lcl}

$A @ B $ & $\dn$ & $\{s_A @ s_B \mid s_A \in A; s_B \in B \}$\\

\end{tabular}

\end{center}

We also call the above "language concatenation".

The power of a language is defined recursively, using the 

concatenation operator $@$:

\begin{center}

\begin{tabular}{lcl}

$A^0 $ & $\dn$ & $\{ [] \}$\\

$A^{n+1}$ & $\dn$ & $A^n @ A$

\end{tabular}

\end{center}

The union of all the natural number powers of a language   

is denoted by the Kleene star operator:

\begin{center}

\begin{tabular}{lcl}

\end{tabular}

\end{center}

as an inductive set: 

\begin{center}

\begin{tabular}{lcl}

\end{tabular}

\end{center}

\subsection{Language Derivatives}

We also define an operation of chopping off a character from

a language:

\begin{center}

\begin{tabular}{lcl}

$\textit{Der} \;c \;A$ & $\dn$ & $\{ s \mid c :: s \in A \}$\\

\end{tabular}

\end{center}

This can be generalised to chopping off a string from all strings within set $A$:

\begin{center}

\begin{tabular}{lcl}

$\textit{Ders} \;w \;A$ & $\dn$ & $\{ s \mid w@s \in A \}$\\

\end{tabular}

\end{center}

which is essentially the left quotient $A \backslash L'$ of $A$ against 

the singleton language $L' = \{w\}$

in formal language theory.

With the  sequencing, Kleene star, and $\textit{Der}$ operator on languages,

we have a  few properties of how the language derivative can be defined using 

sub-languages.

\begin{lemma}

\end{lemma}

\noindent

This lemma states that if $A$ contains the empty string, $\Der$ can "pierce" through it

and get to $B$.

of $A$:

\begin{lemma}

\end{lemma}

\begin{proof}

\begin{itemize}

\item{$\subseteq$}

The set 

is enclosed in the set

because whenever you have a string starting with a character 

immediately after it will form the first iteration, and the rest of the string will 

\item{$\supseteq$}

Note that

and 

where the $\textit{RHS}$ of the above equatioin can be rewritten

\end{itemize}

\end{proof}

Before we define the $\textit{Der}$ and $\textit{Ders}$ counterpart

for regular languages, we need to first give definitions for regular expressions.

Suppose we have an alphabet $\Sigma$, the strings  whose characters

are from $\Sigma$

can be expressed as $\Sigma^*$.

We use patterns to define a set of strings concisely. Regular expressions

are one of such patterns systems:

The basic regular expressions  are defined inductively

 by the following grammar:

\[			r ::=   \ZERO \mid  \ONE

			 \mid  c  

			 \mid  r_1 \cdot r_2

			 \mid  r_1 + r_2   

			 \mid r^*         

\]

The language or set of strings denoted 

by regular expressions are defined as

%TODO: FILL in the other defs

\begin{center}

\begin{tabular}{lcl}

$L \; (r_1 + r_2)$ & $\dn$ & $ L \; (r_1) \cup L \; ( r_2)$\\

$L \; (r_1 \cdot r_2)$ & $\dn$ & $ L \; (r_1) \cap L \; (r_2)$\\

\end{tabular}

\end{center}

Which is also called the "language interpretation" of

a regular expression.

Now with semantic derivatives of a language and regular expressions and

their language interpretations in place, we are ready to define derivatives on regexes.

\subsection{Brzozowski Derivatives and a Regular Expression Matcher}

all strings in that set, we want to define a derivative operation on regular expressions

so that after derivative $L(r\backslash c)$ 

will look as if it was obtained by doing a language derivative on $L(r)$:

\[

L(r \backslash c) = \Der \; c \; L(r)

\]

So we mimic the equalities we have for $\Der$ on language concatenation

\[

\Der \; c \; (A @ B) = \textit{if} \;  [] \in A \; \textit{then} ((\Der \; c \; A) @ B ) \cup \Der \; c\; B \quad \textit{else}\; (\Der \; c \; A) @ B\\

\]

to get the derivative for sequence regular expressions:

\[

(r_1 \cdot r_2 ) \backslash c = \textit{if}\,([] \in L(r_1)) r_1 \backslash c \cdot r_2 + r_2 \backslash c \textit{else} (r_1 \backslash c) \cdot r_2

\]

\noindent

and language Kleene star:

\[

\]

to get derivative of the Kleene star regular expression:

\[

r^* \backslash c = (r \backslash c)\cdot r^*

\]

Note that although we can formalise the boolean predicate

$[] \in L(r_1)$ without problems, if we want a function that works

computationally, then we would have to define a function that tests

whether an empty string is in the language of a regular expression.

We call such a function $\nullable$:

\begin{center}

\begin{tabular}{lcl}

		$\ZERO \backslash c$ & $\dn$ & $\ZERO$\\  

		$\ONE \backslash c$  & $\dn$ & $\ZERO$\\

		$d \backslash c$     & $\dn$ & 

		$\mathit{if} \;c = d\;\mathit{then}\;\ONE\;\mathit{else}\;\ZERO$\\

$(r_1 + r_2)\backslash c$     & $\dn$ & $r_1 \backslash c \,+\, r_2 \backslash c$\\

$(r_1 \cdot r_2)\backslash c$ & $\dn$ & $\mathit{if} \, nullable(r_1)$\\

	&   & $\mathit{then}\;(r_1\backslash c) \cdot r_2 \,+\, r_2\backslash c$\\

	&   & $\mathit{else}\;(r_1\backslash c) \cdot r_2$\\

	$(r^*)\backslash c$           & $\dn$ & $(r\backslash c) \cdot r^*$\\

\end{tabular}

\end{center}

\noindent

The function derivative, written $r\backslash c$, 

defines how a regular expression evolves into

a new regular expression after all the string it contains

is chopped off a certain head character $c$.

The most involved cases are the sequence 

and star case.

The sequence case says that if the first regular expression

contains an empty string then the second component of the sequence

might be chosen as the target regular expression to be chopped

off its head character.

The star regular expression's derivative unwraps the iteration of

regular expression and attaches the star regular expression

to the sequence's second element to make sure a copy is retained

for possible more iterations in later phases of lexing.

The $\nullable$ function tests whether the empty string $""$ 

is in the language of $r$:

\begin{center}

		\begin{tabular}{lcl}

			$\nullable(\ZERO)$     & $\dn$ & $\mathit{false}$ \\  

			$\nullable(\ONE)$      & $\dn$ & $\mathit{true}$ \\

			$\nullable(c)$ 	       & $\dn$ & $\mathit{false}$ \\

			$\nullable(r_1 + r_2)$ & $\dn$ & $\nullable(r_1) \vee \nullable(r_2)$ \\

			$\nullable(r_1\cdot r_2)$  & $\dn$ & $\nullable(r_1) \wedge \nullable(r_2)$ \\

			$\nullable(r^*)$       & $\dn$ & $\mathit{true}$ \\

		\end{tabular}

\end{center}

\noindent

The empty set does not contain any string and

therefore not the empty string, the empty string 

regular expression contains the empty string

by definition, the character regular expression

is the singleton that contains character only,

and therefore does not contain the empty string,

the alternative regular expression (or "or" expression)

might have one of its children regular expressions

being nullable and any one of its children being nullable

would suffice. The sequence regular expression

would require both children to have the empty string

to compose an empty string and the Kleene star

operation naturally introduced the empty string. 

We have the following property where the derivative on regular 

expressions coincides with the derivative on a set of strings:

\begin{lemma}

$\textit{Der} \; c \; L(r) = L (r\backslash c)$

\end{lemma}

\noindent

The main property of the derivative operation

that enables us to reason about the correctness of

an algorithm using derivatives is 

\begin{center}

$c\!::\!s \in L(r)$ holds

if and only if $s \in L(r\backslash c)$.

\end{center}

\noindent

We can generalise the derivative operation shown above for single characters

to strings as follows:

\begin{center}

\begin{tabular}{lcl}

$r \backslash_s (c\!::\!s) $ & $\dn$ & $(r \backslash c) \backslash_s s$ \\

$r \backslash [\,] $ & $\dn$ & $r$

\end{tabular}

\end{center}

\noindent

When there is no ambiguity we will use  $\backslash$ to denote

string derivatives for brevity.

and then define Brzozowski's  regular-expression matching algorithm as:

\begin{definition}

$match\;s\;r \;\dn\; nullable(r\backslash s)$

\end{definition}

\noindent

Assuming the string is given as a sequence of characters, say $c_0c_1..c_n$, 

this algorithm presented graphically is as follows:

\begin{equation}\label{graph:successive_ders}

\begin{tikzcd}

r_0 \arrow[r, "\backslash c_0"]  & r_1 \arrow[r, "\backslash c_1"] & r_2 \arrow[r, dashed]  & r_n  \arrow[r,"\textit{nullable}?"] & \;\textrm{YES}/\textrm{NO}

\end{tikzcd}

\end{equation}

\noindent

where we start with  a regular expression  $r_0$, build successive

derivatives until we exhaust the string and then use \textit{nullable}

to test whether the result can match the empty string. It can  be

relatively  easily shown that this matcher is correct  (that is given

an $s = c_0...c_{n-1}$ and an $r_0$, it generates YES if and only if $s \in L(r_0)$).

Beautiful and simple definition.

If we implement the above algorithm naively, however,

the algorithm can be excruciatingly slow. 

\begin{figure}

\centering

\begin{tabular}{@{}c@{\hspace{0mm}}c@{\hspace{0mm}}c@{}}

\begin{tikzpicture}

\begin{axis}[

    xlabel={$n$},

    x label style={at={(1.05,-0.05)}},

    ylabel={time in secs},

    enlargelimits=false,

    xtick={0,5,...,30},

    xmax=33,

    ymax=10000,

    ytick={0,1000,...,10000},

    scaled ticks=false,

    axis lines=left,

    width=5cm,

    height=4cm, 

    legend entries={JavaScript},  

    legend pos=north west,

    legend cell align=left]

\addplot[red,mark=*, mark options={fill=white}] table {EightThousandNodes.data};

\end{axis}

\end{tikzpicture}\\

\multicolumn{3}{c}{Graphs: Runtime for matching $(a^*)^*\,b$ with strings 

           of the form $\underbrace{aa..a}_{n}$.}

\end{tabular}    

\caption{EightThousandNodes} \label{fig:EightThousandNodes}

\end{figure}

(8000 node data to be added here)

For example, when starting with the regular

expression $(a + aa)^*$ and building a few successive derivatives (around 10)

w.r.t.~the character $a$, one obtains a derivative regular expression

with more than 8000 nodes (when viewed as a tree)\ref{EightThousandNodes}.

The reason why $(a + aa) ^*$ explodes so drastically is that without

pruning, the algorithm will keep records of all possible ways of matching:

\begin{center}

$(a + aa) ^* \backslash [aa] = (\ZERO + \ONE \ONE)\cdot(a + aa)^* + (\ONE + \ONE a) \cdot (a + aa)^*$

\end{center}

\noindent

Each of the above alternative branches correspond to the match 

$aa $, $a \quad a$ and $a \quad a \cdot (a)$(incomplete).

These different ways of matching will grow exponentially with the string length,

and without simplifications that throw away some of these very similar matchings,

it is no surprise that these expressions grow so quickly.

Operations like

$\backslash$ and $\nullable$ need to traverse such trees and

consequently the bigger the size of the derivative the slower the

algorithm. 

Brzozowski was quick in finding that during this process a lot useless

$\ONE$s and $\ZERO$s are generated and therefore not optimal.

He also introduced some "similarity rules", such

as $P+(Q+R) = (P+Q)+R$ to merge syntactically 

different but language-equivalent sub-regexes to further decrease the size

of the intermediate regexes. 

More simplifications are possible, such as deleting duplicates

and opening up nested alternatives to trigger even more simplifications.

And suppose we apply simplification after each derivative step, and compose

these two operations together as an atomic one: $a \backslash_{simp}\,c \dn

\textit{simp}(a \backslash c)$. Then we can build

a matcher with simpler regular expressions.

If we want the size of derivatives in the algorithm to

stay even lower, we would need more aggressive simplifications.

Essentially we need to delete useless $\ZERO$s and $\ONE$s, as well as

delete duplicates whenever possible. For example, the parentheses in

$(a+b) \cdot c + b\cdot c$ can be opened up to get $a\cdot c + b \cdot c + b

\cdot c$, and then simplified to just $a \cdot c + b \cdot c$. Another

example is simplifying $(a^*+a) + (a^*+ \ONE) + (a +\ONE)$ to just

$a^*+a+\ONE$.  These more aggressive simplification rules are for

 a very tight size bound, possibly as low

  as that of the \emph{partial derivatives}\parencite{Antimirov1995}. 

Building derivatives and then simplifying them.

So far, so good. But what if we want to 

do lexing instead of just getting a YES/NO answer?

This requires us to go back again to the world 

without simplification first for a moment.

Sulzmann and Lu~\cite{Sulzmann2014} first came up with a nice and 

elegant(arguably as beautiful as the original

derivatives definition) solution for this.

\subsection*{Values and the Lexing Algorithm by Sulzmann and Lu}

They first defined the datatypes for storing the 

lexing information called a \emph{value} or

sometimes also \emph{lexical value}.  These values and regular

expressions correspond to each other as illustrated in the following

table:

\begin{center}

	\begin{tabular}{c@{\hspace{20mm}}c}

		\begin{tabular}{@{}rrl@{}}

			\multicolumn{3}{@{}l}{\textbf{Regular Expressions}}\medskip\\

			$r$ & $::=$  & $\ZERO$\\

			& $\mid$ & $\ONE$   \\

			& $\mid$ & $c$          \\

			& $\mid$ & $r_1 \cdot r_2$\\

			& $\mid$ & $r_1 + r_2$   \\

			\\

			& $\mid$ & $r^*$         \\

		\end{tabular}

		&

		\begin{tabular}{@{\hspace{0mm}}rrl@{}}

			\multicolumn{3}{@{}l}{\textbf{Values}}\medskip\\

			$v$ & $::=$  & \\

			&        & $\Empty$   \\

			& $\mid$ & $\Char(c)$          \\

			& $\mid$ & $\Seq\,v_1\, v_2$\\

			& $\mid$ & $\Left(v)$   \\

			& $\mid$ & $\Right(v)$  \\

			& $\mid$ & $\Stars\,[v_1,\ldots\,v_n]$ \\

		\end{tabular}

	\end{tabular}

\end{center}

\noindent

Building on top of Sulzmann and Lu's attempt to formalise the 

notion of POSIX lexing rules \parencite{Sulzmann2014}, 

Ausaf and Urban\parencite{AusafDyckhoffUrban2016} modelled

POSIX matching as a ternary relation recursively defined in a

natural deduction style.

With the formally-specified rules for what a POSIX matching is,

they proved in Isabelle/HOL that the algorithm gives correct results.

But having a correct result is still not enough, 

we want at least some degree of $\mathbf{efficiency}$.

One regular expression can have multiple lexical values. For example

for the regular expression $(a+b)^*$, it has a infinite list of

values corresponding to it: $\Stars\,[]$, $\Stars\,[\Left(Char(a))]$,

$\Stars\,[\Right(Char(b))]$, $\Stars\,[\Left(Char(a),\,\Right(Char(b))]$,

$\ldots$, and vice versa.

Even for the regular expression matching a particular string, there could 

be more than one value corresponding to it.

Take the example where $r= (a^*\cdot a^*)^*$ and the string 

$s=\underbrace{aa\ldots a}_\text{n \textit{a}s}$.

If we do not allow any empty iterations in its lexical values,

there will be $n - 1$ "splitting points" on $s$ we can choose to 

split or not so that each sub-string

segmented by those chosen splitting points will form different iterations:

\begin{center}

\begin{tabular}{lcr}

$a \mid aaa $ & $\rightarrow$ & $\Stars\, [v_{iteration \,a},\,  v_{iteration \,aaa}]$\\

$aa \mid aa $ & $\rightarrow$ & $\Stars\, [v_{iteration \, aa},\,  v_{iteration \, aa}]$\\

$a \mid aa\mid a $ & $\rightarrow$ & $\Stars\, [v_{iteration \, a},\,  v_{iteration \, aa}, \, v_{iteration \, a}]$\\

 & $\textit{etc}.$ &

 \end{tabular}

\end{center}

And for each iteration, there are still multiple ways to split

between the two $a^*$s.

It is not surprising there are exponentially many lexical values

that are distinct for the regex and string pair $r= (a^*\cdot a^*)^*$  and 

$s=\underbrace{aa\ldots a}_\text{n \textit{a}s}$.

A lexer to keep all the possible values will naturally 

have an exponential runtime on ambiguous regular expressions.

Somehow one has to decide which lexical value to keep and

output in a lexing algorithm.

In practice, we are usually 

interested in POSIX values, which by intuition always

\begin{itemize}

\item

match the leftmost regular expression when multiple options of matching

are available  

\item 

always match a subpart as much as possible before proceeding

to the next token.

\end{itemize}

The formal definition of a $\POSIX$ value $v$ for a regular expression

$r$ and string $s$, denoted as $(s, r) \rightarrow v$, can be specified 

in the following set of rules:

(TODO: write the entire set of inference rules for POSIX )

\newcommand*{\inference}[3][t]{%

   \begingroup

   \def\and{\\}%

   \begin{tabular}[#1]{@{\enspace}c@{\enspace}}

   #2 \\

   \hline

   #3

   \end{tabular}%

   \endgroup

}

\begin{center}

\inference{$s_1 @ s_2 = s$ \and $(\nexists s_3 s_4 s_5. s_1 @ s_5 = s_3 \land s_5 \neq [] \land s_3 @ s_4 = s \land (s_3, r_1) \rightarrow v_3 \land (s_4, r_2) \rightarrow v_4)$ \and $(s_1, r_1) \rightarrow v_1$ \and $(s_2, r_2) \rightarrow v_2$  }{$(s, r_1 \cdot r_2) \rightarrow \Seq(v_1, v_2)$ }