# Maude Tools:Order-sorted Term Patterns

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

## Introduction

This page introduces the Maude Order-sorted Pattern Tool. The tool has two primary functions:

1. Given an order-sorted signature and a sort, it can check if the sort is finite or empty. Further, it can generate the set of all terms inside a finite sort.
2. Given an order-sorted signature and an order-sorted pattern (syntax shown below), it can—in many cases—discover a finite union of terms equivalent to the given pattern, if it exists.

Order-sorted term patterns are a simple notation for describing unions, intersections, and differences of sets of terms generated by an order-sorted signature.

Our tool transforms general patterns into finite unions by interpreting intersection as unification and difference as an application of our order-sorted symbolic difference algorithm.

### Example Patterns

Suppose t1, t2, and t3 are terms in an order-sorted signature. Then:

1. {t1} U {t2} U {t3} is the pattern representing the union of instances these terms.
2. {t1} - {t2} is the pattern representing the instances of t1 that are not instances of t2.
3. ({t1} U {t2}) & {t3} is the pattern representing the intersection of instances of t1 and t2 with t3.
4. mt is the empty pattern which has no instances.

## Theoretical Details of Sort Operations

### Sort Emptiness

Checking sort emptiness can be be reduced to a rewrite system reachability problem over finite sets of sorts in the original signature where:

1. For each non-constant operator f : s1 ... sn -> s, we add a rule s -> s1 ... sn
2. For each constant operator c : -> s, we add a rule s -> *
3. For each subsort inclusion s < s', we add a rule s' -> s
4. The reachability problem in question is given by s ->+ *

### Sort Finiteness

Checking sort finiteness can be reduced to an LTL model checking problem where:

1. The LTL model states are the sorts in the original signature
2. For each sort s, we have label @(s) which holds iff the current state is s
3. For each operator f : s1 ... sn -> s where input sorts are non-empty and sort s' where s < s', add rules s -> si for each 1 <= i <= n
4. Each sort with no constructible terms besides constants is called a final sort; for each final sort s add a rule s -> s
5. Then, to prove a given sort s is finite, for each non-final sort s' reachable from s, check that s' cannot reach itself (this proposition is expressible as an LTL formula)

## Theoretical Details of Pattern Operations

### Closure Under Boolean Operations

For some order-sorted signatures, term patterns are closed under union, intersection, and difference. Otherwise, we can usually apply a transformation to a signature so that it becomes closed under these operations.

### Special Patterns

Assuming finite signatures, there is a finite pattern which generates every term. There is also a finite pattern generates no terms (e.g. the empty pattern).

### Pattern Equivalence

Two patterns are considered equivalent if they generate the same term set. This condition can be checked by observing if the subtracting each pattern by the other results in the empty pattern.

### Relationship to Propositional Tree Automata

An order-sorted signature can be viewed as a tree automaton that accepts as inputs any term that the signature generates. The generalization of a tree automaton—a propositional tree automaton—can accept not only terms but also unions, intersections, and complements of terms. Our order-sorted term patterns provide a simpler and more intuitive algorithm which accomplishes this same task.

### Order-sorted Symbolic Difference

Our symbolic difference algorithm generalizes previous approaches such as that of Lassez and Marriott, by extending to the case of order-sorted terms.

To use the pattern solver tool, both of the following tarballs will need to be downloaded. Note that currently, the binary is compiled for Linux only. Any modern Linux distribution should be unproblematic.

Once you have downloaded and unpacked both archives, you can run examples. To do so, you need to invoke the Maude rewrite engine (called maude in Maude binary tarball) on the example you wish to run. For example, if I unpacked both archives in my home directory and wanted to run the Pichler example (shown below), I could run:

# ~/maude2.7-bin/maude ~/pat-solve-rel/examples/pichler-ex.maude

## Tool Example Inputs

The following example inputs are all taken from the /examples folder inside the root directory of the pattern solver tool:

These examples are all formatted as equalities between two pattern terms, tested using the method presented above. The terms occurring in a pattern are presented using Maude META-LEVEL syntax, which is documented in the Maude Manual (see section 11.2).

Hopefully, the examples will give a flavor of how the syntax looks when written down and the kinds of queries one might make.