GOLOG

1. GOLOG Maruthappan Shanmugasundaram (Satish) Graduate Student Department of Computer Science University of Manitoba Winnipeg, R3T 2H4 Email: sundaram@cs.umanitoba.ca CS 74.757 Formal Logic

2. Outline • Introduction • Situation Calculus • Golog • ConGolog • cc-Golog • Indigolog • Golex • pGolog • Conclusion CS 74.757 Formal Logic

3. Introduction • Computer systems are often embedded in complex environments with which they interact. • Designers and users of such systems have a mental model of the environment and how the systems actions affect the state of the environment. • However, the system itself does not maintain a model of the environment it is operating in and hence cannot justify its behaviour. CS 74.757 Formal Logic

4. Introduction (contd..) • This makes life difficult for users and designers as they may end reconstructing the model being used. • Reconfiguring or extending the system is also difficult as the system has no understanding at all of what it is doing. • To overcome these problems, the authors have developed a programming language called GOLOG whose design is based on an extended version of situation calculus. CS 74.757 Formal Logic

5. Introduction (contd..) • A Golog interpreter automatically maintains an explicit model of the systems environment. • This allows programs to reason about the state of the world and consider the effects of various courses of actions. • Hence programs may be written at a much higher level of abstraction • The language is well suited for applications in high level control of robots, industrial processes, discrete event simulations, intelligent software agents etc. CS 74.757 Formal Logic

6. Situation Calculus • Situation Calculus is a first order language (with some second order features) specifically designed for representing dynamic domains. • All changes to the world are the result of named actions, which may be parameterized. • A first order term called a situation is used to denote a possible world history, which is simply a sequence of actions. • S0is a constant which denotes the initial situation i.e. the situation in which no actions have yet occurred. CS 74.757 Formal Logic

7. Situation Calculus (contd..) • do(a,s) is a function which denotes the resulting situation from performing action a in situation s. • In situation calculus actions are denoted by function symbols and situations as first order terms. For example, is a situation denoting the world history consisting of the sequence of actions, CS 74.757 Formal Logic

8. Situation Calculus (contd..) • Relations whose truth values vary from situation to situation are called relational fluents and are denoted by predicate symbols taking a situation term as their last argument. For example, is_holding(robot, p, s). • Functions whose denotations vary from situation to situation are called functional fluents and are denoted function symbols with an additional situation argument. For example, loc(robot, s). • Actions in a domain are specified by providing certain types of axioms, namely action precondition axiom, effect axioms and frame axioms. CS 74.757 Formal Logic

9. Situation Calculus (contd..) • Action precondition axiom specify the conditions under which it is physically possible to perform an action. • Effect axioms specify the effects of a given action on the fluents thereby providing the causal laws of the domain CS 74.757 Formal Logic

10. Situation Calculus (contd..) • Frame axioms specify when fluents remain unchanged by actions. These are necessary if one wants to reason about change. For example, a robot dropping things does not affect an objects color: • In general there can be a very large number of frame axioms (generally of the order of 2 X A X F, where A is the number of actions and F the number of fluents) in a system and this gives rise to the Frame Problem. • This complicates the task of axiomatizing a domain and can make theorem proving extremely inefficient. CS 74.757 Formal Logic

11. Situation Calculus (contd..) • The frame problem can be solved by an approach due to Raymond Reiter. • The basic idea is to collect all the effect axioms about a given fluent and make a completeness assumption i.e. assume that they specify all of the ways that the value of the fluent may change. Then apply a syntactic transformation to the effect axioms to obtain a successor state axiom for the fluent. For example: CS 74.757 Formal Logic

12. Situation Calculus (contd..) • In general, a particular domain of application will be specified by a theory of the following form: CS 74.757 Formal Logic

13. Golog • The situation calculus explained previously is good for representing and reasoning about simple actions. • It fails to address the problem of expressing and reasoning with complex actions and procedures like: • Golog is a language based on the situation calculus which allows for expressing and reasoning with complex actions and procedures. • Golog  “alGOL in LOGic” CS 74.757 Formal Logic

14. Golog (contd..) • Complex action expressions are defined using additional extralogical symbols (e.g., while, if, etc.) which act as abbreviations for logical expressions in the language of the situation calculus. • These extralogical expressions are thought of as macros which expand into genuine formulas of the situation calculus. • The abbreviation Do(δ, s, s’) is the most basic abbreviation used in the Golog language, where δis a complex action expression. • Do(δ, s, s’) means that executing δin situation s has s’ as a legal terminating situation. • Complex actions may be nondeterministic i.e., may have several different executions terminating in different situations. CS 74.757 Formal Logic

15. Golog (contd..) Do is defined inductively on the structure of its first argument as follows: 1. Primitive actions: 2. Test actions: 3. Sequence: CS 74.757 Formal Logic

16. Golog (contd..) 4. Nondeterministic choice of two actions: 5. Nondeterministic choice of action arguments: 6. Nondeterministic iteration: Execute δzero or more times. CS 74.757 Formal Logic

17. Golog (contd..) • Conditionals and while loops are defined in terms of the above constructs as follows: • Procedures are hard to define in situation calculus semantics using macro expansion because there is no straightforward way to macro expand a procedure body when that body includes a recursive call to itself. CS 74.757 Formal Logic

18. Golog (contd…. Procedures) 1. An auxiliary macro definition: For any predicate symbol P of arity n+2, taking a pair of situation arguments: 2. Situation calculus semantics for programs involving procedures: A Golog program follows the block-structured programming style. So a program such as, Will be evaluated as: CS 74.757 Formal Logic

19. Golog (contd…. Procedures) Example: A Golog blocks world program to make a seven block tower while ensuring block A is clear in the final situation. CS 74.757 Formal Logic

20. Golog (contd...) • Golog programs are executed using theorem proving. • Doing so is straightforward because program executions are formulas of the situation calculus. • Program execution means, given a program δ and an initial situation, find a terminating situation for δ, if one exists. • To do so, we prove the termination of δ as: and then extract from the proof a binding for the terminating situation. CS 74.757 Formal Logic

21. Golog (contd...) • An elevator controller in Golog. CS 74.757 Formal Logic

22. Golog (contd...) CS 74.757 Formal Logic

23. Golog (contd...) CS 74.757 Formal Logic

24. Golog (contd...) • This initial situation axiom specifies that, initially buttons 3 and 5 are on, and moreover no other buttons are on. Thus we have complete information initially about which call buttons are on. • Running the program is a theorem proving task, which establishes the following entailment: CS 74.757 Formal Logic

25. Golog (contd...) • The meaning of this entailment and why it makes sense: 1. Do is a macro and not a predicate, and the expression stands for a much longer second order situation calculus sentence. 2. As this macro-expanded sentence is legitimate situation calculus, it makes sense to seek a proof of it from Axioms, which characterise the fluents and actions of this elevator world. • A successful proof for the elevator program may return the following binding for s: CS 74.757 Formal Logic

26. Golog (contd...) • The execution trace represented by this binding would be passed to the elevator’s execution module for controlling it in the physical world. • This example shows that Golog is a logic programming language in the following sense: • Its interpreter is a general purpose theorem prover. • Like Prolog, Golog programs are executed to obtain bindings for the existentially quantified variables of the theorem. CS 74.757 Formal Logic

27. Golog (contd...) • Golog is a logic programming language for implementing applications in dynamic domains. • But Golog omits some important considerations. Some of them are: • Sensing and knowledge • Sensing and knowing how • Exogenous actions • Concurrency and reactivity • Continuous processes CS 74.757 Formal Logic

28. ConGolog • ConGolog is a concurrent programming language based on the situation calculus • The language includes facilities for prioritizing the execution of concurrent processes, interrupting the execution when certain conditions become true, and dealing with exogenous actions. • ConGolog differs from other formal models of concurrency in at least two ways. First, it allows incomplete information about the environment. Second, it allows the primitive actions to affect the environment in a complex way and such changes to the environment can affect the execution of the remainder of the program. CS 74.757 Formal Logic

29. ConGolog (contd…) • By using Do, programs are assigned a semantics in terms of a relation, denoted by the formulas Do(δ, s, s’), that a given program δ and a situation s, returns a situation s’ resulting from executing δstarting in the situation s. • Semantics of this form are called evaluation semantics, since they are based on the complete evaluation of the program. • To allow concurrency, it is more convenient to adopt a different form of semantics, the so-called transition semantics or computation semantics. • Transition semantics are based on defining single steps of computation in contrast to directly defining complete computations. CS 74.757 Formal Logic

30. ConGolog (contd…) • For this two predicates are defined: Trans(δ, s, δ’, s’) and Final(δ, s). • Trans(δ, s, δ’, s’) holds if there is a transition from configuration (δ, s) to the configuration (δ’, s’), i.e. if by running program δ starting in situation s, one can get to situation s’ in one elemantary step with the program δ’ remaining to be executed. • Every elementary step will either be a the execution of an atomic action (which changes the situation) or the execution of a test (which does not change the situation). • Also, if the program is nondeterministic, there are several transitions that are possible in a configuration. CS 74.757 Formal Logic

31. ConGolog (contd…) • Final(δ, s) means that the configuartion (δ, s) is a final one, where the computation can be considered completed, i.e. no program remains to be executed. • The final situations reached after a finite number of transitions from a starting situation coincide with those satisfying the Do relation. • Complete computations are thus defined by repeatedly composing single transitions until a final configuration is reached. • With Trans and Final, a new definition of Do can be given as follows: CS 74.757 Formal Logic

32. ConGolog (contd…) • As mentioned earlier, ConGolog is an extended verion of Golog that incorporates a rich account of concurrency. • It is rich because it handles: • Concurrent processes with possibly different priorities • High-level interrupts • Arbitrary exogenous actions • Concurrent processes are modelled as interleavings of the primitive actions in the component processes. • That is, a concurrent execution of two processes is one where the primitive actions in both processes occur, interleaved in some fashion. • Here an important concept is that of a process being blocked. CS 74.757 Formal Logic

33. ConGolog (contd…) • The ConGolog language like Golog except with the following additional constructs: • Exogenous actions: CS 74.757 Formal Logic

34. cc-Golog • cc-Golog is an action language which incorporates continuous change and event-driven behaviour. • Used in high-level robot controllers which often need to specify event-driven behaviour and operate low-level processes that change the world in a continuous fashion. • Main characteristics of a cc-Golog program: • Timing of actions is largely event-driven thereby providing a reactive behaviour. • Actions are executed as soon as possible. • Conditions change continuously over time. • Good blocking policies. CS 74.757 Formal Logic

35. cc-Golog (contd..) • Event-driven behaviour is achieved by including a special action waitFor(τ). • Continuous change is incorporated through continuous fluents, which are functional fluents whose values range over functions of time. • Blocking policies are specified by means of a special instruction withCtrl(φ,σ). • Note: cc-Golog only provides deterministic instructions. CS 74.757 Formal Logic

36. IndiGolog • IndiGolog is an action language which provides an Incremental Interpreter for High-Level programs involving Nondeterminism and Sensing actions. • Golog interpreter executes in an off-line manner. • Off-line execution is unsuitable for large programs and causes serious problems in the presence of sensing actions. • An Indigolog program executes on-line by means of an incremental interpreter. • On-line style of execution is well suited for programs where the initial state of the world is incompletely specified and the agent or robot must use sensors to determine values of certain fluents. • Nondeterminism is taken care of by means of off-line lookahead search operator Σ. CS 74.757 Formal Logic

37. Golex • The field of autonomous mobile robots lacks methods that bridge the gap between high-level symbolic techniques and low-level robot control and navigation systems. • Golex is an execution and monitoring system which bridges the gap between Golog and the complex and distributed RHINO control software. • Golex provides the following features: • High level of abstraction • Execution monitoring • Sensing and Interaction CS 74.757 Formal Logic

38. pGolog • Actions of a robot are often best thought of as low level processes with uncertain outcomes. • A high level robot plan is a then a task, that combines the low level processes in an appropriate way and may involve nondeterminism. • The robot needs to turn a given plan into an executable program, through some from of projection such that it satisfies a given goal with a sufficient degree of probability. • This is achieved through pGolog, a probabilistic variant of Golog, whose programs model the low-level processes. • High-level plans are ordinary Golog programs, except that during projection the names of low-level processes are replaced by their pGolog definitions. CS 74.757 Formal Logic

39. Conclusion • Golog is a logic programming language for implementing applications in dynamic domains like robotics, process control, intelligent software agents, discrete event simulation etc. • It is based on a formal theory of actions specified in a extended version of the situation calculus. • Golog has a number of novel features, both as a programming language and as an implementation tool. • Though Golog has several limitations, the extended versions of Golog (like ConGolog, cc-Golog etc.) address most of these limitations in appropriate ways. • Thus Golog forms a stepping stone creating real world applications in dynamic domains. CS 74.757 Formal Logic

40. References • Hector J. Levesque, Raymond Reiter, Yves Lesperance, Fangzhen Lin, and Richard Scherl, "Golog: A logic programming language for dynamic domains”, Journal of Logic Programming, 31, 59-84, (1997). • J. McCarthy, P. Hayes, “Some philosophical problems from the standpoint of artificial intelligence”, In B. Meltzer and D. Michie, editors, Machine Intelligence,4, 463-502, (1969). • Giuseppe De Giacomo, Yves Lesperance, and Hector J. Levesque, “Congolog, a concurrent programming language based on the situation calculus”, Artificial Intelligence, 121(1-2), 109-169, (2000). • Henrik Grosskreutz, and Gerald Lakemeyer, “ccGolog - An action language with continuous change” Logic Journal of the IGPL, 11(2), 179-221, (2003). CS 74.757 Formal Logic

41. References (contd…) • Giuseppe De Giacomo, and Hector J. Levesque, “An incremental interpreter for high-level programs with sensing”, In Hector J. Levesque and Fiora Pirri, editors, Logical Foundations for Cognitive Agents, 86-102, (1999). • Dirk Hahnel, Wolfram Burgard, and Gerhard Lakemeyer, "Golex - bridging the gap between logic (golog) and a real robot" in Proceedings of the 22nd German Conference on Artificial Intelligence (KI 98), (1998). • Henrik Grosskreutz, and Gerhard Lakemeyer, “Turning high-level plans into robot programs in uncertain domains”, In ECAI’2000, (2000). CS 74.757 Formal Logic