Language Description and Implementation Concepts of LITFAS (Language for Implications from Textual Files and Atomic Sentences)

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 46 – 04/1984

Eberhard Bertsch

Language Description and Implementation

Concepts of LITFAS (Language for Implications

from Textual Files and Atomic Sentences)

Abstract:

Languag~ Description and Implementation Concepts of L IT FA S

(Language for Implications from Textual Files and Atomic Sentences)

E. Bertsch

We define a simple, high-level language that combines essential fea- tures of logic programming with a natural file query formalism. The internal sequence of deduction steps is entirely hidden from the user.

A rough outline of the implementation is also presented. It turns out that the file access mechanism demands a separate kind of backtracking Numerous examples are given to demonstrate the expressive power of the languagE;.

Indexterms:

Logic programming, textual files, query processing, backtracking techniques.

1. Introduction

The syntax and semantics of predicate logic had been formalized /Carn37/, /Quin41/, before the first algorithmic languages were im- plemented /Back78/.

In the 1960s, various computational studies of predicate logic were undertaken /Love68/, /Melt66/, /Robi65/. The general concern of those investigations was the formal modelling of human thought, predominantly in the area of theorem proving.

A particular type of theorem proving - that which occurs when impli- cations are restricted to the form of Horn clauses - was shown to

lend itself to efficient implementation /BM73/. The system which first exploited this property was named PROLOG.

The fundamental insight that PROLOG-like languages can in fact be viewed as practical algorithmic languages was mainly propagated by Kowalski /Kowa74/, /Kowa79/. The procedural interpretation of Horn clauses became the conceptual core of a new programming discipline, now generally called Logic Programming.

Since the mid-1970s, a large number of articles on logic programming have been published. Some of them express dissatisfaction with the original PROLOG language and propose various extensions and modifica-

tions /CMG82/, /Kahn82/. Other research has focused on the application of Horn clause formalisms to data base description /SS82/ and know- ledge base construction /Walk82/.

It is noteworthy that the Japanese Fifth Generation Computer Project may use a variant of PROLOG adapted to concurrent execution as a systems programming language /ST83/, /Kowa83/, /Shap83/.

/CM81/ gives a thorough introduction to the programming techniques needed in applications of PROLOG.

The present paper describes a simple PROLOG-like language that has been implemented in MS-PASCAL on a SIRIUS 1 personal computer /VICT83/. It permits a restricted form of Horn clause deduction. In developing the system, the focus of attention has been placed on its capability to

access textua1 data contained in user files that are in turn main- tained by the available operating system. As an essential feature, textual data are not expected to have the format of predicates. In various aspects, the file system resembles a classical information retrieval system /Salt68/, some other aspects bear closer resemblance to the user interface of a relational data base system /Sche81/,

/Astr76/.

All files are written and updated with the aid of the editor provided by the operating system.

Before the execution of queries related to the contents of a file, a preprocessing phase is applied in order to build an internal index.

In spite of the apparent simplicity of file queries, their expressive power compares favorab.ly with that of languages used for relational data base systems /Astr76/.

The present version of LITFAS does not permit updates as parts of a deduction. This matter deserves further investigation. We suspect that the inclusion of updating facilities would cause harm to the elegance and simplicity of both the language and its implementation.

2. Notation and terminology

In this section, we present those features of logic programming that are required for writing LITFAS programs. The specific treatment of textual files will concern us later.

In LITFAS, an atomic formula (for short: an atom) has the form 9 ( t 1, ... 'tn)

where t

1, • . . ,tn are terms (n ~ 1), or simply

a without any terms.

a is a predicate name, denoted by a sequence of letters. Each term is either a variable name, denoted by a sequence of letters, or a number constant, denoted by a sequence of decimal digits, or a string constant,

denoted by an arbitrary sequence of characters enclosed by quote

symbols (^{11 ) .}

Please note that in contrast to PROLOG, LITFAS does not support nested terms of the form f(t

1, ..• ,t ) where t , ... ,t are again terms.

m 1 m

Atomic formulae that are not parts of an implication (see below) are called atomic sentences.

Semantically~ an atomic sentence expresses the validity of the predi- cate named a for the arguments t , ... ,t . If any of the terms

- 1 n

t ₁, . . . ,tn are variable names (let us call them v

1, . . . ,vk for k ~ n), then the atomic sentence

9 ( t 1' . . . 'tn) is interpreted as stating that

11for all v

1, .•• ,vk the predicate 9 (t₁^{, . . •} ,tn) holds ^{11 •}

If all terms are constants, the interpretation is simply ¹¹the predi- cate 9(t

1, . . . ,tn) holds^{11 •}

A (Horn) implication has the form . . . ' a _m where a

0 ,a

1, •.. ,am are atomic formulae (m ~ 1).

If any of the terms contained in a

0 ,a

1, . . . ,am (say v

1, . . . ,vk) are variable names, the implication is interpreted as

11for all v

1, . . . ,vk the predicate a

0 holds if each of the predicates a , ... , a h o l d ^{11 •}

1 m

The interpretation of variable-free implications is obvious.

A clause is either an atomic sentence or an implication. A LITFAS

program is a nonempty sequence of clauses separated by semicolons.

Let us now turn to the notion of deducibility of a variable-free query with respect to a given program. The textual form of a variable-free query is that of a variable-free atom with a question mark appended.

As a useful definition, we call any mapping m from a set of variable names into a set of constants a substitution, and say that a variable- free clause f'is obtained from a clause f by applying 11) if c' results from replacing every instance of any variable name v in c by the

associated constant ~(~).

Please note that this guarantees identical replacement of several instances of a variable name. Thus p(l,2) can be obtained from p(x,y) by applying a substitution (viz. {(x,l),(Y,2)}), but not from p(x,x).

We proceed inductively:

A variable-free query ~(q ₁, . . . ,qn)? is deducible in depth one with respect to a given program, if there exists a substitution ~ such that ~ applied to as yields ~(q

1, . . . ,qn) for some atomic sentence as in the program.

A variable-free query as above is deducible 1.,n depth n + 1 with respect to a given program, if the program contains an implication i of the form

and there exists a substitution s such that s applied to i yields

bo < bl, ... ,bn

where b equals a(q

1, . . . ,q ) and all b. (1 ~ i ~ n) are deducible in

O - n ^1.

depth n with respect to that program.

Dropping the reference to depth of deduction, we say that a variable- free query is deducible if it is deducible in depth d for some d > o.

It is now easy to define deducibility of generai queries as an exten- sion of the previous notion.

Textually, a query is an atom with a question mark. A query q? is

deducible (with respect to a given program) if there is a substitution

~~ whose application to q yields q' such that q'? is deducible with respect to that program.

~ is called an output substitution (for short: an output) of q?.

Please note that q' is by definition variable-free.

Two output substitutions are called different on a query q?, if they differ in a value associated to (at least) one of the variable names occurring in q. If the query concerned is obvious from the context

of discussion, we shall simply say that two outputs are different.

3. Built-in predicates

Procedural programming languages of the ALGOL-PASCAL family commonly provide some built-in procedures and functions which can be called without explicit definition. Mutatis mutandis, the same holds for PROLOG /CM81/.

In the present version of LITFAS, the binary predicates Unlike and Larger are implicitly available. Under the condition stated below, Unlike and Larger can be used as if there were atomic sentences Unlike (c

1,c

2 ) for all constants c

1 ,c

2 with c

1 ^=I= c

2 and Larger (c

1,cJ for all constants c

1,c

2 with c

1 > c

2 in all LITFAS programs. (c

1 > c

2

is defined in the obvious way for numoer constants and string constants consisting entirely of decimal digits.)

lt should be noted that there is no need for a predicate Equal (~,2) where ~ and ~ are variable names, because if all instances of ~ and ~

in a given clause are replaced by the same variable name, say ~ . the desired predicate is implied.

Now if Unlike and Larger could be used without any further conditions being satisfied, their implementation would lead to a serious increase of system complexity. Readers who are familiar with PROLOG will notice that a simple way to resolve this difficulty would be to demand that parameters of built-in predicates be instantiated before the evaluation of such predicates. However, the introduction of the notion of

instantiation on language level would in turn lead to the requirement that the semantics of LITFAS be partially defined in terms of its implementation. We want to avoid this unpleasant feature (though ubiquitous in PROLOG) in our language definition.

Instead, we impose a condition which implies (is stronger than) the condition of instantiation of parameters, and can be stated without reference to the sequence of deduction steps performed by the system.

The condition may be expressed as follows:

Let g(x,y) be an atomic formula where

e

If x or y is a variable name, then that name must also occur in some atom with a solid predicate name g further to the left in the same clause.

A predicate name is called solid, if it is an identifier of a text predicate (see section 5), or all clauses starting with g have the form

g(c1 , . . . ,cn) with constants c

1 , ••• ,cn.

In other words, g must not be defined in terms of some implication.

Furthermore, atomic sentences defining 9 must not contain any variable names.

(The condition could be somewhat weakened by additionally calling all those predicate names solid that are defined by implications whose right sides contain only solid predicate names.)

4. Example: Genealogy of Prussian kings in the 18th century Consider the following LITFAS program.

Father ("Friedrich !^{11 ,} "Friedrich Wilhelm I");

Father ("Friedrich Wilhelm I", "Friedrich II");

Father (1¹Friedrich Wilhelm I", "August Wilhelm");

Father ("August Wilhelm", "Friedrich Wilhelm II");

Father ("Friedrich Wilhelm II", "Friedrich Wilhelm III");

Son(x,y) < Father(y,x);

Grandfather(x,y) < Father(x,z), Father(z,y);

Grandson(x,y) < Grandfather(y,x);

Brother(x,y) < Father(z,x), Father(z,y), Unlike(x,y);

Uncle(x,y) < Brother(x,z), Father(z ,Y);

Nephew(x,y) < Uncle(y,x).

The query Grandfather (x, "Friedrich Wilhelm II ¹¹ )? is deducible with the output substitution

{(x, "Friedrich Wilhelm I^{11 ) } .}

The query Uncle (x,y)? is deducible with the output

{(x, "Friedrich II ^{11 ) ,} (Y, "Friedrich Wilhelm II")}.

The query Grandfather ("Friedrich I", y)? is deducible both with the output { (Y, ¹¹Fri edri eh II")} and wi th the different output

{(Y, "August Wilhelm")}.

The query Grandfather (x,y)? is deducible with four different outputs.

In the present version of LITFAS, a representation of the set of out- put substitutions constitutes the response to a submitted query.

5. Textual files

At each invocation of the LITFAS system, the external names of a program file and a data file are prompted.

The program file contains a sequence of clauses as a simple string of characters. The predicate names·used on the right sides of implications must be defined in one of three alternative ways:

(a) as names of built-in predicates,

(b) as predicate names of atomic sentences or of atoms on the left sides of implications, (c) in terms of data file contents.

Case (c) requires detailed explanation.

In accordance with customary text editors, a data file is considered as consisting of a sequence of text lines numbered from 1 to some k, If there is a substring of some text line that has the form

· . b b'

*l . . . , v

1 . • . v

1 m m

where i ,(j ~ n) are letters, bis a blank character, v.(j ~ m) are

J J

characters not equal to a blank or end-of-line, and b' is a blank or end-of-line character, then that substring is called a text predi- cate, i

1 . . . in is called an identifier and v

1 . . • vm is called a vaZue

associated to the identifier.

An individual text line may contain any number of text predicates. If it contains two or more, then their identifiers must be different.

A line may additionally contain any amount of text not belonging to text predicates.

The semantics of text predicates is defined by comparison with ordi- nary atomic sentences.

Suppose there is a text predicate with identifier i and value v in line z of the data file. Then the occurence of that string is

equivalent to the existence of a variable-free atomic sentence

i( ¹¹v¹¹ ,z)

in the program file. Consequently, identifiers may be used as predi- cate names with two parameters.

As a practical restriction, LITFAS considers two identifiers or two values as being the same if they agree in an initial section of fixed length (12 at present).

6. Some more examples

Assume that the lines of the following text are separate lines of a data file.

•i-ÄU Beattie , J. (*Ye 1788 ). Theory of Language. *Pl London

*AU Bloomfield , L. ( *Ye 1933 ). Language. *Pl New_York

*AU Chomsky , N, (*Ye 1957 ). Syntactic Structures. *Pl The_Hague

*AU Descartes ' R. (*Ye 1641 ). Meditations

*AU Jespersen , 0. (*Ye 1924 ). Phi 1 osophy of Grammar. *Pl London The relative order of several text predicates within a line is irrele- vant.

Please note that the small amount of necessary formatting is achieved by discriminate use of blanks and underscores.

Even without regard to any implications on a program file, the con- tents of the data file permit various queries.

The query Au("Jespersen",z)? has the output {(z,5)}. Similarly, Au(a,2)? yields {(a,"Bloomfield^{11 ) } .} The query Pl(p,z)? is deducible with the different outputs

{(p, ¹¹London^{11 ) ,} (z,l)}, { ( p , ¹¹ London ^{11 ) , (} z , 5 ) } , {(p,"New_York"), (z,2)}, {(p,¹¹The_Hague^{11 ) ,} (2,3)}.

To make more refined use of the data file, there might be implications like the following on the program file:

Early(author)<Au(author,x), Ye(year,x), Larger(1930,year);

NotNewYorker(author)< Au(author,x), Pl (place,x), Unlike("New_YE>rk" ,place);

Ancient(place) < Ye(year,x), Pl (place,x), Larger(l800,year);

Yearofßl (Y) < Ye(y ,x), Au( "B1 oomfi el d" ,x).

As before,queries are regarded as requests for the associated set of outputs.

Thus Early(author)? yields

{(author,"Beattie^{11 ) } ,} {(author, ¹¹Descartes^{11 ) } ,} {(author, ¹¹Jespersen^{11 ) } .}

Ancient(place)? yields {(place, ¹¹London^{11 ) } .}

So far, all text predicates used on the right side of an individual implication have referred to the same line number x. We shall now present implications that do not satisfy that requirement. The follo- wing examples demonstrate the essential capability of LITFAS clauses to express the kind of queries typically formulated at the user inter- face of relational data base systems /Astr76/, /Schl81/.

Suppose that some lines of a data file contain a text predicate with identifier name and a text predicate with identifier phone. Supposa further that other lines contain a text predicate with identifier phone and one with identifier building.

With the obvious interpretation of these data, we formulate an impli- cation that uses both types of lines (performing a ¹¹join^{11 )} in order to give the names of persons in building A:

Give(n) < name(n,z), phone(t,z),

phone(t,y), building( ¹¹A¹¹ ,y).

The appropriate query is Give(n)?

Taking the same data file, we express an implication to yield all

·names with the respective building codes.

List(n,b) < name(n,z), phone(t,z), phone(t,y) ,building (b,y).

The query for all outputs is List(n,b)?

Note that the output of Give(n)? is also achieved by List(n,¹¹A¹¹ )?

The code of the building in which a particular person ¹¹Mayer¹¹ works, is obtained by List( ¹¹Mayer¹¹ ,b)?

Now let us assume a data file with lines that contain text predicates for the name, age and manager¹s name (denoted with the identifier mn) of an individual employee.

To find the names of persons that are of the same age as Mayer, we need an implication

Same(n) <name( ¹¹Mayer¹¹ ,z),age(a,z), name(n,y),age(a,y)

and the query Same(n)?

With the same file, we can find the names of persons who are older than their respective managers by

Older(n) < name(n,z) ,age(a,z) ,mn(m,z) name(m,y),age(b,y),Larger(a,b) and the query Older(n)?

7. Outline of the implementation

\'

We shall now describe the central procedures and data structures of the LITFAS interpreter. There are significant differences in com- parison with /Bruy82/, resulting specifically from the essential

non-existence of the structure-sharing problem which is due to PROLOG ¹s definition of terms.

An internal representation of the sequence of c1auses is constructed.

(When there is no danger of notational confusion, we shall use the words ¹¹clause^{11 , 11}atom^{11 , 11}term^{11 ,} etc. as meaning the corresponding parts of the internal representation.) Pointers are used to connect objects that represent the same name. A predicate symbol of an atom on the left side of a particular clause points to the next clause whose left side has the same predicate symbol. Likewise, a predicate symbol of an atom on the right side of a particular implication

points to the first clause with that predicate symbol on its left

side. All instances of an individual variable name within the same clause are connected by a ring of pointers.

The following diagram shows the different kinds of pointers that connect parts of a program representation.

Example:

a ( 1 , 0 )

l

~ ~

"' l

b _(X' y) < ^a(y,x)

Let us see how deductions are performed. We postpone consideration of file predicates.

When an atom (representing a query) is placed on the deduction stacki it is made to point to the first clause with the same predicate

symbol on its left side. If the atom and the left side of the clause pointed to are found to match (in the way described below) and the clause happens tobe an implication, then the atoms on the right side of the implication are added to the stack. In the course of the deduction, atoms that have been placed on the stack are in turn

compared with left sides of clauses that have the same predicate

symbol. Aga in, if an atom on the stack and a left side can be matched, the corresponding right side (if there is one) is added to the stack.

Whenever an attempted match fails, backtracking is invoked.

We need to take a closer look at how backtracking and matching (uni- fication) are done.

Whenever an atom on the stack is compared with the left side of a clause and there is a next clause with the same predicate symbol on its left side, a pointer to that clause and pointers to the first and last atoms on the stack that still have tobe matched are placed on a separate backtracking stack. An ordered triple of such pointers is called a backtrack tripZe. Furthermore, at every change of some value on the (deduction) stack in the course of unification, the previous value and its position on the stack are recorded on the backtrack stack.

When a failure occurs in unification, backtracking is performed by restoring all values in the stack that have been changed since the most recent placement of a backtrack triple, restoring the previous pointers to the first and last atoms as provided by the backtrack

triple, and resuming the unification process with the left side of the clause pointed to by the first component of the backtrack triple.

In the following diagram, suppose the atom pointed to by ..:f..:!.. is being compared with clause c₂, c 4 is the first clause behind c2 that has the same predicate symbol on :ts left side, and la points to the current end of the deduction stack.

Then the backtrack triple consists of a pointer to c

4, fi and la.

Example:

C 1 ; ^{f i -}

[2;

c4;

1 a -

To describe unification, we need some auxiliary definitions. We have.

previously stated that different instances of the same name within a clause are represented by a ring of pointers connecting the terms.

Let us call such a ring a program-ring. In a way tobe explained, the process of unification gives rise to rings of pointers connecting positions in the deduction stack. Such rings are called stack-rings.

(Representations of) terms in a program will be said to be

program-connected if they belong to the same program-ring; and posi- tions in the stack will be called stack-connected if they belong to the same stack-ring.

How is unification done? From left to right, the terms of an atom on the stack and those of an atom in the program are compared with each other. Let us say that terms to be compared correspond.

If both the term on the stack and the corresponding one in the pro- gram have a value (that will be the case if the one in the program is a constant and the one in the stack is either a constant or has been assi9ned a value), the two values are compared. If they agree, unifi- cation can continue, otherwise backtracking is invoked.

If the term in the program is a constant, but the one in the stack does not yet have a value (is un-instantiated), then the value of the

constant is assigned to the term on the stack and to all those po- sitions that are stack-connected to it.

Example:

i, ,l,

stack a(x) < b(x,y) 1'

1

program a (

t

( <· --> d e not es c o r r es p o n den c e , - de n o t es s t a c k - c o n n e c t i o n o r

program-connection.) In the example, 3 is assigned to two stack posi- tions representing x.

If the term on the stack has been given a value (instantiated), but the corresponding one in the program is a variable and this variable is program-connected to others, we must consider all stack positions that correspond to any of the variable instan~es in the program-ring and, furthermore, all other stack positions that are in the same stack-ring as any of those stack positions.

If any position thus reached already has a value different from the one mentioned above, backtracking is invoked. Otherwise all of them receive the value.

Example:

stack

program

~

J

a ( 3 , X , X , Z , Z ) • • • , Z , • • •

t 1

1 1

•• •· 1 1 1

,V ,!,

a(y,y,w,y,v) _{1 ~}

I. _ _ _ _ _ ,,. j

3 must be assigned to all positions in all stack-rings, one of whose elements corresponds to a variable contained in the program-ring of terms named y. All x's and z's in the example have that property.

If the program term is a variable, and the stack term is un-instantia- ted, an operation called merging of rings is performed. It serves to merge all those stack-rings which contain any of the stack positions that correspond to some variable in the program-ring of the variable considered.

The existence of a pr~gram-ring is due to equally-named terms within a single clause. Stack-rings may additionally have been established by previous merge operations. An individual stack position that is not connected to any others is considered as a stack-ring for itself (its ring pointer points to itself).

Example:

stack ^p a ^{~ , b, a . +}

' ^C ' ^{d ... , g} ' e

'

...

' ^f '

-1' _~

1 ••• ...1

1

t

program p ( .J. X

'

t

y _{' X}

ti.... ' ^{x,x f' )}

Here we have three previously established stack-rings, each of which contains an element that corresponds to an instance of x. After

unification, one stack ring will contain all elements of the previous three.

For two rings, merging is performed by exchanging the values of one pointer in each ring.

1 }' ·+ ~l

• - - - • ..~---ff • - - - - •

~ pointer after merge

,0 ) previous pointer

This operation must not be applied, however, if both pointers already belong to the same ring, because in that case an exchange of pointers would lead to the splitting of one ring into two.

-~-~l

• - - - • < '<', •

To avoid this, all members of a ring must have an identical mark (ring-stamp). The merging operation is executed only if the elements considered have different ring-stamps. How does an element obtain a mark? At the start of the deduction, stack positions have unique ring- stamps and point to themselves. At every merge operation, the elements of the ring tobe added are given the ring-stamp of the other ring.

When no more atoms on the stack need to be unified, the values associ- ated to the variables in the first atom (query) are printed out with the corresponding variable names. Please note that values can only be numbers or character strings. This output amounts to one substitu- tion. Then backtracking is invoked. Possible further output substitu- tions are printed. The process terminates when no further backtracking is feasible.

Now let us consider the treatment of textual files in the above context.

The contents of a given data file must be scanned to construct three internal tables: a table of identifiers, a table of textual values associated with identifiers, and a table of line numbers giving the places where textual values may be found.

Each identifier is listed with a pointer to the first value (in the value table) which is associated to that identifier.

Each value is listed with a pointer to the next value associated to the same identifier and a pointer to the first place (in the table of line numbers) where the number of a line containing the value is given.

Each entry in the table of line numbers contains an actual line number of the data file and a pointer to the next entry belonging to the

same value.

Example:

Suppose the following data file is submitted.

The tables constructed from this file are:

Identifier table Value table Line number table

a - ^w

. -

b

. -

^. _- -

,, -

C

--

^.

c - ~

I

,,

. _{. .} -

.

. 4

. .

How is that data structure made use of in the course of unification?

Anatom d(x,y), where d is an identifier, may occur as a candidate for unification on the deduction stack. At that time, x or y or both may have been instantiated.

We need to consider four cases:

If both have been instantiated, it is only necessary to check whether line Y contains a substring •d x. The internal data structure is not used. Instead, the external file is accessed. Observe that the

examination of the validity of d(x,y) could alternatively be imple- mented as a sequence of operations on the internal data structure.

We intend to investigate the relative merits of either method and possible intermediate ones by means of time measurements.

If y has been instantiated, but x has not, then x is determined from the tables. The value of x is subsequently assigned to all positions that are stack-connected to the one that represents x. More precisely, since x stands for a string value, a pointer to the string is assig- ned to all those positions. This case has been implemented by purely internal operations. Alternatively, external file access could be used.

If x has been instantiated, but y has not, the line numbers p of

lines with ... •d x ... are considered. If there are several such lines, backtracking is required. By loose analogy to backtrack triples in ordinary deduction, a pointer to the next candidate (in the table of line numbers) is stored on the backtrack stack, and the current value of p is assigned to all positions that are stack-connected to the position of y.

Now suppose that both x and y are un-instantiated. From the internal tables, the first pair (w,f) is determined such that w is a textual value associated with d in some text predicate and f is the number of a line where this text predicate is found. wand f are assigned to all positions that are stack-connected to the one representing x and y, respectively. If there is a next line number with ... •d w ... , then that line number is placed on the backtrack stack for later

use. Otherwise, if there is a next value w' such that •d w' occurs

somewhere in the data file, then w' and the number of the first line that contains this text predicate are stacked for backtracking.

The third and fourth cases of text predicate unification suggest linear structure for the value table and the line number table, because whenever a value or line number is chosen, its immediate successor (if there is any) may be stored for backtracking.

We should like to point out that additional (secondary) access paths might influence performance in the first and second cases, if those cases are implemented by internal search.

Literature:

/Astr76/

/ßack78/

/BM73/

/Bruy82/

/Carn37/

/CMG82/

/CT82/

/CM81/

/Kahn82/

/Kowa74/

/Kowa79/

/Kowa83/

/Love68/

Astrahan, M.M. et al.:

System R: a relational approach to data management.

ACM Trans. on Database Systems 1, 97 - 137 (1976) Backus, J.W.:

The History of FORTRAN I, II and III.

ACM SIGPLAN Not. 13/8, 165 - 180 (1978) Battani, G. and Meloni, H.:

Interpreteur du Langage de Programmation PROLOG.

Groupe Intelligence Artificielle.

Universite Aix-Marseille II (1973) Bruynooghe, M.:

The Memory Management of PROLOG Implementations, in /CT82/, 83-98

Carnap, R.:

The Logical Syntax of Language.

Harcourt-Brace, New York (1937)

Clark, K.L., McCabe, F.G. and Gregory, S.:

IC-PROLOG Language Features, in /CT82/, 253 - 266

Clark, K.L. and Tärnlund, S.-~.(eds.):

Logic Programming.

Acadernic Press (1982)

Clocksin, W.F. and Mellish, C.S.:

Programming in PROLOG.

Springer (1981) Kahn, K.M.:

Intermission - Actors in PROLOG, in /CT82/, 213 - 228

Kowalski, R.:

Predicate Logic as Programming Language.

Proceedings IFIP Congress, 569 - 574 (1974) Kowalski, R.:

Logic for Problem Solving.

North Holland (1979) Ko w a 1 s k i , R. :

Logic as the Fifth Generation Computer Language,

in Scarrott, G. (ed. ): The Fifth Generation Computer Project Infotech State of the Art Report 11:1, Pergamon (1983)

Loveland, O.W.:

Mechanical Theorem Proving by Model Elimination.

Journal of the ACM 15, 236 - 251 (1968)

/Melt66/

/Quin41/

/Robi65/

/Salt68/

/SS82/

/Sche81/

/Schl81/

/Shap83/

/ST83/

/VICT83/

/Walk82/

Meltzer, B.:

Theorem Proving for Computers: Some Results on Resolution and Renaming.

Computing Journal 8, 341 - 343 (1966) Quine, W.V.D.:

Elementary Logic.

Harper-Row, New York (1941) Robinson, J.A.:

A Machine Oriented Logic Based on the Resolution Principle.

Journal of the ACM 12, 23 - 41 (1965) Salton, G.:

Automatie Information

Organization and Retrieval. Mc Graw-Hill (1968) Santane-Toth, E. and Szeredi, P.:

PROLOG Applications in Hungary, in /CT82/, 19 - 32

Schek, rl. -J.:

Methods for the Administration of Textual Data in Database Systems, in Oddy, R.N. et al. (eds.):

Information Retrieval Research. Butterworths, London (1981) Schlageter, G.:

Datenbanksysteme, course text.

Fernuniversität Hagen (1981) Shapiro, E.Y.:

A Subset of Concurrent PROLOG and Its Interpreter.

Report CS83-O6.

The Weizmann Institute of Science, Rehovot/Israel (1983) Shapiro. E.Y. and Takeuchi, A.:

Object Oriented Programming in Concurrent PROLOG.

New Generation Computing 1, 25 - 48 (1983) VICTOR Publications:

SIRIUS 1 MS-PASCAL Reference Manual (publ. by arrangement with Microsoft Corp. ).

Scotts Valley /CA (1983) Walker, A.:

Automatie Generation of Explanations of Results from Knowledge Bases.

IBM Research Report RJ 3481 (1982)