Thursday, December 18, 2014

Compiling regular expressions (I)

This post picks up from here which was concerned with parsing - obtaining representations of regular expressions as abstract syntax trees. The ultimate goal is, given a string representation of a regular expression $e$ , produce a 'recognizer' for the expression (referred to as compiling a regular expression). That is, a function string -> bool  that can be used to categorize strings as either belonging to the language $\mathcal{L_{e}}$ or not.

Having produced an abstract syntax tree for a regular expression $e$, the first step in compiling the expression is to compute an abstract syntax tree of the corresponding augmented regular expression $(e)\#$. This augmented regular expression is the original expression $e$ concatenated with a unique end-marker $\#$. For the given expression $e$, the accepting state for $e$ is given a transition on $\#$. This is a device that allows us to "forget" about accepting states as the computation of a recognizer proceeds; when the construction is complete, any state with a transition on $\#$ must be an accepting state.

Leaves in the abstract syntax tree of the augmented regular expression $(e)\#$ are labeled by $\epsilon$ or a symbol from from $\mathcal{A}$. For those non-$\epsilon$ leaves we attach a unique integer. Accordingly, we will need functions to generate unique integers (positions) that we will employ as we transform the AST of $e$ into the AST of the augmented expression $(e)\#$ leading to our first code example.

let reset_label, generate_label =
let r = ref (-1) in
((fun () -> r := (-1)), (fun () -> r := !r + 1; !r))


As we construct the syntax tree of the $(e)\#$ we compute four functions : null_pos, first_pos, last_pos and following:

1. null_pos is $true$ for a syntax-tree node $n$ if and only if the sub-expression represented by $n$ has $\epsilon$ in its language. That is, $true$ if the regular sub-expression recognizes the empty string and $false$ otherwise;
2. first_pos is the set of positions in the sub-tree rooted at $n$ that correspond to the first symbol of at least one string in the language of the sub-expression rooted at $n$. That is, the set of symbols that can begin a string recognized by the regular sub-expression;
3. last_pos is the set of positions in the sub-tree rooted at the syntax-tree node $n$ that corresponds to the last symbol of at least one string in the language of the sub-expression rooted at $n$. That is, the set of symbols that can terminate a string recognized by the regular sub-expression;
4. following, for a position $p$ is the set of positions $q$ in the entire syntax-tree such that there is some string $x = a_{1}a_{2} \cdots a_{n}$ in $\mathcal{L_{(e)\#}}$ such that for some $i$, there is some way to explain the membership of $x$ in $\mathcal{L_{(e)\#}}$ by matching $a_{i}$ to $p$ and $a_{i + 1}$ to a position in $q$.
Of these, following is the last to compute as it relies upon the values of first_pos and last_pos. If the definition is confusing for now, don't worry about it. The rules for computing following will come later and will be obvious at that point. We'll focus for now on null_pos, first_pos and last_pos.

The results of first_pos, last_pos and follow are sets of integers. Accordingly, we are going to need a type to represent these.

module Int_set : Set.S with type elt = int = Set.Make (
struct
let compare = Pervasives.compare
type t = int
end)

With this we can present the type of ASTs for augmented regular expressions.
type augmented_regexp =
| Epsilon
| Character of char * int
| Sequence of augmented_regexp * augmented_regexp * pos
| Alternative of augmented_regexp * augmented_regexp * pos
| Repetition of augmented_regexp * pos
| Accept of int
and pos = {
null:bool;
first:Int_set.t;
last:Int_set.t;
}


For a given node $n$, the values of its pos record depend only on the sub-expressions of that node. Assuming constructed augmented regular expression syntax trees, we can write null_pos, first_pos and last_pos like this.

let (null_pos : augmented_regexp -> bool)  =
fun x ->
match x with
| Epsilon -> true
| Character (_, i) -> false
| Sequence (_, _, p) -> p.null
| Alternative (_, _, p) -> p.null
| Repetition (_, p) -> p.null
| Accept _ -> false

let (first_pos : augmented_regexp -> Int_set.t) =
fun x ->
match x with
| Epsilon -> Int_set.empty
| Character (_, i) -> Int_set.add i (Int_set.empty)
| Alternative (_, _, p) -> p.first
| Repetition (_, p) -> p.first
| Sequence (_, _, p) -> p.first
| Accept i -> Int_set.add i (Int_set.empty)

let (last_pos : augmented_regexp -> Int_set.t) =
fun x ->
match x with
| Epsilon -> Int_set.empty
| Character (_, i) -> Int_set.add i (Int_set.empty)
| Alternative (_, _, p) -> p.last
| Repetition (_, p) -> p.last
| Sequence (_, _, p) -> p.last
| Accept i -> Int_set.add i (Int_set.empty)


Our strategy in building the syntax-tree of $(e)\#$ from the syntax tree of $e$ will be to visit each node of $e$ and invoke a function to construct the corresponding node of $(e)\#$ inductively. These functions will include the generation of unique integers for the non-$\epsilon$ leaves and encode the rules for building the pos records:

• null
• Sequence $(e_{1}, e_{2})$ : null_pos $e_{1}$ and null_pos $e_{2}$
• Alternative $(e_{1}, e_{2})$ : null_pos $e_{1}$ or null_pos $e_{2}$
• Repetition : $true$
• first
• Alternative $(e_{1}, e_{2})$ : first_pos $e_{1} \cup$ first_pos $e_{2}$
• Sequence $(e_{1}, e_{2})$ : if null_pos $e_{1}$ then first_pos $e_{1} \cup$ first_pos $e_{2}$ else first_pos $e_{1}$
• Repetition $e$ : first_pos $e$
• last
• Alternative $(e_{1}, e_{2})$ : last_pos $e_{1} \cup$ last_pos $e_{2}$
• Sequence $(e_{1}, e_{2})$ : if null_pos $e_{2}$ then last_pos $e_{1} \cup$ last_pos $e_{2}$ else last_pos $e_{2}$
• Repetition $e$ : last_pos $e$

Here then are the augmented regular expression syntax-tree node constructor functions.

let (epsilon : unit -> augmented_regexp) =
fun () ->
Epsilon

and (character : char -> augmented_regexp) =
fun c ->
Character (c, generate_label ())

and (repetition : augmented_regexp -> augmented_regexp) =
fun e ->
Repetition (e, {null=true;first=first_pos e; last=last_pos e})

and (alternative : augmented_regexp -> augmented_regexp -> augmented_regexp)  =
fun e1 e2 ->
Alternative (e1, e2,
{null=null_pos e1 || null_pos e2;
first=Int_set.union (first_pos e1)(first_pos e2);
last=Int_set.union (last_pos e1) (last_pos e2)})

and (sequence : augmented_regexp -> augmented_regexp -> augmented_regexp) =
fun e1 e2 ->
let b1 = null_pos e1
and b2 = null_pos e2 in
Sequence (e1, e2,
{null=b1 && b2;
first=
if b1 then
Int_set.union (first_pos e1)(first_pos e2)
else
first_pos e1;
last=
if b2 then
Int_set.union (last_pos e1) (last_pos e2)
else
last_pos e2})

let (accept : augmented_regexp -> augmented_regexp) =
fun e ->
sequence e (Accept (generate_label ()))


We are now in a position to write the function that transforms a syntax tree of the regular expression $e$ into the syntax tree of the augmented regular expression $(e)\#$.

let rec (augmented_regexp : Syntax.regular_expression -> augmented_regexp) =
fun x ->
match x with
| Syntax.Epsilon -> epsilon ()
| Syntax.Character i ->  character (Char.chr i)
| Syntax.Sequence (x, y) ->
(*Be very careful here. Evaluation order matters!*)
let x' = (augmented_regexp x)
and y' = (augmented_regexp y) in
sequence x' y'
| Syntax.Alternative (x, y) ->
(*Be very careful here. Evaluation order matters!*)
let x' = (augmented_regexp x)
and y' = (augmented_regexp y) in
alternative x' y'
| Syntax.Repetition x -> repetition (augmented_regexp x)

We can wrap all of the above up in a convenience function parse_augmented_regexp which first parses a string to build the syntax tree of the regular expression it represents and then transforms the result into the syntax tree of the corresponding augmented regular expression.

let (parse_augmented_regexp : string-> augmented_regexp * int)  =
fun s ->
let () = reset_label () in
let ast = regexp_of_string s in
let re1 = augmented_regexp ast in
let re2 = accept re1 in
let count = generate_label () in
(re2, count)

Notice that this function returns a pair of the syntax-tree and the number of positions it contains.

The next step in compiling a recognizer from the expression $(e)\#$ is to compute the follow function. To do this we "unite" the information encoded by the first_pos and last_pos functions. Put plainly, follow is a function that takes each symbol (position) in the regular expression to the (set of) symbols (positions) that can follow it. The information is stored in an array of length equal to the number of symbols appearing in the regular expression. There are only two ways a position in a regular expression can follow another:

• If $n$ is a Sequence node with left child $c_{1}$ and right child $c_{2}$, then for every position $i$ in lastpos $c_{1}$, all positions in firstpos $c_{2}$ are in follow_pos $c_{i}$
• If $n$ is a Repition and $i$ a position in lastpos $n$, then all positions in first_pos $n$ are in follow_pos $i$
In addition to computing follow the code below also stores the association between positions and characters of the regular expression. That information goes into an array. The elements of the array have type char option since the Accept symbol has a position but no character associated with it.
let (compute_follow : Int_set.t array -> char option array -> augmented_regexp -> unit) =
fun follow chars x ->
let rec compute x =
match x with
| Sequence (e1, e2, p) ->
compute e1; compute e2;
let first2 = first_pos e2 in
let f i =
follow.(i) <- Int_set.union first2 (follow.(i)) in
Int_set.iter f (last_pos e1)
| Repetition (e, p) ->
compute e;
let f i =
follow.(i) <- Int_set.union (p.first) (follow.(i)) in
Int_set.iter f (p.last)
| Alternative (e1, e2, p) -> compute e1; compute e2
| Epsilon -> ()
| Accept i -> chars.(i) <- None
| Character (c, i) -> chars.(i) <- Some c in
compute x


Now the computation of the augmented regular expression syntax-tree and all four of the associated functions together with the mapping from positions to symbols of $\mathcal{A}$ can be wrapped up in another "high-level" convenience function.

let (regexp_follow : string -> augmented_regexp * Int_set.t array * char option array) =
fun s ->
let re, n = parse_augmented_regexp s in
let follow = Array.make n (Int_set.empty) in
let chars = Array.make n None in
(re, follow, chars)


We're in good shape - but a hop, skip and a jump to computing a recognizer from a regular expression. We'll leave off here on this local maxima for today and finish off the job in the next post!

Saturday, December 13, 2014

Recognizers

In my last post, I gave an OCaml program to parse regular expressions. I intend however to show you, over the coming weeks, not just how to parse them, but how to compile them to recognizers too. Doing so will require me to share quite a lot of code that I gleaned from the book The Functional Approach to Programming by Guy Cousineau and Michel Mauny from which I learned how to do this. In doing so, I will along the way, provide updated code in modern OCaml as the book is presented in the Caml language a predecessor of today's OCaml, and not everywhere equivalent. Additionally, there will be functions of my own "filling in" gaps left as exercises in the book. That said, I don't think there's enough effort of my own to justify "plagiarizing" the material so blatantly so am determined to add at least a little value, where my limited skills allow, in order that I might redeem myself.

So today, let us start with a minimal combinator library implementing "recognizers" for recursive descent parsers, based on Cousineau and Mauny transliterated to the C++ programming language. I hope on reading the following, that you will agree, the multi-paradigm language C++-11 admits "The Functional Approach to Programming" as a "first class citizen" and the result here might be viewed as the beginning of a mini Boost.Spirit! Let's begin.

We are concerned with the problem of "recognizing" phrases belonging to a given language. We will produce programs (functions) that accept character strings as input which decide to accept or reject them. First some headers.

#include <boost/variant.hpp>
#include <boost/variant/apply_visitor.hpp>
#include <boost/utility.hpp>
#include <boost/range.hpp>
#include <boost/detail/lightweight_test.hpp>

#include <list>
#include <functional>
#include <numeric>
#include <string>


Recognizers work on lists. When recognition succeeds, part of the list is consumed and the part of the list remaining is returned or, recognition fails. So the type remaining<A> is a sum type with two cases, where A is the type of "tokens" (symbols) contained by the list (typically but not necessarily char).

//Recognition succeeded
template <class A>
struct remains{
std::list<A> left;
template <class ItT>
remains (ItT begin, ItT end)
: left (begin, end)
{}
};

//Recognition failed
template <class A>
struct recognition_fails {};

//Result of a recognizer. Indicates the result of attempting to
//recognize something from a list
template <class A> using remaining =
boost::variant<remains <A>, recognition_fails<A> >;

Recognizers then are but functions from lists of tokens to values of remaining<A>.
//A 'recognizer' is a function from a list to a value of remaining<A>
template <class A> using recognizer =
std::function<remaining<A>(std::list<A> const&)>;

Here's an example. This function (constant) produces a recognizer that matches the empty string. The recognizer it produces always succeeds and never consumes any input.
//A recognizer that recognizes the empty string. It always succeeds and
//no input is ever consumed
template <class A>
recognizer<A> epsilon ()
{
return [](std::list<A> const& cs) -> remaining<A>
{
return remains<A> (cs.begin (), cs.end ());
};
}

This next factory function produces recognizers that recognize elements that satisfy a user provided predicate.
//Given a predicate, 'recognizer_of_token' produces the recognizer
//associated with the elements that satisfy this predicate
template <class A, class F/*bool(A)*/>
recognizer<A> recognizer_of_token (F test)
{
return
[=] (std::list<A> const& cs) -> remaining<A>
{
if (cs.empty ())
return recognition_fails<A> ();

if (test (cs.front ()))
return remains<A> (boost::next (cs.begin()), cs.end());

return recognition_fails<A>();
};
}

Recognizers can be composed. This function takes two recognizers and returns a recognizer that will, when presented with a list of tokens, attempt recognition via the first and if that doesn't work out, backtrack and attempt to recognize via the second. It's the "if then else" of recognizers.
//Recognizer disjunction
template <class A>
recognizer<A> compose_or (recognizer<A> p, recognizer<A> q)
{
return [=](std::list<A> const& toks) -> remaining<A>
{
remaining <A> res = p (toks);
if (remains<A>* rem = boost::get<remains<A> >(&res)) return *rem;

return q (toks);
};
}

This next function is the builder of the corresponding "and then" sort of recognizer.
//Recognizer conjunction
template <class A>
recognizer<A> compose_and (recognizer<A> p, recognizer<A> q)
{
return [=](std::list<A> const& toks) -> remaining<A>
{
remaining <A> res = p (toks);
if (remains<A>* rem = boost::get<remains<A> >(&res))
return q (rem->left);

return recognition_fails<A> ();
};
}

With disjunction and conjunction of recognizers, we can implement a function to compute, given a recognizer, the corresponding Kleene star recognizer. That is, zero or more occurrences of a given phrase.
//The '*' iterator (Kleene star)
template <class A>
recognizer<A> zero_or_more (recognizer<A> p)
{
return [=] (std::list<A> const& toks) -> remaining <A>
{
return compose_or (
compose_and (p, zero_or_more<A> (p)) , epsilon<A> ()) (toks);
};
}

Well, let's now get concrete. Here's a function to produce a recognizer of a specific token.
//A function to produce a recognizer that recognizes only the
//given character
template <A>
recognizer<A> char_ (A c)
{
return recognizer_of_token<A>([=](A x) -> bool { return c == x; });
}

The composite recognizer for a given "string" of tokens can be constructed then like this.
//A function to produce a recognizer of a specific string
template <class C>
recognizer<typename boost::range_value<C>::type> string_ (C s)
{
typedef typename boost::range_value<C>::type value;

std::list <recognizer<value> > rs;

typedef std::back_insert_iterator<std::list<recognizer<value> > > it_t;

std::accumulate (
boost::begin (s)
, boost::end (s)
, std::back_inserter (rs)
, [](it_t dst, value c) -> it_t
{ *dst++ = char_ (c); return dst; });

return std::accumulate (
boost::next (rs.begin ())
, rs.end ()
, rs.front ()
, [](recognizer<value> acc, recognizer<value> r) -> recognizer<value>
{ return compose_and (acc, r); });
}

That will do for our mini-recognizer library for today. Let's turn attention to testing. First some utilities.
//Match on a remaining<A> returns 'true' if it contains a 'remains<A>'
//value with all input consumed, 'false' if it contains a 'recognition_fails<A>' value
template <class A>
struct accept_visitor
{
typedef bool result_type;
bool operator () (remains<A> const& r) const { return r.left.empty (); }
bool operator () (recognition_fails<A> const& r) const { return false; }
};

//Function to determine if recognition was achieved
template <class A>
bool accept (remaining<A> const& r)
{
return boost::apply_visitor( accept_visitor<A> (), r);
}

//Test if the provided recognizer can recognize the given string
bool parse (recognizer<char> parser, std::string const& s)
{
return accept (parser (std::list<char>(s.begin (), s.end())));
}

Now, a little test.
int main ()
{
//char_
BOOST_TEST( parse (char_ ('a'), "a") );
BOOST_TEST( !parse (char_ ('b'), "a") );
BOOST_TEST( parse (char_ ('b'), "b") );

//'*'
BOOST_TEST( parse (zero_or_more (char_ ('a')), "aa") );
BOOST_TEST( parse (zero_or_more (char_ ('a')), "") );
BOOST_TEST( !parse (zero_or_more (char_ ('a')), "ab") );

//string_
BOOST_TEST (parse (string_ (std::string ("foo")), "foo") );
BOOST_TEST (!parse (string_ (std::string ("foo")), "bar") );

return boost::report_errors ();
}

Et voilĂ . L' approche fonctionnelle de C++! See you soon for more about regular expressions. Happy holidays!

Sunday, December 7, 2014

Parsing regular expressions

Here's a brief refresher on regular expressions derived from Cosineau and Mauny.

Given an alphabet $\mathcal{A}$, a regular expression $e$ over $\mathcal{A}$ is a concise way to describe a set $\mathcal{L}$ of strings of elements of $\mathcal{A}$. The set $\mathcal{L}_{e}$ denoted by an expression $e$ is termed the regular language denoted by $e$.

In their most basic form, regular expressions can be defined like this:

• $\epsilon$ represents the set $\mathcal{L}_{\epsilon} = \left\{\epsilon\right\}$ containing only the empty string
• A symbol $c$ of $\mathcal{A}$ denotes $\mathcal{L}_{c} = \left\{c\right\}$
• $e_{1}e_{2}$ is the set $\mathcal{L}_{e_{1}}\cdot\mathcal{L}_{e_{2}} = \left\{s_{1}s_{2} | s_{1} \in \mathcal{L}_{e_{1}}, s_{2} \in \mathcal{L}_{e_{2}}\right\}$
• $e_{1}|e_{2}$ is the set $\mathcal{L}_{e_{1}}\bigcup \mathcal{L}_{e_{2}}$
• $e^{*}$ is the union $\bigcup_{i=0}^{\infty}\mathcal{L}_{e}^{i}$ where $\mathcal{L}_{e}^{0} = \mathcal{L}_{\epsilon}$ and $\mathcal{L}_{e}^{i} = \mathcal{L}_{e}^{i-1}\cdot\mathcal{L}_{e}$
This last operator $*$ is called the Kleene closure operator and $e^{*}$ equivalent to the infinite regular expression $\epsilon|e|ee|eee|\dots$

Regular expressions provide a convenient syntax for searching plain text data for lines matching specific patterns as demonstrated by the venerable Unix function 'grep' (I was taught grep is an acronym for generalized regular expression pattern-matching). To produce a function like grep requires a program for analyzing a regular expression $e$ and computing a recognizer for $\mathcal{L}_{e}$, that is a function string -> bool, that can be used to classify a string $s$ (say) in terms of whether or not $s \in \mathcal{L}_{e}$. This procedure of computing a recognizer for $\mathcal{L}_{e}$ from $e$ is called compiling a regular expression.

Writing a regular expression compiler is not for the faint-of-heart! Doing so requires more work than can be reasonably described in one blog-post so here, I'll focus only on the first part - parsing a regular expression. That is, given a string $s$ a program to produce an abstract syntax tree describing the regular expression $e$ represented by $s$.

To begin, we define the type of regular expressions.

type regular_expression =
| Epsilon
| Character of int
| Sequence of regular_expression * regular_expression
| Alternative of regular_expression * regular_expression
| Repetition of regular_expression

We could proceed from here by hand-crafting a recursive descent parser or we might take advantage of a parser generator system like ocamllex/ocamlyacc which is the choice I favored. On reaching that decision it occurred to me that, since ocamllex itself treats regular expressions as inputs, the source code for ocamllex itself might contain a suitable grammar for the expression type above and indeed it does! Things at this point become marvelously recursive - to build a regular expression compiler we can bootstrap (at both the source and binary levels) from an existing regular expression compiler (which itself is a bootstrap by the way)!

The code that follows is an adaptation of the parser and lexer input files for ocamllex (the copyright of Xavier Leroy).

/*parser.mly*/

%{
open Syntax
%}

%token <int> Tchar

%token Tend Tor Tlbracket Trbracket
%token Tstar Tmaybe Tplus Tlparen Trparen

%left Tor
%nonassoc CONCAT
%nonassoc Tmaybe Tstar Tplus
%nonassoc Tchar Tlbracket Tlparen

%start main
%type <Syntax.regular_expression> main
%%

main:
| regexp Tend
{ $1 } ; regexp: | Tchar { Character$1 }
| regexp Tstar
{ Repetition $1 } | regexp Tmaybe { Alternative (Epsilon,$1) }
| regexp Tplus
{ Sequence (Repetition ($1),$1)}
| regexp Tor regexp
{ Alternative ($1,$3) }
| regexp regexp %prec CONCAT
{ Sequence ($1,$2) }
| Tlparen regexp Trparen