Baroque(ID:576/bar001)Logic programming languageBoyer & Moore, Edinburgh, 1972. Logic programming language with non-logic programming features Kowalski: "assembly-like programming language that provided list processing and arithmetic primitives defined by Horn clauses and interpreted by a structure- sharing SL-resolution theorem prover with a depth-first search strategy" Places References: in "Machine Intelligence 7", Meltzer, Bernard and Michie, Donald (eds) Edinburgh University Press, 1972 view details in "Machine Intelligence 7", Meltzer, Bernard and Michie, Donald (eds) Edinburgh University Press, 1972 view details in "Machine Intelligence 7", Meltzer, Bernard and Michie, Donald (eds) Edinburgh University Press, 1972 view details in [ACM] JACM 22(1) January 1975 view details When I returned from Marseilles, Boyer and Moore were very enthusiastic. Programming in resolution logic seemed to be just what they were looking for to exploit their earlier discovery of the structure sharing method of implementing resolution. They were already aware that structure sharing was analogous to the use of association lists in the implementation of Lisp. By the summer of 1972, however, they were so enthusiastic that they developed their own logic programming language called Baroque [27]. Baroque was an assembly-like programming language that provided list processing and arithmetic primitives defined by Horn clauses and interpreted by a structure- sharing SL-resolution theorem prover with a depth-first search strategy. "Demons" were attached to primitive functions such as addition and multiplication, to exploit the machine’s built-in arithmetic. Boyer and Moore then coded an interpreter in Baroque for a programming language akin to pure Lisp, with pattern- matched invocation and nondeterminism inherited from its implementation language. Programs written in the Lisp-like language were about 10 times slower than similar programs written directly in Baroque. However, what intrigued Boyer and Moore about the language was that it permitted (indeed, encouraged) the symbolic execution of programs and hence the interpreter could prove simple theorems about programs, such as "There exists an X such that (Length X) is 3." As they tried to prove more complicated theorems about programs, for example, that append is associative or that the length of (Append A B) is the sum of the lengths of A and B, they realized it was necessary to do mathematical induction. Boyer and Moore then turned their attention toward mechanizing inductive proofs. in [ACM] CACM 31(01) (Jan 1988). view details |