1. Constraints in NUT - CiteSeerX

1. Constraints in NUT

Jaan Penjam

Institute of Cybernetics, Akadeemia tee 21, EE0026 Tallinn, Estonia

Enn T~ougu

Inst for Teleinformatik, Kungl Tekniska Hogskolan, Electrum 204, S-16440 KISTA, Sweden

Abstract NUT is a programming system for knowledge-based programming with facilities for automatic program synthesis. The system allows to specify computational problems in OO style. Concepts and objects can be treated in NUT as functional constraint networks. Constraint satisfaction problems are solved using algorithms for automatic program synthesis described earlier for the PRIZ system.

1.1 Introduction The NUT system is the most advanced representative of the family of programming systems called PRIZ. This family includes systems PRIZ ES, Solver, MicroPRIZ, ExpertPRIZ, NUT etc., which have been developed in the last 20 years in the Institute of Cybernetics of the Estonian Academy of Sciences. All these systems support a knowledge-based programming style and they have been successfully used to solve engineering problems as well as in scienti c investigations of AI. The NUT language was outlined as an extension of an object-oriented programming language with features of automatic program synthesis, and its full description appeared in [T~ougu et al. 1986]. But the language was never implemented in the precise correspondence with it. The rst implementation of a version of the NUT language was done as a part of a Soviet new generation computer project START on the Pirz workstations which were developed in the framework of the same project [Kotov et al. 1989] and [T~ougu 1991]. In 1990, the NUT system was implemented in various UNIX and X Windows Systems

2

1. Constraints in NUT

Speci cation processing 6

OOP

CP

-

?

?

?

?

CCP

Object manipulation

?

Constraint solving ?

?

Fig. 1.1.

Three dimensions of computing in NUT

environments [Matskin 1991]. The work on implementation of NUT was completed at the Royal Institute of Technology in Stockholm where it is now being used for educational purposes [Matskin and T~ougu 1992]. An attempt is made in the NUT to amalgamate dierent programming paradigms each of which claims to be a good platform for the future computing: logic programming, object-oriented programming, constraint programming, knowledge-based programming. When one combines dierent methods and techniques, always a rather natural question arises how to merge underlying paradigms into a new one which will preserve the merits of all of its constituents. Quite a success has been achieved in combining logic and constraint programming. Two very promising approaches have evolved: constraint logic programming [Jaar and Lassez 1987] and concurrent constraint programming [Saraswat 1990]. A recent work [Smolka et al. 1993] is an example of merging constraint programming with object-oriented programming. Having a closer look at the NUT system, one can see the following three dierent modes of computations in it:  speci cation processing (inheritance, delegation etc.);  object manipulation (sending and processing messages);  constraint solving (synthesizing and running programs on sets of relations). These are three orthogonal dimensions of computations which can be combined in various ways, Fig. 1.1. The combination of speci cation processing and object manipulation is what we call object-oriented programming. A coordinate plane determined by the axes of Speci cation processing and Constraint solving form constraint programming. Combination of object manipulation and Constraint solving is al-

1.2 Functional constraints

3

most covered by concurrent constraint programming and logic constraint programming. This coordinate plane corresponds also to the most interesting and novel part of the NUT system. This is a kind of constraint object programming which is still dierent from the approach taken in [Smolka et al. 1993], rst of all, because it applies a speci c technique of constraint solving by program synthesis. The aim of this article is to present constraint semantics of NUT classes. We describe the way how speci cations written in NUT are translated into functional constraint networks suitable for application of dierent satisfaction techniques. Some of these techniques are described in [T~ougu and Uustalu 1993].

1.2 Functional constraints Let X = fx1; x2; . . . xn g be a set of problem variables. We shall consider constraints as relations over the set X specifying which combinations of values of problem variables are acceptable. Formally, constraints can be written as interpreted formulae in rst-order predicate calculus. Let us denote constraints as follows: Ax1 (x1); Ax2 (x2);


; Axn (xn); Ax1;x2 (x1; x2); Ax1;x3 (x1; x3);


; Ax1;xn (x1; xn); Ax2;x3 (x2; x3); Ax2;x4 (x2; x4);


; Ax2;xn (x2; xn); ... Axn?1;xn (xn?1; xn); Ax1;x2;x3 (x1; x2; x3);


; Axn?2;xn?1 ;xn (xn?2; xn?1; xn); ... Ax1;x2;...;xn (x1; x2 . . . ; xn): In special cases, constraints may be simply atomic formulae, i.e. predicates which determine domains of variables (in the case of unary predicates) or "local" relationships between tuples of variables. A Constraint Satisfaction Problem (CSP) is represented by a conjunction of all constraints involved: Q(x1; x2; . . . ; xn)  Ax1 (x1)&


&Axn (xn) &Ax1;x2 (x1; x2)&


&Ax1;x2;...;xn (x1; x2 . . . ; xn): The CSP is solvable if the formula

9x1; x2; . . . ; xnQ(x1; x2; . . . ; xn)

(1:1) is constructively derivable. The proof of the solvability of the CSP is called constructive if during derivation individual constants x1; x2; . . . xn are indicated which satisfy the formula (1.1) for the underlying interpretation.

4

1. Constraints in NUT

In general, a CSP may have no complete solution when the amount of usable resources is limited. For eciency considerations partial constraint satisfaction problem is regarded [Freuder and Wallace 1992] or/and additional restrictions are set to the formulae representing expressions and to the interpretation of functional and predicate symbols. Two popular restrictions are that constraints may contain no functional symbols and domains of potential values of problem variables are nite [Mackworth 1992]. In this paper we shall restrict ourselves to the two following types of constraint formulae:  ground atoms Ax(x)  P (x) where P is a predicate specifying a domain of x. We call the predicate P characteristic predicate of the class of objects P if the predicate symbol P is interpreted as `argument x belongs to the class P';  functional constraints Ax1;...;xm;y (x1; . . . ; xm; y) which has an interpretation where y has at most one value satisfying the relation Ax1;...;xm;y (x1; . . . ; xm; y) for any tuple of values of x1; . . . ; xm In the last case, a constraint de nes a function y = f (x1; . . . ; xm) and can be put down as a formula X1; . . . ; Xm ?!f Y (1:2) where X1; . . . ; Xm are propositions representing computability of x1; . . . ; xm respectively. The formula (1.2) itself expresses the property that if the objects x1; . . . ; xm have suitable values then one can compute a value for y using function f . Functions determined by functional constraints may be of the second order as well. This means that a constraint may bind some objects g1; . . . ; gl of functional type which stand for arguments of the mapping F of the functional constraint. Formally, a constraint Ag1;...;gl;x1;...;xm;y (g1; . . . ; gl; x1; . . . ; xm; y) contains the second order functional dependency if the following holds y = F (g1; . . . ; gl; x1; . . . ; xm): Objects g1 ; . . . ; gl can obtain their values dynamically during solution of the current CSP [T~ougu and Uustalu 1993]. In this case, we still may wish to specify type of an object gi , saying that gi must be a function computing vi from ui1; . . . ; uiki . This is expressed by the formula Ui1; . . . ; Uiki ?!gi Vi: The constraint Ag1;...;gl;x1;...;xm;y (g1; . . . ; gl; x1; . . . ; xm; y) will then be represented by the following formula: (U11; . . . ; U1k1 ?!g1 V1); . . . ; (Ul1; . . . ; Ulkl ?!gl Vl); X1; . . . ; Xm ?!F Y : (1:3) Let us notice, that the relation Ag1;...;gl;x1;...;xm;y (g1; . . . ; gl; x1; . . . ; xm; y) binds the objects g1; . . . ; x1; . . . ; y, but not the objects u11; u12; . . . ; v1; . . .. Higher order functional constraints provide generality to the language of constraints, and allow some interesting applications, see Sec.1.5.2.

1.3 The NUT Language

5

1.3 The NUT Language NUT is an object-oriented programming language and environment for specifying problems by means of constraints with built-in methods for solving constraint satisfaction problem. As any object-oriented language, NUT has class and object as its basic notions. Class is a carrier of common features of objects of the same type, i.e. of objects with similar structure and with the property to react similarly to certain changes of their environment (receiving the same messages from other related objects). Let us introduce a predicate C (x) for every class C which is true for any object x of the class C and false otherwise. There are some prede ned classes such as num, text, bool etc. in the NUT system. Hence, there are a number of unary predicates de ned:  num(x) { x is a rational number, or that is the same, that x is an object of the class num;  text(x) { x is a string of characters;  bool(x) { x is a boolean value; etc. Similarly, the predicate triangle(ABC ) means that the object ABC belongs to the class of triangles. The dierence here is that a concept of triangle has to be speci ed and stored into the knowledge base by a user as the class triangle. Formally, every object x might be treated as a tuple of its attributes x = (x1; x2; . . . ; xn) which represents aspects of an object essential for underlying consideration. A number of attributes considered in any particular situation is assumed to be nite. A class C determines relationships between attributes of objects belonging to the class. Each class C has its characteristic predicate which can be speci ed as C (x)  9x1; x2; . . . ; xnQ(x; x1; x2; . . . ; xn) (1.4) where x1; . . . ; xn are its attributes. This is a constraint speci ed by the class C . The matrix Q in the formula (1.4) is the conjunction of "smaller" constraints representing relations between the attributes. So, using the class mechanism, a user can built up the hierarchy of constraints. There are the following means in the NUT system to specify various constraints:  constraints for structure of objects;  equational constraints over numeric objects;  constraints as dierent kinds of identity relations;  constraints as messages which may be accepted by an object together with its (pre)programmed reaction to the message. All these constraints can be represented by nite sets of functional constraints.

6

1. Constraints in NUT

1.3.1 Structural Constraints An object in NUT can have a xed number of components which are objects again. The names and types of these components are aspects to be speci ed by the class of the object. Considering objects with complex structure we suppose that there are two dierent operations one can apply to objects and their components. One can separate a component from the compound object to treat it further independently, and vice versa, one can incorporate objects of proper types into a new object as its components. For example, the situation where a class Z de nes its objects to consist of two components x and y of classes X and Y respectively, can be speci ed in the NUT language as Class Z:(var x:X; y:Y);

This is a structural constraint that binds any object z of class Z with its components which we denote by z:x and z:y. Semantically, this means that for every object z of the class Z there exist functions selectx, selecty and compose to separate components z:x and z:y from the object z and to unite the two objects into the object of class Z respectively. In other words, belonging to the class Z means for an object z that there are objects z:x and z:y, such that the following constraints are satis ed:

Az:x(z:x) Az:y (z:y) Az;z:x(z; z:x) Az;z:y (z; z:y) Az:x;z:y (z:x; z:y) Az;z:x;z:y (z; z:x; z:y)

     

X (z:x) Y (z:y) selectx(z) = z:x selecty(z) = z:y true compose(z:x; z:y) = z

(1.5) (1.6) (1.7) (1.8) (1.9) (1.10)

The class Z de nes therefore a predicate Z (z) as a conjunction of the formulae (1.5)-(1.10). The constraints (1.5) and (1.6) determine the domains (given by classes) of components z:x and z:y. Other relations are functional constraints and might be reformulated as follows:

Z ?!selectx Z :X Z ?!selecty Z :Y Z :X; Z :Y ?!compose Z

(1.11) (1.12) (1.13)

Constraints (1.7) and (1.8) can be treated as equations de ning abbreviation for selection operation selectx and selecty respectively. Afterwards we shall use elsewhere "dotted notation of selection", i.e. z:x instead of selectx(z). To represent computability of such a selected element the proposition Z.X will be used. For example, assuming that abbreviation, one can reduce the de nition of the characteristic predicate of class Z as follows:

1.3 The NUT Language

selectx

z.x:X t

7







@





@

@I

@

@

@

@

@

@

@

@ 



@

@R

-



?

?

compose

@

t

z:Z

?



?

?

?

?

?

?

?

? 



?

?

z.y:Y t?





Fig. 1.2.

selecty 

Constraint network of the class Z

Z (z) = X (z:x) & Y (z:y) & Z :X; Z :Y ?!compose Z : On the other hand, a set of implications in the form of formulae (1.11){ (1.13) permits a simple graphical representation of the constraint network. A constraint network is a graph where nodes are used for representation of objects involved and functional constraints (implications). The nodes of objects are denoted by names and types (classes) of the corresponding objects and the nodes of constraints are labelled by their names (see next sections) or/and by the functions realizing them. We shall omit some labels, for example classes of objects or function symbols, if there will be no confusion. In Fig.1.2, the constraints (1.11){(1.13) are presented as a network. A hierarchy of classes (and corresponding constraints) can be de ned in the manner described above. Besides structural constraints, a class may contain other kinds of conditions to be satis ed. In the following sections we show how these constraints are interpreted as implications in a propositional calculus. Every additional restriction for components of a class will complement its characteristic predicate by one or more atomic constraint.

1.3.2 Equations An equation

f (x1; . . . ; xn) = 0 (1:14) over numeric objects is a constraint which allows to nd some xi if all other x1; . . . ; xi?1; xi+1; . . . ; xn are given. This is valid only when we know the method how to compute xi from other variables of the equation. Let us denote by fi?1 the function which solves the equation (1.14) in respect of a variable xi: xi = fi?1 (x1; . . . ; xi?1; xi+1; . . . ; xn)

8

1. Constraints in NUT

so that

f (x1; . . . ; xx?1; fi?1(x1; . . . ; xi?1; xi+1; . . . ; xn); xi+1; . . . ; xn) = 0: An equation may be a partially solvable constraint in the sense that not always it can be solved in respect of all unknowns. For instance, the equation

x21 + 2x1 + 3 = 0 cannot be solved in real numbers at all, and the corresponding function fi?1 does not exist. Besides that we have to accept that sometimes we do not know how to get the function fi?1 even when it exists, as there is no general eective method to solve equations. The NUT language permits to include equational constraints over numeric components into class declarations. For instance, Class W:(var x,y:num; rel R: 2*x - y = 0);

means that an object of class W has two numeric components x and y constrained by the equation 2x ? y = 0. The semantics of an equation (1.14) is de ned by a conjunction of constraints Aix1;...;xn  X1&


&Xi?1&Xi+1&


&Xn ?!fi?1 Xi for every variable xi for which we know a function fi?1 . In the case of the class W above, the equation R generates two assignments:

x := g1 (y) = y=2 and

y := g2(x) = 2  x: Hence, the constraint de ned by the class W can be presented as the predicate W (w)  Num(w:x) & Num(w:y) & W :X & W :Y ?!compose W & W :X ?!g1 W :Y & W :Y ?!g2 W :X:

The constraint network corresponding to the given speci cation of the class W is shown in Fig.1.3. Combining structural and equational constraints permits us to de ne rather complex concepts as classes of objects of hierarchical structure. For example, the following two classes altogether specify a concept of line segment in twodimensional space.

1.3 The NUT Language

selectx

w:x:Num t



9







@

BM 





@

@I B

@

 @

B @

 @

B

@

 @

B @

 @













B

@ 

@R

-



R1



R2





B





?

?

compose

@

t

w:W

?



?

? B

 ?

?

B

 ?

? B

 ?

? 



B ?

 ?

w:y:Num BN

t? 





Fig. 1.3.

selecty 

Constraint network of the class W

Class

Point:(var x,y:num);

Class

Bar:(var P,Q:Point; length, angle:num; rel (P.x - Q.x)^2 + (P.y-Q.y)^2 = length^2; P.y - Q.y = (P.x - P.y) * tan(angle));

Here we can point out the expressive power of the NUT language - rather short class descriptions consisting of some equations taken from school textbooks generate a large number of constraints speci ed. Similarly to the class Z in the previous Section, the characteristic predicate Point consists of 5 atomic constraints. Therefore, the declarations of end points P and Q in the speci cation of the class Bar introduce 2  5 = 10 constraints. Two new constraints will be added by speci cation of domain Num for length and angle, and 10 more constraints are generated by the two equations as they are solvable with respect to all unknowns. To conclude, the class Bar speci es 32 constraints for every object of this class. This example demonstrates a problem speci c for equational constraint systems: equations may not have unique solutions. For instance, there are in nitely many values of variable angle which satisfy the last equation in the class Bar for xed valuation of other variables. The NUT system uses some heuristics to choose the solution, however it is recommended to avoid usage of equations with multiple solutions. In many cases speci cations with equations of this kind can be transformed into the "equivalent" ones with unique solution. This is mainly a knowledge engineering task we do not consider here which allows one to use the NUT system for solving practical problems such as they arose in CAD systems or implementing semantics of programming languages (see [Kalja and Pahapill 1992], [Penjam 1990]).

10

1. Constraints in NUT

1.3.3 Programs as constraints NUT permits a exible mechanism for message passing between objects. This is used for invoking methods available for an object of a class. Besides that, a method corresponds strictly to a set of functional constraints between the components of the object. A set of constraints

X1; . . . ; Xm ?!f Y1 1

X1; . . . ; Xm ?!fn Yn

...

where f = (f1; . . . ; fn) can be speci ed in NUT as a method with a name R in the following way: R : x1, ... , xm -> y1, ... , yn { f };

Hence, there is correspondence between functional constraints and methods speci ed by a class. Let us look at the example: Class compl:(var re, im : num; mod, arg : num; rel retomod : re, im -> mod, arg {mod:=sqrt(re^2 + im^2); arg:=arccos(re/mod)}; modtore : mod, arg -> re, im {re:=mod * cos(arg); im:=mod * sin(arg)});

The two relations retomod, modtore of the class compl are speci ed by the following two parts. First, they have external views of constraints which specify their input and output parameters and give some type information, i.e. explicit information about their input and output parameters written to the left and to the right of an arrow: re, im -> mod, arg mod, arg -> re, im

This external information of constraints is used for planning computations when a constraint problem is solved (see [T~ougu and Uustalu 1993] in this book). Second, speci cation of these relations contain programs written in an imperative language which is a part of NUT. These programs implement the methods. This is the semantics of the speci cations used in object-oriented computations. The second relation describes a method with an input variables mod

1.3 The NUT Language

11

and arg and output variables re and im which can be invoked by a message modtore. Any method speci ed in the class de nes a node of the constraint network of every object of the class. This node is labelled by the name of the method and there are arcs binding the node with inputs and outputs of the method. If there is an object C 1 of class compl, methods retomod and modtore give the following two nodes: retomod C1.re C1.mod 



-

s

-

s

 



Z}

Z Z 

>

Z Z 



Z Z 



Z Z 



Z



Z



Z



Z



Z Z  

Z



C1.im

Z





 =

Z

Z 

Z~

s



 s

C1.arg

modtore Let us remark that any solvable arithmetic equation can be replaced by a set of speci cations of methods representing its functions fi (cf. previous Sec.). For example the equation y = 2x is equivalent to the following methods: 



rel R1 : x -> y {y:=2*x}; R2 : y -> x {x:=y/2};

1.3.4 Identity relations NUT has a large number of speci c language constructions that allow to describe speci cation transformations which are usual for object oriented programming. Some of these features can be eectively speci ed using dierent kinds of identity relations. Identity in the NUT means that two (or more) objects have the same component values. This does not mean automatically that these objects are of the same type, however there must be some correspondence between the types of components of related objects. In the simplest case when two numeric objects x and y are de ned to be identical, it means that there is an equation

x=y together with its standard semantics as it was described in previous Section. Identity relation between objects is syntactically speci ed in the same form, i.e it looks like an equation. However, the semantics of such a relation is more complicated and depends on the order of components being speci ed in classes. Omitting here details one can read in [T~ougu 1988, page 78] we demonstrate this feature in the case of binding construction.

12

1. Constraints in NUT

Bindings are amendments to types introduced by the speci cations of components, and they introduce additional constraints. Let us consider an example where one has de ned a triangle as a connection of three line segments: triangle : ( var AB : Bar ; BC : Bar P=AB.Q; CA : Bar P=BC.Q, Q=AB.P; perimeter : num; rel perimeter=AB.length+BC.length+CA.length);

The binding P=AB.Q In the speci cation BC : Bar P=AB.Q

says that the end point of side AB is identical to the rst point of side BC , i.e. sides AB and BC have a common point. Bindings can be considered as syntactic sugar, i.e. they can be syntactically easily transformed into the remaining part of the language, except for the case where type variables are involved. Bindings enable us to write speci cations in a shorter form. Let us compare the last class speci cation with another equivalent one where identity of points is de ned explicitly using equation. triangle : ( var AB, BC, CA : Bar ; perimater : num; rel AB.Q=BC.P; BC.Q=CA.P; CA.Q=AB.P; perimeter=AB.length+BC.length+CA.length);

Despite of dierent syntax, in both cases, the identity relation AB.Q=BC.P generates two equations, one for both components of the point: ABC:AB:Q:x = ABC:BC:P:x and ABC:AB:Q:y = ABC:BC:P:y. Both equations, in turn, generate 2 constraints as this was described in Sec. 1.3.2.

1.4 Speci cation of Computational Problems NUT performs partial constraint satisfaction by means of algorithms for structural synthesis of programs ([Mints and T~ougu 1983] and [T~ougu and Uustalu 1993]). A request for program construction can appear in the NUT system in dierent forms. First, we discuss the simplest and generally applicable form. A message of the following form can be sent to any object x in the NUT system: x.compute(y,..., z)

1.4 Speci cation of Computational Problems

13

where y,..., z are components of the object x. This is a request to compute values of y,...,z and to save these values in the object x. In order to compute the values of y,...,z, the class of x, extended with the already existing values of components of x will be used as a speci cation of this problem. This message fails, if some of components in the list are not computable from the given speci cation. Let us consider the following class declarations. Class circle : ( var a, d, p, S : num; rel d= 2 * r; S= pi * r ^ 2; p = 2 * pi * d ); Class square : ( var a, d, rel d^2 = S = a p = 4

p, S : num; 2 * a ^ 2; ^ 2; * a );

Class problem1 : ( var q : square; c : circle; rel c.d=q.a; q.a=13; x=q.S - c.S );

Now, after creating an object fig by means of the following statement fig:=new problem1

we can compute the solution of the problem shown in Fig. 1.4 simply by sending the message fig.compute(x).

The list of components in parentheses may be empty: fig.compute().

In this case, all components which are computable will be evaluated and the values will be kept in the state of the object fig. The message compute with empty list of components never fails. Another possibility to specify a request for program construction is to ask for automatic synthesis of a method.

14

1. Constraints in NUT

a=13 Fig. 1.4.

A computational problem

If a class speci cation contains sucient information for computing components y1,..., yn from other components x1,..., xm, then a method, let us call it r, with the axiom x1,..., xm ?! y1,..., yn can be synthesized, using the following speci cation in the relations part of the class: r: x1,..., xm -> y1,..., yn {spec}

The keyword spec in the program part is a request for sythesizing a program from the class speci cation where this keyword is being used. The input and output variables of the program are given in the axiom of the method. As an example, we can extend the class problem1 by adding there a method for computing the value of the desired result : Class problem2 : ( var q : square a=13; c : circle d=q.a; rel result: -> x {spec} x=q.S - c.S );

Now the following sequence of statements will compute the result: fig:=new problem2; fig.result()

In order to set a program which solves the problem for an arbitrary value of the side of the square, we have to drop the binding a=13 in the speci cation of the class, and add the input variable q:a into the axiom of the method result: Class problem3 : ( var q : square; c : circle d=q.a; rel x=q.S - c.S; result: q.a -> x {spec} );

Then we can write

1.5 Some Important Extensions

15

fig:= new problem3; fig.result(13)

for computing the desired result for the side x of the square. One can add more methods of this kind to the class problem1, for example: Class problem4 : ( var q : square; c : circle d=q.a; rel x=q.S - c.S; result: q.a -> x {spec}; reverse: x -> q.a {spec}; fromradius: c.r -> x {spec} );

However, in general, every method of the form r: x -> y {spec}

can be modelled by an assignment and the message compute, as shown below for the method reverse in an object w of the class problem4: w:= new problem4; w.x(13); w.compute(q.a);

1.5 Some Important Extensions 1.5.1 Variables of Type any In this section we describe some important features of NUT language which give it exibility for speci cation of constraints. The type variable any provides an interesting form of polymorphism to the language, which can be used in object-oriented computations as parametric polymorphism, but has a more general interpretation in speci cations - components of an object of type any can be referred to before the type of this object will be concretely speci ed. The following class represents computationally a concept of maximum of a function. It can be used in a combination with any class representing a function which has numeric components arg, val for representing argument and value of the function. Class max : ( var argmax, maxval:num; fun:any; rel r:(fun.arg -> fun.val) -> argmax, maxval {g} );

16

1. Constraints in NUT

where g is a method for nding maximum of a function. For example, if a function is represented by the class Class f : ( var arg,val:num; rel val= 1 - arg ^ 2 );

then the following class speci es a problem of nding maximum my of the function represented by f and the value of the argument mx at the maximum of the function: Class problem5 : ( var mx,my ; num; function : f; m : max fun = function, argmax = mx, maxfun = my );

1.5.2 Higher Order Functional Constraints Let us look at the implementation of the method r in the class max: r:(fun.arg -> fun.val) -> argmax, maxval {g};

The axiom shows us that the program g, which is an implementation of the method, has one argument and this argument must be a function. The program g can be written directly in the NUT language. It will contain statements which call its functional argument. These statements are called subtask statements of NUT, because a nested implication in an axiom de nes a subtask in program construction. In the present example, this is the subtask of nding a function for computing fun:val from fun:arg, de ned by the implication fun.arg -> fun.val

In a program, the subtasks are referred to by the number showing their position in the axiom of the program, and their calls have the following form: subtask ()

The integer is the subtask number, parameters are passed positionally by value to the variables in the subtask. The subtask statement subtask 1(x, y)

in the text of a program g means a call of the function for computing fun:val from fun:arg synthesized automatically on the class where the method is described. Value of x is passed to fun:arg and, after the execution of the function, value of y is received from fun:val. There are two kinds of subtasks with subtle but important dierence in semantics. A subtask which has the form

1.5 Some Important Extensions

17

[ -> ]

in an axiom, and has been used above, requests the synthesis of a program on the current state of the object where the method is executed, i.e. it takes into account all values of components available at this time. Another form of the subtask is [ |-- -> ]

This subtask requests synthesis of a program on a new object of the given class and uses purely the properties of the class, ignoring the environment where the request was given. We demonstrate the usage of a higher order function on an example of a class map which models the corresponding functional operator, i.e. it computes an output array b, mapping the function onto elements of an input array a and applying it to them. A virtual component mapfun represents the function implicitly. The function must be synthesized according to the subproblem [mapfun.arg -> mapfun.res].

The object mapfun has class any, but it must contain components arg and res which represent argument and result values of the mapped function. Class map : ( var a,b:array of num; vir mapfun:any; rel r:[mapfun.arg -> mapfun.res] a -> b {for i to length(a) do x:=a[i]; subtask 1(x,y); b[i]:=y od} );

By describing other functional programming operators: lter, reduce etc., one can easily develop a set of concepts for functional programming in NUT. However, syntax of this functional language will be dierent from the conventional syntax of functional programming languages.

1.5.3 Production Rules Using purely functional constraints does not allow us to specify abstract features of objects. To overcome this shortage NUT has been extended by Horn clause logic. This is intended for meta-level reasoning about problems and speci cations and provides generality and logical power to the NUT system. Using productions in speci cations one can represent facts and rules. Productions can be used for generating new facts and also for computations almost like in Prolog. The following are examples of facts:

18

1. Constraints in NUT -> father ( John, Jack ) ; -> father ( Jack, Jim ) ;

and this is a rule: father (@x,@y) & father(@y, @z) -> grandfather (@u, @x,@z);

The rules contain metavariables which are identi ers beginning with the character @ and denote objects of the NUT language. The rule given above enables us to produce a new fact: -> grandfather(,John, Jim)

from two given facts. The words father and grandfather denote predicates which can be:  abstract predicates without any particular realization,  names of programs,  names of classes. In the latter case they are characteristic predicates of classes and this type of predicates is especially useful for describing general laws for classes and objects. For instance, the following rule point(@u) & point(@v) -> bar(@t, @u, @v)

says that if we have two objects of the class point, then we can form a new object of the class bar. This rather general rule can be applied for extending speci cations in solving a number of geometric problems. Another example of this kind is a rule about distance on a straight line: if the distance from point A to point B is equal to L1 and the distance from point B to point C is equal to L2, then the distance from A to C is L1 + L2. With a class distance: Class distance : ( var A, B : Point; Length : num );

we can write a speci cation of the following from: R: distance A = P, B = Q:

or, more brie y: R: distance P, Q:

if we use positional binding of components of a class. (P is bound with the rst and Q with the second component.) We can use the class distance in a completely dierent way and write an atomic formula:

1.6 Summary

19

distance (@x, @y, @z) .

This formula contains three variables @x, @y, @z which can be uni ed with the objects R, P , Q of the speci cation: R: distance P, Q;

and the NUT system can transform it automatically into the following atomic formula: distance (R,P,Q).

This can be used as a fact in a production; for example, the law for distance can be written as follows: collinear(@x, @y, @z) & distance(@u, @x, @y, @L1) & distance(@v, @y, @z, @L2) -> distance(@w, @x, @z, @L1 + @L2);

This production means that whenever there are three collinear points @x; @y; @z and there is a distance @u of the length @L1 between the points @x and @y, and another distance @v of the length @L2 between the points @y and @z, then a new speci cation for distance can be introduced automatically for the points @x and @z.

1.6 Summary Development of NUT is an attempt to incorporate constraint programming into an object-oriented programming framework. This has been done by 1) using classes as a source of information for constraint satisfaction; 2) introducing a special type of messages - the compute messages, which are requests for automatic program construction and execution. This is a dynamic way to apply program synthesis, when existing values of components of objects are taken into account. Methods can be synthesized also purely from class speci cations, not taking into account the previous results of computations. This is done, when the keyword spec is being used as a body of a message. This is a static approach to program synthesis. Synthesized programs can appear as values of parameters of methods, adding a avour of higher-orderness to the language, which gives us the most dynamic way to synthesize programs.

Acknowledgements We are much indebted to Mari K~opp, Mihail Matskin

and Benjamin Volozh for polishing the present version of the NUT system. We wish also to express our gratitude to our other colleagues at the Estonian Academy of Sciences by whom the rst version of NUT was designed and implemented. The authors would also like to thank Tarmo Uustalu for our fruitful discussions on the NUT system and many helpful comments on this paper.

20

1. Constraints in NUT

References

[Freuder and Wallace 1992]Freuder E.C., Wallace R.J. (1992) Partial Constraint Satisfaction. - Arti cial Intelligence, 58, pp. 21{70. [Jaar and Lassez 1987]Jaar, J., Lassez J.-L. (1987) Constraint Logic Programming. - Proc. of the 14th ACM Symposium on Principles of Programming Languages. Munich, pp. 111 { 119. [Kalja and Pahapill 1992]Kalja, A., Pahapill, J. (1992) Small Knowledge CAD Systems. - Information Modelling and Knowledge Bases III: Foundations, Theory and Applications, IOC Press, Amsterdam, pp. 347{356 the 14th ACM Symposium on Principles of Programming Languages. Munich, 1987, pp. 111 { 119. [Kotov et al. 1989]Kotov, V., Nariniani, A., Tyugu, E. (1989) The USSR Academy of Sciences START Project. - Information Processing 89 (IFIP'89). North Holland, pp. 623 { 626. [Mackworth 1992]Mackworth A.K. (1992) The Logic of Constraint Satisfaction. - Arti cial Intelligence, 58, pp. 3{20. [Matskin 1991]Matskin, M. (1991) NUT System papers. - Computer Science Department. Aarhus University, DAIMI MD { 59. [Matskin and T~ougu 1992]Matskin, M., Tyugu, E. (1992) The NUT language. TRITA-TCS-SE-92-TR. Royal Institute of Technology, Stockholm. [Mints and T~ougu 1983]Mints, G., Tyugu, E. (1983) Justi cation of the Structural Synthesis of Programs. - Science of Computer Programming, 2, no.3, pp. 215 { 240. [Mints and T~ougu 1988]Mints, G., Tyugu, E. (1988) The Programming System PRIZ. - Journal of Symbolic Computations, 5, pp. 359 { 375. [Mints and T~ougu 1990]Mints, G., Tyugu, E. (1990) Propositional Logic Programming and the PRIZ system. - Journal of Logic Programming, 9 no.2-3, pp. 179 { 194. [Penjam 1990]Penjam, J. (1990) Computational and Attribute Models of Formal Languages. - Theoretical Comp. Sci., 71, pp. 241 { 264. [Saraswat 1990]Saraswat, V. (1990) Concurrent Constraint Programming. - Proc. of the 17th ACM Symposium on Principles of Programming Languages. San Francisco, pp. 232 { 245. [Smolka et al. 1993]Smolka, G., Henz, M., Wurtz, J. (1993) Object-Oriented Concurrent Constraint Programming in Oz. - DFKI RR-933-16. Saarbrucken. [T~ougu et al. 1986]Tyugu, E., Matskin M., Penjam J., Eomois P. (1986) NUT - An Object-Oriented Language. - Computers and Arti cial Intelligence, 5, no.6, pp. 521{542.

22

References

[T~ougu 1988]Tyugu, E. (1988) Knowledge-Based Programming. - Addison-Wesley, N.Y., 1988. [T~ougu 1991]Tyugu, E. (1991) Three New-Generation Software Environments. - Communications of the ACM, 34, pp. 46{59. [T~ougu and Uustalu 1993]Tyugu, E., Uustalu, T. (1993) Higher-Order Functional Constraint Networks. - In Constraint Programming. NATO ASI Series F:Computer and Systems Sciences, (see this volume).