nonreach – A Tool for Nonreachability Analysis

. We introduce nonreach , an automated tool for nonreachabil-ity analysis that is intended as a drop-in addition to existing termination and conﬂuence tools for term rewriting. Our preliminary experimental data suggests that nonreach can improve the performance of existing termination tools.


Introduction
Nonreachability analysis is an important part of automated tools like T T T 2 [1] (for proving termination of rewrite systems) and ConCon [2] (for proving confluence of conditional rewrite systems). Many similar systems compete against each other in the annual termination (TermComp) 1 and confluence (CoCo) 2 competitions, both of which will run as part of TACAS's TOOLympics 3 in 2019.
Our intention for nonreach is to become a valuable component of all of the above mentioned tools by providing a fast and powerful back end for reachability analysis. This kind of analysis is illustrated by the following example.
Example 1. Suppose we have a simple program for multiplication represented by a term rewrite system (TRS, for short) consisting of the following rules: add(0, y) → y add(s(x ), y) → s(add(x , y)) mul(0, y) → 0 m u l (s(x ), y) → add(mul(x , y), y) For checking termination we have to make sure that there is no infinite sequence of recursive calls. One specific subproblem for doing so is to check whether it is possible to reach t = MUL(s(y), z ) 4 from s = ADD(mul(w , x ), x ) for arbitrary instantiations of the variables w , x , y, and z . In other words, we have to check nonreachability of the target t from the source s.
In the remainder we will: comment on the role we intend for nonreach (Sect. 2), describe how nonreach is built and used (Sect. 3), give an overview of the techniques that went into nonreach (Sect. 4), and finally provide some experimental data (Sect. 5).

Role
When looking into implementations of current termination and confluence tools it soon becomes apparent that many tools use the same techniques for proving nonreachability. In light of this observation, one of our main goals for nonreach was to provide a dedicated stand-alone tool for nonreachability that can be reused for example in termination and confluence tools and can in principle replace many existing implementations.
In order to make such a reuse desirable for authors of other tools two things are important: (1) we have to provide a simple but efficient interface, and (2) we should support all existing techniques that can be implemented efficiently. 5 At the time of writing, we already successfully use nonreach as back end in the termination tool T T T 2 [1]. To this end, we incorporated support for external nonreachability tools into T T T 2 , with interaction purely via standard input and output. More specifically, while at the moment only YES/NO/MAYBE answers are required, the interface is general enough to support more detailed certificates corroborating such answers. The external tool is launched once per termination proof and supplied with those nonreachability problems that could not be handled by the existing techniques of T T T 2 . Our next goal is to achieve the same for the confluence tool ConCon [2].
Furthermore, a new infeasibility category will be part of CoCo 2019. 6 Infeasibility is a concept from conditional term rewriting but can be seen as a variant of nonreachability [3]. Thus, we plan to enter the competition with nonreach.
Another potential application of nonreach is dead code detection or showing that some error can never occur.

Installation and Usage
Our tool nonreach is available from a public bitbucket 7 repository which can be obtained using the following command: git clone git@bitbucket.org:fmessner/nonreach.git To compile and run nonreach, you need an up to date installation of Haskell's stack. 8 The source code is compiled by invoking stack build in the project directory containing the stack.yaml file. In order to install the executable in the local bin path (~/.local/bin/ on Linux), run stack install instead.
Usage. The execution of nonreach is controlled by several command line flags. The only mandatory part is a rewrite system (with respect to which nonreachability should be checked). This may be passed either as literal string (flag -d "...") or as file (flag -f filename). Either way, the input follows the formats for (conditional) rewrite systems that are used for TermComp and CoCo.
In addition to a rewrite system we may provide the nonreachability problems to be worked on (if we do not provide any problems, nonreach will wait indefinitely). For a single nonreachability problem the simple format s -> t is used, where s and t are terms and we are interested in nonreachability of the target t from the source s. Again, there are several ways to pass problems to nonreach: • We can provide white-space-separated lists of problems either literally on the command line (flag -P "...") or through a file (flag -p filename). • Alternatively, a single infeasibility problem can be provided as part of the input rewrite system as specified by the new infeasibility category of CoCo 2019. • Otherwise, nonreach waits for individual problems on standard input.
For each given problem nonreach produces one line of output: In its default mode the output is NO whenever nonreachability can be established and either MAYBE or TIMEOUT, otherwise. When given an infeasibility problem, the output is YES if the problem is infeasible and either MAYBE or TIMEOUT, otherwise.
Further flags may be used to specify a timeout (in microseconds; flag -t) or to give finer control over the individual techniques that are implemented in nonreach (we will mention those in Sect. 4).
It is high time for an example. Let us check Example 1 using nonreach.

Example 2.
Assuming that the TRS of Example 1 is in a file mul.trs we can have the following interaction (where we indicate user input by a preceding >): nonreach -f mul . trs > ADD ( mul (w ,x),x) -> MUL (s(y),z) NO

Design and Techniques
In this section we give a short overview of the general design decisions and specific nonreachability techniques that went into nonreach.
Design. Efficiency was at the heart of our concern. On the one hand, from a user-interface perspective, this was the reason to provide the possibility that a single invocation of nonreach for a fixed TRS can work on arbitrarily many reachability problems. On the other hand, this lead us to mostly concentrate on techniques that are known to be fast in practice. The selection of techniques we present below (with the exception of narrowing) satisfies this criterion.
Techniques. Roughly speaking, nonreach uses two different kinds of techniques: (1) transformations that result in disjunctions or conjunctions of easier nonreachability problems, and (2) actual nonreachability checks. We use the notation s t for a nonreachability problem with source s and target t.
Reachability checks. The first check we recapitulate is implemented by most termination tools and based on the idea of computing the topmost part of a term that does not change under rewriting (its cap) [4]. If the cap of the source s does not unify with the target t, then there are no substitutions σ and τ such that sσ → * tτ . There are different algorithms to underapproximate such caps. We use etcap, developed by Thiemann together with the second author [5], due to its linear time complexity (by reducing unification to ground context matching) but nevertheless simple implementation. With etcap subterms are matched bottomup with left-hand sides of rules. In case of a match, the corresponding subterm is potentially rewritable and thus replaced by a hole, written , representing a fresh variable. We illustrate etcap on the first two (addition) rules of Example 1.
The second reachability check implemented in nonreach [3,6] is based on the so called symbol transition graph (SG for short) of a TRS. Here, the basic idea is to build a graph that encodes the dependencies between root symbols induced by the rules of a TRS. This is illustrated by the following example: we generate the corresponding SG shown in Fig. 1(a) on page 5. For each rule we generate an edge from the node representing the root symbol of the left-hand side to the node representing the root symbol of the right-hand side. Since in the last rule, the right-hand side is a variable (which can in principle  be turned into an arbitrary term by applying a substitution), we have to add edges from h to all nodes (including h itself).
From the graph it is apparent that f(x , y) is not reachable from g(z ), no matter the substitutions for x , y and z , since there is no path from g to f.
We obtain the following SG based nonreachability check: Which reachability checks are applied by nonreach can be controlled by its -s flag, which expects a list of checks (in Haskell syntax). Currently the two checks TCAP and STG are supported.
Transformations. We call the first of our transformations (problem) decomposition. This technique relies on root-reachability checks to decompose a problem into a conjunction of strictly smaller subproblems. Thus, we are done if any of these subproblems is nonreachable.
Decomposition of a problem s t only works if source and target are of the form s = f (s 1 , . . . , s n ) and t = f (t 1 , . . . , t n ), respectively. Now the question is whether t can be reached from s involving at least one root-rewrite step. If this is not possible, we know that for reachability from s to t, we need all t i to be reachable from the corresponding s i .
For the purpose of checking root-nonreachability, we adapt the two reachability checks from above: if there is a non-empty path from root(s) to root(t) in the SG False otherwise If at least one of these checks returns False, we can decompose the initial problem s t into a conjunction of problems s 1 t 1 , . . . , s n t n .
The second transformation is based on narrowing. Without going into too much technical detail let us start from the following consideration. Given a reachability problem s t, assume that t is reachable from s. Then either the corresponding rewrite sequence is empty (in which case s and t are unifiable) or there is at least one initial rewrite step. Narrowing is the tool that allows us to capture all possible first steps (one for each rule l → r and each subterm of s that unifies with l), of the form s → s i → * t. This idea is captured in Fig. 1(b). Now, decomposition (which is always applicable and thus has to be handled with care), transforms a given reachability problem s t into a disjunction of new problems (that is, this time we have to show NO for all of these problems in order to conclude NO for the initial one) s ? ∼ t or s 1 t or . . . or s k t, where the first one is a unifiability problem and the remaining ones are again reachability problems.
The maximal number of narrowing applications is specified by the -l flag.

Experiments
In order to obtain test data for nonreach we started from the Termination Problem Data Base (TPDB, for short), 9 the data base of problems that are used also in TermComp. Then we used a patched version of the termination tool T T T 2 to obtain roughly 20,000 non-trivial reachability problems with respect to 730 TRSs. These are available from a public bitbucket repository 10 alongside a small script, that runs nonreach on all the problems and displays the overall results. All these problems could, at the time of creating the dataset, not be solved with the reachability checks used in the competition strategy of T T T 2 . The current version 11 of nonreach in its default configuration can prove nonreachability of 369 problems of this set. While this does not seem much, we strongly suspect that the majority of problems in our set are actually reachable. The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.