Matchers and grammars using tree regular expressions

Latest on Hackage:

This package is not currently in any snapshots. If you're interested in using it, we recommend adding it to Stackage Nightly. Doing so will make builds more reliable, and allow stackage.org to host generated Haddocks.

BSD3 licensed by Alejandro Serrano
Maintained by A.SerranoMena@uu.nl

t-regex: matchers and grammars using tree regular expressions

t-regex defines a series of combinators to express tree regular expressions over any Haskell data type. In addition, with the use of some combinators (and a bit of Template Haskell), it defines nice syntax for using this tree regular expressions for matching and computing attributes over a term.

Defining your data type

In order to use t-regex, you need to define you data type in a way amenable to inspection. In particular, it means that instead of a closed data type, you need to define a pattern functor in which recursion is described using the final argument, and which should instantiate the Generic1 type class (this can be done automatically if you are using GHC).

For example, the following block of code defines a Tree' data type in the required fashion:

{-# LANGUAGE DeriveGeneric #-}
import GHC.Generics

data Tree' f = Leaf'
             | Branch' { elt :: Int, left :: f, right :: f }
             deriving (Generic1, Show)

Notice the f argument in the place where Tree' would usually be found. In addition, we have declared the constructors using ' at the end, but we will get rid of them soon.

Now, if you want to create terms, you need to close the type, which essentially makes the f argument refer back to Tree'. You do so by using Fix:

type Tree = Fix Tree'

However, this induces the need to add explicit Fix constructors at each level. To alleviate this problem, let's define pattern synonyms, available from GHC 7.8 on:

pattern Leaf = Fix Leaf'
pattern Branch n l r = Fix (Branch' n l r)

From an outsider point of view, now your data type is a normal one, with Leaf and Branch as its constructors:

aTree = Branch 2 (Branch 2 Leaf Leaf) Leaf

Tree regular expressions

Tree regular expressions are parametrized by a pattern functor: in this way they are flexible enough to be used with different data types, while keeping our loved Haskell type safety.

The available combinators to build regular expressions follow the syntax of Tree Automata Techniques and Applications, Chapter 2.


The expressions empty_ and none do not match any value. They can be used to signal an error branch on an expressions.

Whole language

You can match any possible term using any_. It is commonly use in combination with capture to extract information from a term.


A regular expression of the form r1 <||> r2 tries to match r1, and if it not possible, it tries to do so with r2. Note than when capturing, the first regular expression is given priority.


Of course, at some point you would like to check whether some term has a specific shape. In our case, this means that it has been constructed in some specific way. In order to do so, you need to inject the constructor as a tree regular expression. When doing so, you can use the same syntax as usual, but where at the recursive positions you write regular expressions again.

Let's make it clearer with an example. In our initial definition we had a constructor Branch' with type:

Branch' :: Int -> f -> f -> Tree' f

Once you inject it using inj, the resulting constructor becomes:

inj . Branch' :: Int -> Regex' c f -> Regex c' f -> Tree' (Regex' c f)

Notice that fields with no f do not change their type. Now, here is how you would represent a tree whose top node is a 2:

topTwo = inj (Branch' 2 any_ any_)

In some cases, you don't want to check the value of a certain position which is not recursive. In that case, you cannot use any_, since we are not talking about the type being built upon. For that case, you may use the special value __.

For example, here is how you would represent the shape of a tree which has at least one branch point:

someBranching = inj (Branch' __ any_ any_)

Iteration and concatenation

Iteration in tree regular expressions is not as easy as in word languages. The reason is that iteration may occur several times, and in different positions. For that reason, we need to introduce the notion of hole: a hole is a placeholder where iteration takes place.

In t-regex hole names are represented as lambda-bound variables. Then, you can use any of the functions square, var or # to indicate a position where the placeholder should be put. Iteration is then indicated by a call to iter or its post-fix version ^*.

The following two are ways to indicate a Tree where all internal nodes include the number 2:

{-# LANGUAGE PostfixOperators #-}

regex1 = Regex $
           iter $ \k ->
                  inj (Branch' 2 (square k) (square k))
             <||> inj Leaf'

regex2 = Regex $ ( (\k -> inj (Branch' 2 (k#) (k#)) <||> inj Leaf')^* )

Notice that the use of PostfixOperators enables a much terse language.

Iteration is an instance of a more general construction called concatenation, where a hole in an expression is filled by another given expression. The general shape of those are:

(\k -> ... (k#) ...) <.> r  -- k is replaced by r in the first expression

Matching and capturing

You can check whether a term t is matched by a regular expression r by simply using:

r `matches` t

However, the full power of tree regular expression come at the moment you start capturing subterms of your tree. A capture group is introduced in a expression by either capture or <<-, and all of them appearing in a expression should be from the same type. For example, we can refine the previous regex2 to capture leaves:

regex2 = Regex $ ( (\k -> inj (Branch' 2 (k#) (k#)) <||> "leaves" <<- inj Leaf')^* )

To check whether a term matches a expression and capture the subterms, you need to call match. The result is of type Maybe (Map c (m (Fix f))). Let's see what it means:

  • The outermost Maybe indicates whether the match is successful or not. A value of Nothing indicates that the given term does not match the regular expression,
  • Capture groups are returned as a Map, whose keys are those given at capture or <<-. For that reason, you need capture identifiers to be instances of Ord,
  • Finally, you have a choice about how to save the found subterms, given by the Alternative m. Most of the time, you will make m = [], which means that all matches of the group will be returned as a list. Other option is using m = Maybe, where only the first match is returned.

Tree regular expression patterns

Capturing is quite simple, but comes with a problem: it becomes easy to mistake the name of a capture group, so your code becomes quite brittle. For that reason, t-regex includes matchers which you can use at the same positions where pattern matching is usually done, and which take care of linking capture groups to variable names, making it impossible to mistake them.

To use them, you need to import Data.Regex.TH. Then, a quasi-quoter named rx is available to you. Here is an example:

{-# LANGUAGE QuasiQuotes #-}

example :: Tree -> [Tree]
example [rx| (\k -> inj (Branch' 2 (k#) (k#)) <||> leaves <<- inj Leaf')^* |]
           = leaves
example _  = []

The name of the capture group, leaves, is now available in the body of the example function. There is no need to look inside maps, this is all taken care for you.

Note that when using the rx quasi-quoter, you have no choice about the Alternative m to use when matching. Instead, you always get as value of each capture group a list of terms.

For those who don't like using quasi-quotation, t-regex provides a less magical version called with. In this case, you need to introduce the variables in a explicit manner, and then pattern match on a tuple wrapped inside a Maybe. The previous example would be written as:

{-# LANGUAGE ViewPatterns #-}

example :: Tree -> [Tree]
example with (\leaves -> Regex $ iter $ \k -> inj (Branch' 2 (k#) (k#))
                                              <||> leaves <<- inj Leaf' )
             -> Just leaves
           = leaves
example _  = []

Notice that the pattern is always similar with (\v1 v2 ... -> regular expression) -> Just (v1,v2,...).

Random generation

You can use t-regex to generate random values of a type which satisfy a certain tree regular expression. Of course, you might always generate random values and then check that they match the given expression, but this is usually very costly and maybe even statistically impossible. Instead, you should use arbitraryFromRegex.

instance Arbitrary Tree where
  arbitrary = frequency
    [ (1, return Leaf)
    , (5, Branch <$> arbitrary <*> arbitrary <*> arbitrary) ]

> arbitraryFromRegex regex2

Note that in the previous example we also gave an instance declaration for Arbitrary. This class comes from the QuickCheck package, and is needed to generate unconstrained random values for the case in which any_ is found.

Sometimes you may not be able or want to write such an instance. In that case, you can use arbitraryFromRegexAndGen, which takes an additional argument from which any_ values are generated.

Attribute grammars

Attribute grammars are a powerful way to perform computations over a term. The main idea is that each node in your term (when seen as a tree) is traversed, and two sets of information are recorded at each point:

  • Inherited attributes go from parent to children. When describing a grammar, each node needs to specify the value of inherited attributes of all their children,
  • Synthesized attributes flow in the other direction. At each node, you need to described how to get the value of each synthesized attribute based on your inherited attributes and the synthesized attributes of children.

The most performant attribute grammar compilers, such as UUAGC only allow deciding which rule to apply on a node depending on their topmost constructor. With t-regex you can look as deep as you want to take this decision (but of course, performance will suffer if you do this very often).

Here is an example of a grammar which computes a graphical representation of a Tree plus its number of leaves:

grammar = [
    rule $ \l r ->
     inj (Branch' 2 (l <<- any_) (r <<- any_)) ->> do
       (lText,lN) <- use (at l . syn)
       (rText,rN) <- use (at r . syn)
       this.syn._1 .= "(" ++ lText ++ ")-SPECIAL-(" ++ rText ++ ")"
       this.syn._2 .= lN + rN
  , rule $ \l r ->
     inj (Branch' __ (l <<- any_) (r <<- any_)) ->>> \(Branch e _ _) -> do
       check $ e >= 0
       (lText,lN) <- use (at l . syn)
       (rText,rN) <- use (at r . syn)
       this.syn._1 .= "(" ++ lText ++ ")-" ++ show e ++ "-(" ++ rText ++ ")"
       this.syn._2 .= lN + rN
  , rule $ inj Leaf' ->> do
       this.syn._1 .= "leaf"
       this.syn._2 .= Sum 1

Let's dissect it part by part.

First of all, a grammar is made of a series of rules. Each rule follows the same schema:

rule $ \v1 ... vn ->
  regular expression ->> do

rule is the constant part which prefixes every rule. Then, you have the set of variables which will be used to capture information from the term, in a similar way to previous section. After that you have the tree regular expression the term needs to match. Finally, and separated by ->>, you find the actions to perform when this rule is selected.

Two small extensions are shown in the second rule. By default, ->> does not give you access to the matched term. However, if you need to access some of its information (for example, because you used __, as in this case), you can use the alternative version ->>> which gives this as an argument. The second extension is the use of check to pinpoint a logical condition which is not captured by the regular expression itself.

The syntax for the actions relies heavily in lenses and operators from the lens package. In particular, you have four lenses:

  • this.inh gives access to the inherited attributes of the node,
  • at n . syn gives access to the synthesized attributes of children,
  • this.syn is where you set the synthesized attributes of your node,
  • at n . inh is where you set the inherited attributes of children,

Furthermore, you can combine those with lenses over your inherited and synthesized attribute data type to have more lightweight syntax. In our case, the synthesized attributes are a tuple (String, Sum Int), so we access them with _1 and _2, as shown in the example.

The general rule is that you read values using use, and set values via .=. If some value is not set, it defaults to the empty element of your synthesized type, or to the value of parent node in the case of inherited attributes.

comments powered byDisqus