2.1 The Sharing abstract domain

The pioneering abstract domain Sharing by Jacobs and Langen (Reference Jacobs and Langen1992) represents sharing information in a concise set representation. Let $\mathcal{V}$ be an infinite set of variables and $\mathcal{P}_f(\mathcal{V})$ be the set of its finite subsets. The domain Sharing can be defined as follows:

\begin{equation*} \mathrm{S{\scriptstyle HARING}} = \{ [A,U]\mid A\subseteq \mathcal{P}(U), (A\neq \emptyset \Rightarrow \emptyset \in A), U \in \mathcal{P}_f(\mathcal{V}) \} . \end{equation*}

Intuitively, an abstract object $[A,U]$ describes the relationships among the variables in $U$ : if $S\in A$ , the variables in $S$ are allowed to share a common variable. For example, $[\{ \{x,y\},\{z\},\emptyset \},\{w,x,y,z\}]$ represents the substitutions where $x$ and $y$ may possibly share, while $z$ is independent from both $x$ and $y$ . Moreover, the variable $w$ , which does not appear in the first component, is ground. Two examples of such substitutions are $\{x/y, w/a\}$ and $\{w/a\}$ while $\{x/z, w/a\}$ is not, because $x$ and $z$ do share. In addition, a special value $\bot$ is needed to denote the empty set of substitutions.

2.2 The shLin abstract domain

The abstract domain ShLin keeps track of the amount of linearity information in a substitution, coupling an object of Sharing with the set of linear variables. More formally, it is defined as the reduced product of Sharing and a basic linearity domain Lin. Each element of ShLin is a triple where the first component represents the sets of variables which may share, exactly as in Sharing; the second component records the set of variables that must be linear; the third component is, as before, the set of variables of interest. The abstract domain ShLin is defined as follows, where $\mathit{vars}(S)$ denotes the set of all the variables in $S$ :

\begin{equation*} \mathrm{S{\scriptstyle H}L{\scriptstyle IN}} = \{ [S,L,U]\mid S \subseteq \mathcal{P}(U), (S \neq \emptyset \Rightarrow \emptyset \in S), L \supseteq U \setminus \mathit{vars}(S), U \in \mathcal{P}_f(\mathcal{V}) \} \enspace . \end{equation*}

For instance, $[\{ \{x,y\}, \emptyset \},\{x,z\}, \{x,y,z\} ]$ represents the substitutions where $x$ may share with $y$ , while $x$ and $z$ are (always) bound to a linear term (actually $z$ must be ground). Two examples of such substitutions are $\{x/t(u,a), y/t(u,u), z/a\}$ and $\{x/y, z/a\}$ , while $\{x/t(u,u), y/t(u,u), z/a\}$ is not since $t(u, u)$ is not linear.

2.3 Intuition on linearity and its impact on sharing precision

Linearity information plays a key role in improving the precision of sharing analysis. In fact, when a variable occurs multiple times in a term, unification may introduce additional sharing between variables.

For instance, consider the substitution $\theta _1=\{x/f(u,v)\}$ over the set $U=\{x\}$ of variables of interest. This substitution is abstracted in Sharing as $S=[\{ \{x\}, \emptyset \},U]$ . If we now compute the $\mathit{mgu}$ between $S$ and $\mathcal E=\{x=f(y,z)\}$ , we obtain the abstract object $\mathit{mgu}(S,\mathcal E)=[\{ \{x,y\},\{x,z\},\{x,y,z\}, \emptyset \},\{x,y,z\}]$ , which contains the sharing group $\{x,y,z\}$ , due to the fact that the substitution $\theta _2=\{x/f(u,u)\}$ is also abstracted as $S$ in Sharing.

Linearity information mitigates this problem. Intuitively, linearity acts as a constraint that rules out combinations of sharing groups that would only arise due to repeated occurrences of variables. In fact, the substitutions $\theta _1$ and $\theta _2$ are abstracted in different objects in ShLin, namely $S_1=[\{ \{x\}, \emptyset \},\{x\},U]$ and $S_2=[\{ \{x\},\emptyset \},\emptyset ,U]$ . The abstract unification operator in ShLin can now exploit this information and obtain $\mathit{mgu}(S_1,\mathcal E)=[\{ \{x,y\},\{x,z\},\emptyset \}, \{x,y,z\},\{x,y,z\}]$ while $\mathit{mgu}(S_2,\mathcal E)=[\{ \{x,y\},\{x,z\},\{x,y,z\},\emptyset \}, \emptyset ,\{x,y,z\}]$ which still contains the sharing group $\{x,y,z\}$ .

2.4 The shLin² abstract domain

The idea behind $\mathrm{S{\scriptstyle H}L{\scriptstyle IN}}^{2}$ is to enhance Sharing by annotating each sharing group with linearity information on each variable. If a variable in a sharing group is (possibly) non-linear, it is denoted using $\omega$ as an exponent, otherwise the variable is linear. For instance, the object $xy^\omega z$ (called a 2-sharing group) represents the sharing group $\{x,y,z\}$ and the information that the common variable shared among $x$ , $y$ and $z$ may occur more than once in $y$ but only once in $x$ and $z$ . For example, this is the case for the variable $u$ in the substitution $\{ x/f(u,v,v), y/g(u,u,w), z/u \}$ . The $\mathrm{S{\scriptstyle H}L{\scriptstyle IN}}^{2}$ abstract domainFootnote ³ can be defined as follows:

\begin{equation*} \mathrm{S{\scriptstyle H}L{\scriptstyle IN}}^{2} = \bigl \{ [S,U] \mid \text{$S$ is a set of 2-sharing groups}, U \in \mathcal{P}_f(\mathcal{V}), S \neq \emptyset \Rightarrow \emptyset \in S \bigr \} . \end{equation*}

Linearity information may vary between 2-sharing groups. For instance, $[\{xy, y^\omega z, \emptyset \}, \{x, y, z\}]$ represents the substitutions $\theta$ where the variable $y$ may share with $x$ or $z$ , $x$ and $z$ are linear, while $y$ might be non-linear. However, the variable in common between $\theta (x)$ and $\theta (y)$ may only appear once in $\theta (y)$ . An example of such a substitution is $\{x/u, y/t(u,v,v), z/v\}$ , while $\{x/u, y/t(u,u,v), z/v\}$ is not.

2.5 Optimal abstract operators

All the above abstract domains are equipped with the optimal abstract operators for unification, matching and the other required operations. Amato and Scozzari (Reference Amato and Scozzari2009, Reference Amato and Scozzari2024) implement backward unification through matching, exploiting the property that the exit substitution is always more instantiated than the call substitution. Analyses based on matching have been shown to be strictly more precise than analyses that do not use matching. Moreover, Amato and Scozzari (Reference Amato and Scozzari2024) show that when using the optimal operators, the overall analysis is strictly more precise than the analysis performed with the standard operators. Surprisingly, the optimal operators are able to improve not only sharing and linearity information but also groundness.

3.1 Structure of the code

PLAI is written in Prolog and completely modular: each abstract domain is implemented in its own module and communicates with the analyzer engine through a well-defined interface. However, this interface is quite extensive and, to reduce the amount of code required for each abstract domain, we implemented a compatibility layer in the module as_template which translates the standard interface into more elementary operations.

For example, consider the call_to_entry predicate, part of the abstract domain interface, corresponding to what we have called forward unification. It is defined as follows:

where

• • Sg is the goal we are going to analyze;

• • Sv is the set of variables occurring in Sg;

• • ClauseKey is an identifier for the clause we are using to analyze Sg;

• • Head is the head of the clause;

• • Hv is the set of variables occurring in Head;

• • Fv are the variables in the clause that do not occur in Head;

• • Proj is the call substitution projected onto the variables in Sv;

• • Entry is the resulting entry substitution;

• • ExtraInfo may contain additional information that is passed later to the backward unification phase.

Our implementation of this predicate is the following:

It combines the predicates augment, mgu and project, implemented in each of our domains, with unifiable_with_occurs_check which is a built-in predicate in Ciao.

The compatibility layer also avoids duplicating code that is syntactically identical across different domains. For example, the special value $bottom, which denotes an empty abstract substitution (corresponding to $\bot$ in Section 2.1), is handled largely within this layer. The same applies to most of the code for analyzing Prolog built-ins. Apart from the compatibility layer, there are two other modules that contain code shared by all our domains: as_aux contains generic utility code, while as_bags contains an implementation of finite multisets.

Finally, the three domains are implemented in the modules as_sharing, as_shlin and as_shlin2. Although CiaoPP already provides several implementations of Sharing, we have devised a new one to serve as a baseline for the other domains in our collection. The behavior of the analysis (such as choosing between matching or unification for backward unification, or between optimal and standard operators) can be configured through specific CiaoPP flags.

The built-in PLAI domains for sharing analysis are implemented natively in Prolog, using sets (ordered lists) and a shallow encoding of logic variables. We adopt the same approach in our implementations. All code is fully annotated with type and mode information using the annotation mechanism provided by the Ciao system. For example, this is the complete specification of the predicate computing the lubs of abstract substitutions:

The specification states that compute_lub is always called with a non-empty list of abstract substitutions as its first argument, and an independent variable as a second argument, which is bound to an abstract substitution on exit. The predicate is also declared to be deterministic and not to fail (when called under these preconditions). These annotations may be checked at run-time and have proved very useful during development, both for catching bugs in our code and for ensuring a correct understanding of how the CiaoPP interface is expected to work. In addition, most modules include a comprehensive test suite.

3.2 From the algorithm to the implementation

Moving from the algorithmic descriptions given in our papers to their actual implementation has not always been straightforward, and has required careful consideration.

First of all, while PLAI has the predicate call_to_entry which corresponds directly to forward unification, it splits backward unification into two distinct steps. First, the exit substitution is projected onto the variables of the chosen atom by the predicate exit_to_prime, it is then extended to all the variables of the original goal by the predicate extend, incorporating the information on the other variables coming from the call substitution. This process is depicted in Figure 1, which we briefly describe here. The procedure $\texttt {{call to entry}}$ computes the $\mathit{mgu}$ between $\theta ^{in}$ and $\mathcal E$ , the equation connecting the selected atom $q(t(Y), Y)$ and the clause head $q(t(A), B)$ , yielding $\bar \theta = \mathit{mgu}(\theta ^{in}, \mathcal E) = \{X/f(\_0),Y/f(\_0),Z/\_1,A/f(\_0),B/f(\_0)\}$ . This is then projected onto the variables of the clause to obtain the entry substitution $\theta$ . After analyzing the body, $\theta$ is further instantiated, yielding the exit substitution $\theta '$ .

Now exit_to_prime computes the $\mathit{mgu}$ between $\theta '$ and $\bar \theta$ , and projects the result onto the variables of the selected goal, obtaining $\theta ''$ , called the prime. Note that in this step we are sure that variables in $\theta '$ are not further instantiated, hence unification may be replaced by matching. Using matching instead of unification (which is irrelevant in the concrete) improves precision in the abstract. Finally, extend propagates the effect of the prime to the entire initial goal, by unifying it with the call substitution. Again, since variables in the prime are not going to be further instantiated, unification may be replaced by matching.

Two observations are worth noting. First, the extend step is conceptually redundant: the final projection in exit_to_prime could be performed directly over all variables of the initial goal, thus producing the answer substitution in a single step. However, this would require modifying the PLAI engine, which we do not intend to do. Second, our $\mathit{mgu}$ and $\mathit{match}$ operations are designed so that $\mathit{mgu}$ takes an abstract substitution and a concrete set of equations, whereas $\mathit{match}$ takes two abstract substitutions. This makes the implementation of extend using only $\mathit{mgu}$ a bit cumbersome, since it should operate on two abstract substitutions.

Fig. 1.

Flow of the analysis in PLAI.

More importantly, the definitions of $\mathit{mgu}$ and $\mathit{match}$ given in our papers are expressed in a declarative style. It is relatively easy to implement these operators following the definitions using a generate-and-test approach, and we have adopted this strategy in several cases. However, there are some cases in which this approach is too slow, making it necessary to devise more carefully optimized implementations.

As an illustrative example, consider the definition of the matching operator for ShLin shown in Figure 2. Rather than discussing the details of the definition (for which we refer to Amato and Scozzari (Reference Amato and Scozzari2010)), we use it here to highlight some of the issues that arise in its implementation. The crucial step in the definition is the computation of $S''_0$ . This involves selecting a sharing group $B \in S_1$ and a subset of sharing groups $X \subseteq S''_2$ , and then checking whether the conditions $B \cap U_2 = \left (\bigcup X\right ) \cap U_1$ and $L_1 \cap nl(X)=\emptyset$ are satisfied.

A straightforward implementation would follow a generate-and-test strategy that mirrors the formal definition. However, this approach requires enumerating a large number of candidate subsets $X$ , whose number is exponential in the size of $S''_2$ , which is itself potentially exponential in the number of program variables. To obtain a practically usable implementation, it is therefore necessary to reduce the search space.

First, once we fix $B \in S_1$ , a necessary condition for satisfying $B \cap U_2 = \left (\bigcup X\right ) \cap U_1$ is that every $C \in X$ satisfies $C \cap U_1 \subseteq B \cap U_2$ . Hence, we can restrict the search to subsets $X \subseteq \{ C \in S''_2 \mid C \cap U_1 \subseteq B \cap U_2 \}$ . Additionally, instead of generating $X$ , checking constraints and then producing the pair $\left \langle B \cup \bigcup X, L_2 \setminus nl(X) \setminus \bigcup (X \cap \bar S) \right \rangle$ , we have devised a procedure that incrementally builds the resulting pairs, without explicitly generating the candidates $X$ at all. In this way, although the theoretical complexity of the procedure does not decrease, the implementation is generally much faster.

Fig. 2.

The definition of the match operator in ShLin, for $[S_1,L_1,U_1]$ and $[S_2,L_2,U_2] \in \mathrm{S{\scriptstyle H}L{\scriptstyle IN}}$ .