Knowledge-based programming environments

Knowledge-based programming environments E Tyugu This is a survey presented at the International Joint Conference on A I (IJCAI-89) in Detroit on Soviet work in the field of knowledge-based programming. It considers work which started in the 1970s as automatic programming projects with a goal to find new ways of program construction and, particularly, the work on computational models and problem solving. The structural program synthesis and conceptual programming technique developed in this framework were later used in the new generation computer project, START. Keywords: knowledge bases', programming environments, program synthesis', declarative programming Building knowledge-based programming environments is a field of artificial intelligence and its application which has achieved some maturity in the Soviet Union. This paper considers the knowledge-based programming environments and, in more detail, the conceptual programming systems which are a family of programming environments developed during the past ten years. Some ideas are presented of the logical basis of these programming environments. It is referred to as propositional logic programming, because it is a kind of program construction where propositional logic is used. A survey of Soviet projects of knowledge-based systems will be given as well. First of all, programming environments, not just software engineering environments, will be discussed. Topics such as documentation, project management and general tools not directly connected with programming will not be considered. A view of a program will be very pragmatic; a program will not be considered as a clever expression or a text. Instead, a program will be regarded as a large modular item, which is like an iceberg hidden in a computer, so that only a top of the iceberg will be visible to the user who just gives input and gets output and does not want to bother about all the parts of the program inside the computer. Our conjecture of a

modular program is represented in Figure 1. The intention, therefore, is to build such large icebergs, putting together the modules, small and large, glueing them together by means of different computer commands. The approach to program development used here is called conceptual programming because it is essentially the usage of concepts in programming. New concepts are defined and used for specifying problem conditions, i.e. for giving specifications from which programs can be built, then the computer is relied on to get the program ready and to run it. These activities can be divided into two separate stages: one is specifying concepts and the other is specifying a problem in terms of knowledge of given concepts. The characteristic features of this approach are: • using a knowledge-base actively, • programming completely in terms of problem domain, • using a computer in the whole problem-solving process, beginning from the description of a problem itself and, • synthesizing programs automatically.

"~

vislble part

Institute of Cybernetics of Estonian Academy of Sciences, 21 Akadeemia tee, Tallinn 200108, Estonia, USSR Paper received 4 October 1990. Accepted 29 October 1990

4

Figure 1. User's view of a large program

0950-7051/91/010004-04 © 1991 Butterworth-Heinemann Ltd

Knowledge-Based Systems

Let us settle formally here what is a problem statement. This is an expression of the following form: Ml-x~y which means 'knowing M compute y from x'. This definition restricts the class of problems which we can handle to the computational problems. However, here are some examples showing that these computational problems themselves can be quite different: 'knowing triangle, compute alpha from a,b,c' 'knowing staff, compute young-employees.' Looking at the sources of experience for building knowledge-based programming environments, we can see that the field of knowledge-based environments is the focus, where experiences gained in artificial intelligence, in software practice and in theoretical computer science meet (see Figure 2). We have to use the results of these different knowledge domains for building knowledge-based programming environments. The AI field provides us with knowledge representation needed for problem solving, and with search methods for theorem proving which is needed if we prove solvability of the problem and then extract the program from the proof. We can also use experience of knowledge engineering gained in building expert systems. In the software field, abstract data types are quite close to a knowledge representation language. Objectoriented programming gives us ideas for developing programming environments. Logic programming itself can be called knowledge-based programming. All the other functions of programming environments which are not connected with program synthesis, for instance debugging, are handled in the software

field. Intelligent software packages have been investigated in the Soviet Union for more than a decade. This work started on old clumsy mainframes and was usually done by large groups of researchers, but it has real applications, e.g. in computer-aided design, and new tools for developing large programs have evolved from this field. Finally, theoretical computer science provides experience in formal specifications, program transformation and synthesis as well as in semantics and computational logic. Figure 3 shows how one and the same text can be perceived in different fields. There is a text about a device that could be called a cooler. This is a device for heat exchange. An engineer would call the text in this figure a mathematical model of a device. In the software field, it can be considered as a text of an abstract data type. Actually, we call it the computational frame of the cooler. A computational frame is a special kind of frame that we can efficiently use for computational purposes.

ARCHITECTURE OF KBPES There are three levels of knowledge application for programming (see Figure 4). The lowest level means encoding of algorithms or making programs which can be directly run on some particular computer. Making efficient programs means also program transformation and optimization. Here, the local optimization of assembler code of superconductors done by means of expert systems could be mentioned. There are also several works which consider automatic programming as developing executable programs from given specifications which are more or less algorithmic representations of problems and close to programs themselves 1. T21 Tll

AI:

• knowledge representation • search

• theorem proving • expert systems • knowledge engineering

DTI,WI,cI,QI SOFTWARE: • abstract data types • object oriented programming • logic programming • programming environments • intelligent software packages

)

DT2,W2,c2,Q2

T22

T12

cooler:

THEORETICAL COMPUTER SCIENCE: • formal specifications • program transformation &synthesis • semantics

• computer logic

Figure2. Sources of experience for building knowledge-based programming environments Vol 4 No i March 1991

(TII,TI2,T21,T22 : temperature; DTI,DT2 : tcxnperature; Q1,Q2 : heat; el,c2 : speclfic_heat; WI,W2 : Volume_velocity; QI+Q2=O; QI=DTI*cl*W1; Q2=DT2*c2*W2; DT1=T12-T11; DT2=T22-T21 )

Figure 3. Model, data type or frame? 5

USER INTERFACE

~

LANGUAGE UNDERSTANDING

PROGRAM PLANNER .

.

.

.

.

_

.

.

.

SYNTHESIS

- - ~

PROGRAM GENERATOR (PROCESSOR INTERFACE

PROGRAM TRANSFORMATION AND OPTIMISATION

Figure 4. Three levels of knowledge application Work where the selection of different data-representations is considered should also be mentioned here 2, 3. The central part of programming is certainly building the algorithm itself, using problem-domain knowledge. This activity is known as the program synthesis. Well-known work in this direction belongs to Manna and Waldinger 4 who have been working on deductive program synthesis. Besides that, it is possible to synthesize programs inductively, i.e. from examples 5-7. The part which is closest to the user is the intelligent interface which requires yet another kind of knowledge-linguistic knowledge for natural language interface, or knowledge about dialogue for highly interactive interface s . This paper is mostly concerned with the second level which is the central part of a problem-solving system. However, as we build practical software systems, we must also consider efficiency of synthesized programs as well as user interfaces. All three different knowledge application levels are therefore needed in a programming environment. Looking at one or another of the three parts of a KBPE, we can see the knowledge flows as shown in Figure 5. • • • •

knowledge introduction, problem specification, using given knowledge, getting explanations.

A knowledge base is used in all these activities. A complication here is that we have several knowledge bases and several levels of knowledge applications. Hence we have an intricate picture where several schemes similar to Figure 5 are combined and have interrelated knowledge flows. A user does not like to know too much about the internal structure of the system. Therefore we need a simplified model of a KBPE for users. A user's view of 6

a small knowledge-based environment, called MicroPriz 9 is shown in Figure 6. We can see only one knowledge base, however it contains all three kinds of knowledge mentioned above. The user understands that the first activity is specifying new concepts and the second involves using these concepts for solving problems. This means that most of the knowledge flow is hidden from the user. However, sometimes, particularly when a specification has to be debugged, a more detailed model of a KBPE is needed. The debugging in this case is quite different from conventional debugging of a program - it is debugging on a very high conceptual level, i.e. debugging of concepts. This is needed in case the problems are unsolvable. Let us look at a small example to see how concepts can be used in problem solving. Let us take the following problem from physics: 'A mass of 700 kg falls from 3.5 m height and pushes a pole 5 cm into the soil. Find the force applied to the pole by the mass.' Its formalization in the input language of MicroPriz is as follows: xl motion m=700 s=3.5 a=9.81 x2 motion m = x l . m s=0.05 v = x l . v ?x2.f This is a problem of a falling mass, and it is essentially about two accelerating motions. Having a concept of motion, we can use it for specifying the phases of motion of falling mass: firstly, acceleration and secondly, deceleration, giving the parameters of processes contained in the text. We were able to give a complete specification of this problem in two lines. The procedural part of the text is the problem statement 'compute f of x2', which is expressed in the input language of MicroPriz as ?x2.f. In order to use the concept of motion, we have to Knowledge-Based Systems

I

I

4

2

2

User interface knowledge base

Problem solver programming

system

I

i 2 3 4

Knowledge introduction Problem specification Reusage of knowledge Explanation

Figure 5. Knowledge flow specify it. The complete specification of this concept in the input language of MicroPriz is *motion f=m*a v=a*t s=v*t/2 s = a't^2/2 This is almost a minimal text about this concept. It is syntactically quite close to the mathematical model of the physical process itself - that is essential for a user. Having this specification, one can solve a number of problems concerning motion. Now a few words about an experiment that I have done. I had a young lady in my department who was a student from the Tallinn Technical University. I asked her to solve on MicroPriz all the problems in physics given to her at the university during one term. It appeared that students were given two or three new concepts a week. They had to use them, and almost all the computational problems could be solved this way. That shows that we can encode computational knowledge very easily in that kind of environment. It would not be realistic to hope that we can specify larger programs in the same way. What we actually need to do is to combine this kind of knowledge-based programming of simple computational parts of programs with conventional programming of intricate algorithms. We have built a programming system Priz ~° which includes, besides a program synthesizer, a conventional programming part enabling us to use Fortran, Cobol and assembler language. The overall structure of the Priz system is shown in Figure 7. The Vol 4 No 1 March 1991

specifying new concepts

2 specifying a n d solving p r o b l e m s Figure 6. The MkroPriz system program synthesizer uses problem specifications from a library and expands problem statements introduced into source text written in Fortran or assembler language. This means that we have extended the conventional languages by a new statement - the problem statement. The expansion of a problem statement goes as follows: the synthesizer synthesizes an algorithm, then a real program is compiled and we get a new program module, which will be called from the point where the problem statement was in the program. Another way to extend the capabilities of a computational problem solver is to use it together with an expert system for making decisions during the problem specification and computational phases. Using this, we have developed a new system which we call Expertpriz 11 (see Figure 8). It contains an expert system shell which handles the expert knowledge base. It also contains a problem solver which is the Micropriz. These parts interact in the object-oriented way, sending messages to one another. This system is a product on the market in the Soviet Union and in Europe.

REPRESENTING KNOWLEDGE ABOUT COMPUTABILITY Knowledge representation and knowledge usage in our programming systems will now be examined more closely. We can take a connectionist approach and say that we specify computational frames which are actually semantic networks. They are put together from the building blocks shown in Figure 9. These blocks are: • Functional dependencies where the output (z) depends on the input (x and y). • Operator dependencies which are different from functional depedencies in the sense that their argu7

Conventional programmi ng1 system

User interface

~

~

User interface

l

[ / Problem System ~--I~ statement interface I / m°di ~

/

-1

MlcroPRIZ

MieroEXPERT

question

Synthesizer

Program Figure 8. The expertPriz system

Figure 7. The Priz programming system Functional ments can be functions; the function needed here is for computing v from u. This function is not given in the operator dependency, but we have a slot with parameters u and v inside it and we can put another computational frame into this slot that explains how to compute v from u. • One more building block is a structural relation. • We can also use equations as sources of functions. The example of an equation here binds u, i and r and enables us to compute each of these variables from the other two variables, i.e. it represents three functional dependencies.

X y

8

>

Operator dependencies :

~Z

Structural relations :

point

x ~ An example of a computational frame of a particular problem is given in Figure 10. This is a minimax problem where computing the minimal value of maximal values of elements of rows of a matrix is required. H e r e we have a slot for a matrix, and when we substitute a particular matrix into the slot, we can build the program automatically, just using the dataflow considerations. It is quite easy to understand how to do that, because the arrows show how the data flow must go. However, already here we get nested loops in the resulting program, one loop for finding maximums in rows and another loop for finding a minimum. The same meaning of specifications which we expressed by means of sematic networks, can be expressed in formal logic. It has been demonstrated that our program synthesis is being done exactly in accordance with the laws of constructive logic 1°. We can also speak here about deductive program synthesis, which means the following. We have a problem specification, and we transform this specification into a logical

dependencies :

Equations :

i

y

u

Polymorphic slots with partially specified paprameters :

Figure 9. Building blocks of computational frames

theory. Then, having a problem which can formally be represented as a formula, we prove this formula constructively and extract the algorithm from this proof. In any case, we have to express in a logical language that we have some p r e p r o g r a m m e d functions or building blocks for building programs. One can even

Knowledge-Based Systems

A--~B B--*D g

matrix i 4

Gm

mtmmax

A f.--~,gD (A--~ B) ---->(C z--~D) A---~Bg

j./

C V-~g)D

~m~m a x i n r o w

Actually, we use more complicated inference rules, because we need conjuctions for representing functions with several arguments: A-~,B B&C --> g D

Figure 10. Frameof minimax problem start from very primitive functions like addition and multiplication, but nevertheless, one must have some functional constants. In a general case, one can specify these constants, telling what is the precondition P and what is the postcondition R of the program one has; this gives the formula Vx(P(x) ~ ~qyR(x,y)). It means that having input x, satisfying the precondition P, you can get an output y satisfying the postcondition R. In the case of Prolog, this formula is simplified, a precondition is not given at all, and the atomic formula R(x,y) expresses the computability of y from x. In the Priz system, we simplify this axiom in another way and use a formula where postcondition contains only output variable: Vx(P(x) ~ ayR(y)). This is certainly a restriction of the language. In this case, we can transform the axiom to the form ~axP(x) ~ ~IyR(y). Now we have closed formulas on both sides of the implication, and that means that we have actually a propositional formula X --->Y, which means 'given x we can find y'. This simplification is too severe a restriction on language and we use a slightly more general language which is still propositional. We call it the language of propositional logic programming. This language contains implications which have the logical meaning: 'A implies B', but they have also the computational meaning: 'B can be computed from A'. We use more complicated formulas to express operator dependences; these are nested implications 'if B can be computed from A, then D can be computed from C'. Actually, we also need conjunctions of arguments and now this is the whole language. It is very easy to extract programs in the form of lambda-terms from proofs in this language. We can extend the language immediately just showing under the arrow of an implication A--->B a program (a lambda-term) which computes B from A. This is the realization of the logical formula A --> B. So we actually get a language which binds logics and programs. The inference rules which are sufficient for the case without conjunctions are very simple: Vol 4 No 1 March 1991

A&C ~ B&D ( A - ~ B ) ~---~FCA&E--OBg

E~C A -7> B&C

A f;se--~ectBB ' where X is an abbreviation for X~ & X~ & . . . & Xy or X~,X~ . . . . . X:,; X~, X/3. . . . . X,~, being of the same structure as the formula X. It turned out that the implicative language (with conjunctions) which we have introduced has sufficient expressive power for representing any theorem of the intuitionistic propositional calculus. By introducing new variables for subformulas and using equivalence replacement threorem, any formula of the intuitionistic propositional calculus can be reduced to a set of formulas in our language. As a corollary, we get the estimate for the complexity of program construction by means of our inference rules. This problem is P-space complete - the time needed for providing depends exponentially on the length of the set of axioms. Now we can represent the example of the minimax problem in our logical language. Specification in the logical language consists just of three axioms: for getting an element, for constants of maximum and minimum: M&I&J ~ E (J -~ E) ~ a x MAXINROW (I-~ MAXINROW) ;~in MINIMAX The proof of the goal M ~ MINIMAX is the following:

(J -~ E) ~.~naxM A X I N R O W M&I&J ~et E (I --*¢MAXINROW) ~ . n MINIMAX M&I max--~get)M A X I N R O W M

rnin(max~get)) MINIMAX

The precise program in the form of a lambda-term is the following: Am min (Ai max(~.j get(m,i,j))). We were surprised that having worked for a long time in a connectionist world, w e obtained from logicians a very clear and sound logicallexplanation of what we did. 9

SPECIFICATION LANGUAGE

.~'m ( x: t) = X. s e m ( t)U { X ->X.Y . . . . . X -> X.Z, X. Y& ,..& X. Z > X ,

The input language of our systems will now be considered. We have used the input language already for specifying physical problems. It contains three kinds of statements (see Figure 11).

where Y..... Z are propositional

sere (t),

for the inheritance - e m p t y , ff

• The basic statement is for stating that some new object a is of type t, and it is written a:t

variables

from sem (t) x : t, i s

t is a primitive object.

sere(s), if t has been specified

a s t : s.

seirl (Sl: .., ; Sn ) = s e I n ( S I } U ... U seli1 ( S )

• In a more complicated case, one has amendments in addition, where one can give values for parameters and fill in slots. • One can have a straightforward specification of something which is called 'a' here, giving superconcepts, using inheritance mechanism, specifying components, again in the form of specifications and giving specifications of properties by means of relations. In our case, the relations are functional dependencies, equations and operator dependencies

s e r e ( s u p e r x) = s e r e (t},

sem(r:x

where

t comes from x : t

..... x ->y ..... y (f))= 1 k 1 m

: Ix~...

scm(E(x

~x

->Y~...

~YI

..... x)=O)={X&...&X 1 n 1 where

&X

I-1

&,,.&X->X 1+1 n

E { ... ) = 0 is s o l v a b l e f o r -

i

x } i

Figure 12. Semantics' of specifications It is surprising that this language actually has very precise semantics; we can translate any text of this language into a set of axioms 1°, using rigorous rules as shown in Figure 12. Even more, when we became acquainted with intuitionistic type theory, it appeared that we had invented a user friendly language of the type theory 12. That means that texts in our input language can be considered as expressions of the type theory as shown in Figure 13. We now have a very precise logical explanation to what we actually have done from practical considerations. Figure 14 shows the summary of the logical basis of the conceptual programming systems. We have specifications of concepts in the user-friendly language. These specifications are transformed into expressions of intuitionistic type theory which are not visible to a user. These expressions can be converted into a set of

a:t

. I

a

is

x E T . .... y E S a'(x:t;

... ; y : s ) a E (TX... x s ) x E T , .... y E S

r'x ->y r E (T -> S )

tET a't (a.)t E T

tET

t"

a't

c----d... e=f { d / c ... f/e) (au)t E T

Figure 13. Specifications as types i

~//a : t

b1=v l,

\ \

"\

bk=vk

f

l 1

\

amendments

n a m e o f the k new object \

& bindings

( ~

is

bl

of

bk

R]....Rk; ) '

yl ..... known

ym,

vl

of

a

is

vk "

are

names

of

or concepts

are

or preprogrammed

relations,

i.e. equations

functions

axioms in propositional language, giving a constructive theory about the concepts and the problems we specify. The system must prove the solvability, i.e. that the result can be computed from the input of the problem. This proof is transformed into an algorithm and so we can get a program. That is how it works logically.

CONCEPTUAL PROGRAMMING TECHNIQUE

- components

tl . . . . . t n

Figure 11. Specification language 10

is

i ~properties

objects

R1 . . . . . R k

a

where

supereoncepts

y l ..... y m ;

x l : tl ; ... x n : tn ; I

where

t"

*'°

it's type (class)

a :

a

Figure 15 contains a problem description from mechanics, and also specifications needed for solving the problem. It explains how conceptual programming is used for problem-solving. We usually have to specify concepts which are the same as classes in the object-oriented programming. In this example, it is useful to specify the concept of Knowledge-Based Systems

specifications of concepts

•._ expressions o f " intuitionisflc type theory

specification of a problem

a constructive theory

problem statement

solvability proof

algorithm

program

Figure 14. Logical basis of conceptual programming y

B

active filters in electronics. In this case, one has to specify a set of concepts which represent the knowledge about the whole problem domain so that each problem of the domain can be specified using these concepts. Let us take as an example a package for analysis of alternating current circuits. An example of a problem is represented in Figure 16 where an oscillator os is specified and used as a superconcept for specifying a particular oscillator osc with given parameters: R = 22 Ohm, L = 30 H and C = 0.00001 F. To be able to specify problems of this kind we need the concepts of capacitor (cap), inductor (ind), resistance (res) as well as concepts of fragments of circuits: parallel connection (par) and series connection (ser) of branches which are called ports. We start building our package from basic concepts of complex numbers, multiplication of complex numbers and a concept of port which contains Ohm's law (see Figure 17). Here we use a new feature of the

°

I

R! i point: (x, y: n u m e r i c )

Pq

line:

(p, q: I, a I^2 I *

point; : numeric; = (q.x - p.x) ^2 + (q.y - p.y) A2: eoslal =(q.x-p.x)

L o

os: (Xl : res; X2: had; X3: cap; X4: ser xl =Xl, x2=X2; X5 : par xl =X4, x2 =X3)

C

T

R I~ : n u m e r i c ; super port ; super os ; Xl.r= R; X2.L=L; X2. g=u; X3.C= ~, X3.~= ~;

o s c : ( L, C,

J

mech: (u,v: n u m e r i c ; AB: l i n e l = 1.1, p = (0,0), a = u ; BC: line l = 1.7, p = AB.q, q .y = -0.4, q.x = v)

i =XS.i ; u =XS.u;

z=XS~; g=XS.g )

o

m: m e c h

u = 30 t-- rn.v

[

I

Figure 15. Problems from mechanics Y:osc

point and the concept of interval of a straight line between points p and q, having length 1 and angle of inclination a. Some geometrical properties of the interval are given by equations. The whole specification of the mechanism is in three lines, and the problem itself in this case contains only two lines. We can therefore work in a bottom-up manner, starting from the point and interval and specifying a mechanism represented by two intervals thereafter. We could do the same in a top-down manner as well, starting with the specification of the mechanism in terms of intervals and only after that thinking about what the interval must be and what the point has to be. Both ways are possible. We can also specify more complicated problems about the mechanism. If we have a concept of maximum, we can ask what is the maximal distance that can be reached by the slider. A specification of this problem is as follows: m: mech mm: max arg = m.u fun = m.v ?mm.res

R=22,

L=30,

C=0.00001;

Figure 16. Specifications of oscillators cmpl : ( re, im : numeric; vir ar~ mod : numeric ; mod^2 = re~2 + im^2 ; m o d * s i t , are) = n n )

Vol 4 No 1 March 1991

i

mult : ( vir xl, x 2 , x : compl; x.mod = x l . m o d * x2.mod; x.arg = xl.arg + x2.arg )

port : (i, u, z : cmpl; vir g : cnapl; r l : mult x l = z, x2=g, x.mod= I, x . a r g = 0;,

Conceptual programming is being used for building engineering software packages and also software for computer-aided design, for instance, for designing

im ~ m o d

r2 : mult x l =i, x2=z,

-

re

X2

c

U W

N ~.

z-g=l u=i.z

X=U)

Figure 17. Complex numbers and Ohm's law 11

specification language - virtual components. These are components which can be used in computations but are not parts of the value of the object. For instance, according to the given specification, the value of a complex number consists of real and imaginary parts (re, ira), but argument (arg) and modulus (rood) of a complex number can be used in problem specifications and computations as well. ~;pecification of the package is completed by specifying the concepts ser, par, cap, ind and res as shown in Figure 18. Having these specifications, one can understand precise computational meaning of specifications of oscillators given in Figure 16. This completes the specification of a small but practically useful engineering software package. Up to now the problems written in the source language have been demonstrated, which can be solved very fast and easily, because as can be guessed, solving them requires only the usual constraint propagation technique and we have a very fast method for constraint propagation. It works in linear time - that is the time depends linearly on the size of the text of a theory. If we have operator dependencies (i.e. subproblems), the things are more complicated. Nevertheless, work has been carried out in applying conceptual programming in different fields which need the usage of operator dependencies~3. One field is building compilers and interpreters. This is an exciting problem: having a precise specification of

a programming language (specification of its syntax and semantics) to implement this language automatically. i.e. to build either an interpreter or a compiler automatically. A small example of doing that in conceptual programming style is given in Figure 19. The example language is syntactically very simple - j u s l three production rules for putting together texts. These texts represent electrical schemes containing series and parallel connections of resistors. The semantics of a text can be given in the form of computational frames. In Figure 19 we have an attribute grammar which represents attribute semantics of the language. It contains attribute models ml,m2,m3 of the three productions pl,p2,p3. These semantics can be used for computations directly, if one has implemented the syntactical part. A parsing tree is obtained from the syntactical part, and then for every production which has been used its attribute model is substituted. A complete model of the problem is obtained (Figure 20), and the problem can be solved. It has been proved that a large class of attribute grammars can be implemented this way 1~. Another field where we can use conceptual programming is database management. Using this approach, we separate the logical part of database management from the data handling part. This means that if we have programs for handling files, getting data and putting them back into files and some other program modules needed for handling files, then the logic behind using

Syntax: cap : ( ~upcr port; , C : numeric: g.m=O; g.im= w . C ) ind : ( super port; w , L; numeriq" 7~re=O; z.im= w . L) r e s : ( super port ; __~ r : numeric" xre=r; ~im=O }

p 1: s c h <- p a r ( s c h ,

_[_ --]-- C ° °

k ~

L

sch )

p2:

s c h <- s e r ( s c h ,

sch )

p3:

s c h <- r e s ( n u m

)

o °

Example:

J. ~ r

ser(res(

1 ), p a r ( r e s ( 2 ) , r e s ( 2 ) ) )

o

Semantics: par : { s u ~ r port; __~ xl, x2 : any; g.re = xl.g.re + x2.g.re ; g.im = xl.g.im + x2.g.im; Lre = x l . t r e + x2.i.re; i.im = xl.i.im + x2.i.im; u =xl.u; u =x2.u)

ser

: { suoer port ; vir xl, x2: any; z.re = xl.z.re + x2z.re; z.im = xl.z.im + x2.zAm ; u.re = xl.u.re + x2.tzre ; tLim = xl.u.im + x2.u.im ; i=xl.i; i=x2.i)

i-> o

U Xl

W

X2

);

m2 : (res: num; vir cl: num; (:2: n u m ; r e s = c l + c 2 ); i-->

U W

Figure 18. Components of electric circuits 12

~

m l : (res: n u m ; vir cl: hum; c2: n u m ; 1/res=l/cl+l/c2

~

o--t

X 1

m3: (res: num; vir c l : text; res=val ( c 1 ) )

Figure 19. An attribute grammar Knowledge-Based Systems

r--L1

2 0 ¢2 Parsing tree :

prog

/

/'

\\\

,

ser~ r ~ i ~ l ~ ! p a r {~res~i~2e~. ; 6 : 1 ~ ~) Semantic

model of the text : sem : (node1 : m 3 c i = ' 1 " ; node2 : m3 c1='2" ; node3 : m3 ci='2" ; node4 : m l cl=node2, c2=node3 ; prog : m2 c1=nodel, c2=node4 ) sem !-- prog.res Figure 20. Attribute semantics o f a specification

s e t : ( v a l :, e n c a p s u l a t e d ; vir elem : a n y ; tick : e n c a p s u l a t e d ; v a l , tick -> e l e m ( select ) I;

subset : ( super set ; vir of:set; cond : bool ; ( of.tick->t~ond, e l e m ), of->val ( S u b ) ) ; p e r s o n : (... ; age : n u m ;

... ) ;

people : set elem = person ; children : subset of = people, elem = p e r s o n , oond = ( person, age < 16 );

these programs can be explained in terms of our language. The first specification in Figure 21 gives us a concept of a set of elements of any type (this is a polymorphic concept). Due to the fact that sets with different elements can be declared, even building sets of sets and getting hierarchic data specifications is possible. The second specification represents a concept of subset, which can be obtained by filtering an initial set by computing a condition and if the condition is satisfied, then taking the element into the subset. Continuing in this way, we can specify all the known data models: network models, relational models, hierarchic models and, certainly, functional models and entity relationship models. The models need never be separated - one just has an integrated database management system. Work in this field is being done by Hele-Mai Haav in Tallinn 15, and these database management systems are incorporated into our products. The last example of using the knowledge-based approach is solving problems of dynamics of simulation, optimization and modelling. These are the problems where the basic concept has the following laws (Figure 22): the next state can be computed from a given state, input and time, and output depends on state, input and time. The basic computational frame contains two slots: for a process and for a model, and it distributes the state of a process, passing the components of the state vector to building blocks of the model, and takes back the next state and also handles the time. Having this concept, one can use different kinds of processes and models. Figure 23 shows a particular model and process called 'simulation'. The simulation itself is described here in four lines, and the model in three lines. It uses an integrator based on Euler's integration method. The way in which conceptual programming works logically has been demonstrated. Some preprogrammed modules which can be put together are always needed. It should be stressed that we separate the logical part from the computational part. The same

nextstate = F ( state, input, time ) output = G ( state, input, time ) Basic laws :

process

~- p e o p l e -> c h i l d r e n e s e t : ( ~ u p e r set ; vir key:any; val, k e y -> elem(keyselect); create: -> val(A); a d d e l e m : elem, val -> val(B); deleteelem: elem, val -> val(C}); Figure21. Specifications of sets Vol 4 No 1 March 1991

model

dyrmmics : (model : any; process : any ; process.state -> model.all.state (DISTR) ; proces.time -> model.all.time (COPY) ; model.all.nextstate -> process.nextstate(COLLECT)) Figure 22. Computational problems o f dynamics 13

I) : dynamics model = M, process = simulate ; D !-- simulation.result

C-PRIZ : •

intuitionistic type theory

•

intuitionistic propositional calculus

ExpertPRIZ : • O+ logic Whe re simulate: (state, nextstate : vector ; lime : numeric ; re~it : table ; ( state -> nextstate ) -> result (SIMUL) ) ; M : (I 1 : integrator initstate = 1 ; I2 : integrator initstate = 0 ; I 1.input = -0.5"I 1.output - I2.output ) ; integrator : ( nextstate = if time = 0 then initstate else

(state+mput);

output = state)

Figure 23. Example of a simulation problem is done in Prolog, but logic is used on the propositional level. That does not mean that it is trivial, it is a general language, because we can have constants of higher order. We can have a kind of recursion and so we can have any kind of programs or synthesize any primitive recursion function, using only three constants: 'primitive recursion', 'zero' and 'plus one'. Summarizing this section, see Figure 24. We have several conceptual programming systems: C-Priz is running under Unix and MSDOS; it relies on two logical calculi-intuitionistic type theories for user interface and intuitionistic propositional calculus for program synthesis. Another system, ExpertPriz is a small system for personal computers and it uses a so-called 0-plus logic for the expert system part; it also contains a calculus for symbolic computations which means that we can solve problems symbolically, using an algebraic form of relations. NUT-system is an object-oriented programming environment with a rather complicated logical basis 16. We have been criticized for not being able to do everything that can be done in Prolog, so we included first-order Horn clause logic as an additional part into the N U T system, but it is used not for computations directly, but for making some general inferences about the problems. We use this part of N U T for extending a problem specification itself. For example: if we have a database of persons, and for every person have his name and also know his father and mother, then we should like to ask about a grandfather of a person. It is impossible to answer this question without introducing grandfather in the person's frame in our case. However, using the Horn clause logic, we can infer additional relations from a very simple rule: 'grandfather is a father of a parent of the person'. That is the essence of the extension in N U T which allows us not to include a grandfather in every person's frame and still enables us to solve problems about grandfathers. 14

•

intta'tionistic t y p e t h e o r y

•

intuitionistic propositional calculus

•

symbolic algebra

NUT

."

•

H o r n c l a u s e logic

•

intuitionistic type theory

•

intuitionistic propositional calculus

Figure 24. Calculi of conceptual programming systems

RELATED WORK Theoretical research in program synthesis will now be considered. Much pioneering work was done in the 1970s by Nepeivoda, who demonstrated realizations of formulas of constructive logic in programming languages ~7. It is a well-known fact in constructive logic, that one can get a realization of any provable formula in the form of an algorithm or a result of computations. However, Nepeivoda showed how to get it in the form of a program in a programming language. He constructed realizations in PL/1, LISP and Algol-68. In Tallinn, Mints has investigated the classes of constructive theories which can be useful in the practice of program synthesis, bearing in mind the efficiency of the synthesis. Dikovsky in Kalinin has developed a fast algorithm for constraint propagation on computational models 18. This algorithm works in linear time, and he specified a very simple data structure for implementing this algorithm. Kanovich, also from Kalinin, gave a fine classification of theories for structural synthesis of programs and the time estimates of complexity of proof search in these theories 19. He introduced the concept of dependency of subproblems--arguments of operator dependenices. (These are the functions which must be built automatically for solving a problem.) If they are independent, then the case is almost linear. If one has subproblems of small dependency, only with dependence level 1 or 2, then the time needed for program synthesis is still acceptable. However, if the dependency of subproblems is not restricted, one gets the task of proof-search in the intuitionistic propositional logic which is P-space complete as known from logic, that means exponential time complexity. There have been some works in synthesis of parallel programs. Early work by Pospelov involved the stratification of constraints into layers to be processed in parallel 2°. It may be useful for implementation in Knowledge-Based Systems

hardware. Karzanov and Faradjev considered a problem of aggregation of relations, i.e. transformation of computational frames 2~. Plaks built sequential communicating processes on computational models 22. He used Petri nets as the underlying formalism. Valkovski and Malyshkin worked on the problem of parallel processing of arrays represented in computational models 23. One of the earliest practically useful knowledgebased application programming systems in the USSR was the system Fikhar for calculating physical characteristics of nuclear reactors 24. An ambitious project of a knowledge-based programming environment with a high-level language, Dekart, was started in Leningrad at the beginning of the 1980s. It resulted in an experimental software system Spora for an old mainframe Besm-625. This system is quite similar to Priz except that its input language is based on Pascal and also includes relational database facilities. A different kind of knowledge-based tool was developed in Novosibirsk by Levin and Nariniani 26. These are knowledgebased software factories which support the development of natural language interfaces, constraint propagation and programming in a very high-level language.

REFERENCES 1 Darlington, J 'An experimental program transformation and synthesis system' Artificial Intelligence Vol 16 (1981) pp 1-46 2 Barstow, D 'An experiment in knowledge based automatic programming' Artificial Intelligence Vol 12 (1979) pp 73-119 3 Kant, E 'On the efficient synthesis of efficient programs' Artificial Intelligence Vol 20 (1983) pp 253-305 Manna, Z and Waldinger, R A Deductive Approach

to Program Synthesis: Artificial Intelligence and Software Engineering (Ch. Rich, R C Waters, eds.) Morgan Kaufman Publishers, inc. USA (1986) 5 Summers, P 'A methodology for LISP program construction from examples' J. ACM Vol 24 (1977) pp 161-175 6 Bauer, M A 'Programming by examples' Artificial Intelligence Vol 12 (1979) pp 1-21 7 Biermann, A and Kirshnaswamy, R Constructing Programs from Example Computations Rep. OSU- C I S R C - T R - 7 4 - 5 , Ohio State university, Columbus (1974) 8 Heidorn, G Automatic Programming Through

Natural Language Dialogue: A Survey: Artificial Intellidence and Software Engineering (Ch. Rich, R C Waters, eds) Morgan Kaufman Publishers inc., USA (1986) 9 Kypp, M 'MicroPRIZ - a user friendly problem solver' Personal Computers and their Applications

Vol 4 No 1 March 1991

Tallinn: Valgus (1986) pp 29-30 10 Mints, G and Tyugu, E 'The programming system priz' J. Symbolic Computation (1988) pp 359-375 11 Koov, M 'ExpertPriz: a hybrid expert system building tool' Software Development Tools. VTT Symposium 104 TRC of Finland, Espoo (1989) pp 173-185 12 Tyugu, E 'Propositional logic programming and type theories' in: Proc. SCAI 89 Tampere University of Technology (1989) pp 988-996 13 Tyugu, E Knowledge-Based Programming (1988) Addison-Wesley, USA 14 Penjam, J 'Computational and attribute models of formal languages' Theoretical Computer Science Vol 71 (1990) pp 241-264 15 Haav, I-I -M 'ExpertPRIZ as an environment for developing expert data base systems' in: Proc. 12th

International Seminar on Database Management Systems Suzdal (1989) pp 89-94 16 Tyugu, E et al 'NUT -an object-oriented language' Computers and Artificial Intelligence Vol 5 (1986) pp 521-542 17 Nepeivoda, N 'Relation of natural deduction rules to statements of programming language' Soviet Math. Doklady Vo1239 No 3 (1978) pp 526-529 18 Dikovski, A 'Solving algorithmic problems about synthesis of programs without loops in linear time' System Programming and Computer Software Vol 3 (1985) pp 38-49 19 Kanovich, M 'Quasipolynomial algorithms of satisfiability and derivability of propositional formulas' Soviet Math. Doklady Vol 290 No 2 (1980) pp 281-286 20 Pospelov, D Introduction to Computing Systems Soviet Radio, Moscow (1972) (Russian) 21 Karzanov, A and Faradjev, I 'Action planning on computational models' Computer Software and Systems Programming Vol 4 (1975) pp 19-24 (Russian) 22 Plaks, T 'Synthesis of parallel programs on computational models' Computer Software and System Programming Vol 4 (1977) pp 55-63(Russian) 23 Valkovski, V and Malyshkin, V Synthesis of Parallel

Programs and Systems on Computational Models Nauka Publishers, Novosibirsk (1988) (Russian) 24 Bashmachnikov, A and Zagadski, B et al 'FIKH A R - a modular programming system for reactor calculations' Proc. 3rd Symposium on Programs for Mathematical Physics Novosibirsk (Russian) (1973) 25 Babajev, I, Novikov, F and Petrushina, T 'DEKART -input language of the SPORA system' Applied Informatics Vol 1 (1981) Moscow: Finansy i ststistika (Russian) 26 Nariniani, A and Kanflrashina, E 'Tools for building knowledge based systems' in" Kotov, V (ed.) Computers and Software (1986) Novosibirsk pp 100-118 (Russian)

15