Equational unication in Denali
3.2 Simplifying unication
If we are to incorporate equational unication into Denali, we must provide a way of coping with the complexities outlined above. Although the discovery of more powerful equational unication procedures would be helpful, we are not basing Denali upon any such development. Instead, we have designed Denali to support a methodology that relies upon the programmer's exploiting three separate approaches to the problem of containing the complexity of equational unication.
First, the programmer can exploit the sort hierarchy to stratify an otherwise mono-lithic equational theory so that the implementation of unication can be decomposed.
The programmer is responsible for dening, for each sort, a unication procedure over the terms of that sort. The language implementation is responsible, in turn, for combining these separate procedures into an overall unication procedure. We will elaborate this
3.2. Simplifying unication 57 strategy in Section 3.2.1.
Second, the programmer, by keeping in mind the limitations of unication in Denali, can strive to design realizable abstractions. It is possible to lessen the diculty of uni-fying the terms of a given sort by converting some of the constructors of that sort into predicates. This approach is the topic of Section 3.2.2.
Third, the programmer can impose mode restrictions to constrain the domain of the unication procedure of each sort, consequently simplifying its implementation. In im-posing the mode restrictions, the programmer must make an engineering tradeo between the expressive power of the unication procedure and the diculty of its implementa-tion. We will describe this approach, which we call moded equational unication, in Section 3.2.3.
Although we discuss approaches to simplifying the demands upon implementations of unication, we do not describe how implementations are actually written. We will consider the implementation problem in detail in Chapter 4.
3.2.1 Sort stratication
The operational semantics of Denali under equational unication, which we will discuss in Section 3.3, requires that the programmer provide a unication procedure for each sort. The implementation of a unication procedure must respect an underlying equa-tional theory. Thus, the nat unication procedure, given any two terms of sort nat, should enumerate a complete set of uniers for the terms. For example, one complete set of uniers of the two terms X+Y and s(0) is the sequence of two substitutions,
hX=0; Y=s(0)i and hX=s(0); Y=0i.
Because of sort restrictions, not all of the complexity of the equational theory that underlies a program need be built into any particular unication procedure. Only that part of the theory that applies to terms of the sort in question need be considered. For example, suppose that the theory underlying a program contains the union of the nat andlist theories. Thelist constraints need not be taken into account when unifyingnats, since nonat can contain alist. The converse is not true, however, sincelists can contain nats as elements.
58 3. Equational unication in Denali
3.2.2 Simplifying abstractions
The programmer must be aware of the limitations of Denali, and avoid designing pro-grams for which unication procedures cannot be constructed. The most important design decisions in this regard involve deciding what function symbols can be used to construct terms for a given sort. Adding function symbols, while increasing expressive power by making a greater variety of terms available, generally complicates the unica-tion problem since the relaunica-tionships between symbols can become more complicated.
An alternative to providing an n-ary function as a constructor is to provide it as an
n+1-ary predicate instead. Providing it as a predicate lessens the expressive power of the terms of its sort, since a lesser variety of terms can be constructed. But it simplies the equational theory since that function symbol's interaction with the others is eliminated.
The eects of this tradeo can be seen with thelist sort that we have used repeatedly as an example. When a binary append function is incorporated along with the nil and cons functions, a non-empty equational theory is required to express their relationships.
Ifappend is supplied as a ternary predicate, classical unication suces for the remaining list terms.
3.2.3 Moded unication
The diculty of obtaining a complete unication procedure lies not with the equational theory itself but in the set of terms with which the procedure must deal. The demands upon an equational unication procedure can be relaxed if the domain over which it must operate is restricted. Regardless of the theory, for example, it is always trivial to unify pairs of variables. In general, an implementation can be made more tractable by eliminating the instances in which its worst-case performance occurs.
Given an appropriate change to the semanticsof Denali, to be explained in Section 3.3, modes can be used to place restrictions upon the interfaces of unication procedures.
The resulting problem, moded equational unication, is often easier to solve than the corresponding unmoded equational unication problem.
The weakest possible restriction is to require that both arguments to a unication
3.2. Simplifying unication 59 procedure be of mode any. We require that all unication procedures be at least this restrictive. This allows us to permitthe appearance of unmoded termsin Denali programs while ruling out the possibility that pairs of unmoded terms will ever be unied.
The requirements of the unication procedure drive the design of the moded base.
To illustrate this, consider the equational theory for nat. The smallest complete set of uniers of the pair of terms X+Y and Z+W is innite. If no moded nat term ever contains more than one variable, however, then every uniable pair of moded nats will possess a singleton complete set of uniers.
A programmer, having made this observation, might choose to dene the modes for nat so that terms containing more than one variable are unmoded. This can be done by giving the following mode signature:
any>gnd 0:!gnd s: gnd!gnd s: any!any +: gnd;gnd!gnd +: gnd;any!any +: any;gnd!any
The key to this is the omission of the stipulation that +: any;any!any.
Since terms containing more than one variable are unmoded, they never need to be considered by the unication procedure.
It is sometimes necessary to impose stricter mode restrictions upon unication.
Con-sider, for example,the problemof unifying the twolisttermsappend(L1;L2) andappend(L3;L4).
The smallest complete set of uniers is innite. On the other hand, unifying a pair of list terms such as append(L1;L2) and cons(X ;cons(Y;cons(Z ;nil))) is simpler, yielding only four uniers. By imposing a mode restriction uponlist unication that requires that one of the two terms be of mode any and the other of modeenum, better performance can be guaranteed since the problem of unifying pairs of unenumeratedlists need not be considered by the implementation.
We will adopt the following general scheme for expressing the mode restriction that is to be placed upon the unication procedure for a sort S. A single mode M of sort
60 3. Equational unication in Denali
S encodes the restriction for the procedure. One argument to the unication procedure must be of mode M, while the other must be of mode any. In other words, if the mode restriction M is any, then the unication moding is (any;any); otherwise, the moding is (M;any);(any;M). The moding for nat unication can be encoded as any, while the moding for list unication can be encoded as enum.