The Repeated Demise of Logic Programming and Why It Will Be Reincarnated

Logic Programming is the proposal to implement systems using mathematical logic. Perhaps the first published proposal to use mathematical logic for programming was John McCarthy’s Advice Taker paper. Planner was the first language to feature ''procedural plans'' that were called by ''pattern-directed invocation'' using ''goals'' and ''assertions''. A subset called Micro Planner was implemented by Gerry Sussman, Eugene Charniak and Terry Winograd and was used in Winograd's natural-language understanding program SHRDLU, Eugene Charniak's story understanding work, and some other projects. This generated a great deal of excitement in the field of AI. It also generated controversy because it proposed an alternative to the logic approach that had been one of the mainstay paradigms for AI. The question arose as what the difference was between the procedural and logical approaches. It took several years to answer this question. The upshot is that the procedural approach has a different mathematical semantics (based on the denotational semantics of the Actor model) from the semantics of mathematical logic. There were some surprising results from this research including that mathematical logic is incapable of implementing general concurrent computation even though it can implement sequential computation and some kinds of parallel computation including the lambda calculus. Also along the way a large number of logic programming experiments were carried out although none met with great success. Also classical logic blows up in the face of inconsistent information that is becoming more ubiquitous with the growth of the Internet. Now we are in the midst of a huge paradigm shift to massive concurrency with the advent of Web Services and many-core computer architectures. This paradigm shift enables and requires a new generation of systems incorporating ideas from mathematical logic in their implementation. The result will be that logic programming will be reincarnated. But something is often transformed when reincarnated! Actors Actors are the universal primitives of concurrent digital computation. In response to a message that it receives, an Actor can make local decisions, create more Actors, send more messages, and designate how to respond to the next message received. A Serializer is an Actor that is continually open to the arrival of messages. Messages sent to a Serialize always arrive although delivery can take an unbounded amount of time. (The Actor model can be augmented with metrics.) Unbounded nondeterminism is the property that the amount of delay in servicing a request can become unbounded as a result of arbitration of contention for shared resources while still guaranteeing that the request will eventually be serviced. Arguments for unbounded nondeterminism include the following: • There is no bound that can be placed on how long it takes a computational circuit called an Arbiter to settle. – Arbiters are used in computers to deal with the circumstance that computer clocks operate asynchronously with input from outside, ''e.g..'', keyboard input, disk access, network input, ''etc.'‘ – So it could take an unbounded time for a message sent to a computer to be received and in the meantime the computer could traverse an unbounded number of states. • Electronic mail enables unbounded nondetermism since mail can be stored on servers indefinitely (perhaps the server is down temporarily) before being delivered. • Communication links to servers on the Internet can be out of service indefinitely. Actor Programming Language Semantics Actors can be used to define the semantics of concurrent programming languages. Actor script semantics Actor script semantics are defined by the behavior of Actors that serve as the script elements of an Actor programming language. For example consider the following concurrent programming language in which each <expression> is one of the following kinds: <identifier> When Communication[Eval[environment] customer] is received, send environment Communication[lookup[<identifier>]customer] send <recipient> <communication> When Communication[Eval[environment] customer] is received, send <recipient> Communication[Eval[environment] customer’] where customer’ is a new Actor such that when customer’ receives the communication r, then send <communication> Communication[Eval[environment] customer’’] where customer’’ is a new actor such that when customer’’ receives the communication c, then send r c <recipient>.<message> When Communication[Eval[environment] customer] is received, send <recipient> Communication[Eval[environment] customer’] such that when customer’ receives the communication r, then send <message> Communication[Eval[environment] customer’’] such that when customer’’ receives the communication m, then send r Communication[m, customer] receiver <pattern>i <expression>i When Communication[Eval[environment] customer] is received, send customer a new actor r such that when r receives a communication com, then try environment.bind[<pattern>i com] and 1. if a new environment’ is created send <expression>i Communication[Eval[environment’]] 2. otherwise try <pattern>i+1 behavior <pattern>i <expression>i When Communication[Eval[environment] customer] is received, send customer a new actor r such that when r receives Communication[message customer’], then try environment.bind[<pattern>i message] and 1. if a new environment’ is created send <expression>i Communication[Eval[environment’] customer’] 2. otherwise try <pattern>i+1 {<expression1>, <expression2>} When Communication[Eval[environment] customer] is received, send <expression1> Communication[Eval[environment]] and concurrently send <expression2> Communication[Eval[environment] customer] let <identifier> = <expression1> in <expression2> When message[Eval[environment] customer] is received, then create a new environment’ by environment.bind[<identifier> <expression1>.Eval[environment]] and send <expression2> Communication[Eval[environment’] customer] serializer <expression> When Communication[Eval[environment] customer] is received, then send customer a new actor s such that communications sent to s are processed in FIFO order with a behavior Actor that is initially <expression>.Eval[environment] and: When communication com is received by S, then send the behavior Actor Communication[com customer’] where customer’ is a new actor such that when it receives an Actor then it is used as the behavior Actor for the next communication received by S. Example Actor script An example Actor script for a simple storage cell that can contain any Actor address is as follows: Cell ≡ receiver Communication[Create[initial] customer] send customer serializer readWrite(initial)} The above script which creates a storage cell makes use of the behavior readWrite which is defined as follows: readWrite(contents) ≡ behavior Communication[read[] customer] {send customer contents, readWrite(contents)} Communication[write[x] customer] {send customer x, readWrite(x)} For example the following expression creates a cell x with initial contents 5 and then concurrently writes to it with the values 7 and 9. let x = Cell.Create[5] in {x.write[7], x.write[9], x.read[]} The value of the above expression is either 7 or 9. A Limitation of Logic Programming In his 1988 paper on the early history of Prolog, Bob Kowalski published the thesis that “computation could be subsumed by deduction” and quoted with approval “Computation is controlled deduction.” which he attributed to Pat Hayes. Contrary to Kowalski and Hayes, Hewitt's thesis was that logical deduction was incapable of carrying out concurrent computation in open systems because of indeterminacy in the arrival order of messages. Indeterminacy in Concurrent Computation Hewitt [1985], Hewitt and Agha [1991], and other published work argued that mathematical models of concurrency did not determine particular concurrent computations as follows: The Actor model makes use of arbitration for determining which message is next in the arrival ordering]of an Actor that is sent multiple messages concurrently. For example Arbiters can be used in the implementation of the arrival ordering of an Actor which is subject to physical indeterminacy in the arrival order. In concrete terms for Actor systems, typically we cannot observe the details by which the arrival order of messages for an Actor is determined. Attempting to do so affects the results and can even push the indeterminacy elsewhere. Instead of observing the internals of arbitration processes of Actor computations, we await outcomes. Physical indeterminacy in arbiters produces indeterminacy in Actors. The reason that we await outcomes is that we have no alternative because of indeterminacy. According to Chris Fuchs [2004], quantum physics is a theory whose terms refer predominately to our interface with the world. It is a theory not about observables, not about beables, but about ‘dingables’ We tap a bell with our gentle touch and listen for its beautiful ring. The semantics of indeterminacy raises important issues for autonomy and interdependence in information. In particular it is important to distinguish between indeterminacy in which factors outside the control of an information system are making decisions and choice in which the information system has some control. It is not sufficient to say that indeterminacy in Actor systems is due to unknown/unmodeled properties of the network infrastructure. The whole point of the appeal to quantum indeterminacy is to show that aspects of Actor systems can be unknowable and the participants can be entangled. Actor Model and Mathematical Logic What does the mathematical theory of Actors have to say about logic programming? A closed system is defined to be one which does not communicate with the outside. Actor model theory provides the means to characterize all the possible computations of a closed Actor system. So mathematical logic can character