Metodología para el desarrollo de aplicaciones web

The high-level programming language GOLOG(“alGOL in LOGic”) (Levesque et al. 1997) is based on the situation calculus. As planning is known to be computationally very demanding and impractical for deriving complex behaviors with hundreds of actions, GOLOGfinds a compromise between planning and programming. The robot or agent is equipped with a situation calculus background theory. The programmer can specify the behavior just like in ordinary imperative programming languages but also has the possibility to project actions into the future. The amount of planning (projection) used is in the hand of the programmer. With this, one has a powerful language for specifying the behaviors of a cognitive robot or agent. The semantics of GOLOGis defined by situation calculus macros. Programs are expanded to situation calculus formulas with the predicateDo. If the theory entails the behavior program δ

D |= (∃δ, s).Do(δ, S0, s) ∧ Goals(s),

it is proven that programδ leads to the goal situation s starting from S0. As a side effect of the

The Semantics of Golog

The semantics is defined as follows.

1. Primitive Action: Do(a, s, s′₎def_{= Poss(a[s], s) ∧ s}′_{= do(a[s], s).}

For a primitive action it is checked if it is possible to execute it in the current situation (denoted by the predicateP oss). Note that a[s] denotes the action term with its situation argument restored. The successor situation is thendo(a[s], s).

2. Test action: Do(ϕ?, s, s′₎def

= ϕ[s] ∧ s′_{= s.}

Similar to primitive actions in the formulaϕ[s] all situation arguments are restored. A test does not change the situation.

3. Sequence: Do([δ1; δ2], s, s′)def= ∃s′′.Do(δ1, s, s′′) ∧ Do(δ2, s′′, s′).

4. Nondeterministic choice of actions: Do((δ1|δ2), s, s′)def= Do(δ1, s, s′) ∨ Do(δ2, s, s′).

5. Nondeterministic choice of action argument: Do((πx)δ(x), s, s′₎def_{= ∃x.Do(δ(x), s, s}′_).

6. Nondeterministic iteration:

Do(δ∗, s, s′) def= ∀P.(∀s1.P (s1, s1) ∧

∀s1, s2, s3.(P (s1, s2) ∧ Do(δ, s2, s3) ⊃ P (s1, s3))) ⊃ P (s, s′)

7. Conditionals: Do(if ϕ then δ1elseδ2endif, s, s′)def= Do([ϕ?; δ1|¬ϕ?; δ2], s, s′).

8. Loops: Do(while ϕ do δ endwhile, s, s′₎def

= Do(((ϕ?; δ)∗_{; ϕ?), s, s}′_).

9. Recursive Procedures: To define recursive procedures one needs to define an auxiliary macro definition. For any predicateP of arity n + 2 define Do(P (t1, . . . , tn), s, s′) def=

P (t1[s], . . . , tn[s], s, s′). Expressions of the form P (t1, . . . , tn) serve as procedure calls.

Then, one has to define the situation calculus semantics for programs involving recursive procedures making use of a standard block-structured programming style. A program will have the form

procP1(~ϑ1) δ1endproc; · · · ; proc Pn(~ϑn) δnendproc; δ0,

whereP1, . . . , Pnwith formal parameters ~ϑiand procedure bodiesδ1, . . . , δnare proce-

dures. The result of evaluating a program is defined as

Do({proc P1(~ϑ1)δ1endproc; · · · ; proc Pn(~ϑn)δnendproc}; δ0, s, s′)def=

∀P1, . . . , Pn. "n ^ i=1 (∀s1, s2.~ϑi).Do(δi, s1, s2) ⊃ Pi(~ϑi, s1, s2) # ⊃ Do(δ0, s1, s2)

3.3. REASONING ABOUT ACTION AND CHANGE 47

The Famous Elevator Example

The elevator example is famous in that it is usually a standard example for GOLOGand was often adduced. We follow this by presenting the elevator program from (Reiter 2001).

The available actions are up(n), down(n), turnoff (n), open, and close, which moves the elevator up and down to floorn, turns off the call button at floor n, and opens or closes the door, resp. The fluents needed are currentFloor(s) = n, and on(n, s), giving the current floor and stating whether the call button on floorn is turned on or not. The action preconditions are (1) Poss(up(n), s) ≡ currentFloor(s) < n, (2) Poss(down(n), s) ≡ currentFloor(s) > n, (3) Poss(open, s) ≡ true, (4) Poss(close, s) ≡ true, and (5) Poss(turnoff (n), s) ≡ on(n, s). The successor state axioms for the fluents currentFloor and on are

currentFloor(do(a, s)) = m ≡ a = up(m) ∨ a = down(m)∨ currentFloor(s) = m ∧ ¬∃n.a = up(n) ∧ ¬∃n.a = down(n) on(m, do(a, s)) ≡ on(m, s) ∧ a 6= turnoff (m).

As an abbreviation nextFloor(n, s) is defined as nextFloor(n, s)def= on(n, s)∧

∀m.on(m, s) ⊃ |m − currentFloor(s)| ≥ |n − currentFloor(s)|,

which is the nearest floor to the currently served floor. Further we need the procedures defined below. The initial situation is given asDS0= {currentFloor(S0) = 4, on(b, S0) ≡ b = 3 ∨ b =

5}.

procserves(n)

goFloor(n); turnoff (n); open; close endproc procgoFloor(n)

(currentFloor = n)? | up(n) | down(n) endproc procpark(n)

ifcurrentFloor= 0 then open else down(0); open endif endproc

proccontrol

[while_{∃n.on(n) do serveAFloor endwhile]; park} endproc

To run the programcontrol means to do theorem proving for the entailment Axioms|= ∃s.Do(control, S0, s).

A successful “execution” returns the following binding fors: s = do([down(3), turnoff (3), open,

A Golog Interpreter in Prolog

Next, we briefly address the Prolog implementation of GOLOG. We show the Toronto implemen- tation of GOLOGfrom (Reiter 2001). The semantics is defined by a set of clauses do/3 which directly map theDo predicate to Prolog code:

do(E1 : E : 2, S, S1) :− do(E1, S, S2), do(E2, S2, S1).

do(?(P), S, S) :− holds(P, S).

do(E1# E2, S, S1) :− do(E1, S, S1); do(E2, S,1).

do(if(P, E1, E2), S, S1) :− do(?(P) : E1# ?(−P) : E2, S, S1).

do(star(E), S, S1) :− S1= S; do(E : star(E), S, S1).

do(while(P, E), S, S1) :− do(star(?(P) : E) : ?(−P), S, S1).

do(pi(V, E), S, S1) :− sub(V, , E, E1), do(E1, S, S1).

do(E, S, S1) :− proc(E, E1), do(E1, S, S1).

do(E, S, do(E, S)) :− primitive action(E), poss(E, S).

Further, a predicate sub/4 is needed for term substitutions. These are for instance fluent values which have to be instantiated:

sub(X1, X2, T1, T2) :− var(T1), T2= T1.

sub(X1, X2, T1, T2) :− not var(T1), T1= X1, T2= X2.

sub(X1, X2, T1, T2) :− not T1= X1, T1= .. [F | L1], sub list(X1, X2, L1, L2), T2= .. [F | L2].

sub list(X1, X2, [ ], [ ]).

sub list(X1, X2, [T1| L1], [T2| L2]) :− sub(X1, X2, T1, T2), sub list(X1, X2, L1, L2).

The do clause for a test mentions the predicate holds/2. It is needed to evaluate logical formulas. It is defined by the following set of clauses:

holds(P & Q, S) :− holds(P, S), holds(Q, S). holds(P v Q, S) :− holds(P, S); holds(Q, S).

.. . holds(−(−P), S) :− holds(P, S) .. . holds(−all(V, P), S) :− holds(some(V, −P), S). holds(−some(V, P), S) :− not holds(some(V, P), S). holds(−P, S) : −isAtom(P), not holds(P, S). holds(all(V, P), S) :− holds(−some(V, −P), S). holds(some(V, P), S) :− sub(V, , P, P1), holds(P1, S).

3.3. REASONING ABOUT ACTION AND CHANGE 49

Finally, for (test) actions one needs a predicate which restores the situation argument of an action term, as well as a check if a formula is atomic.

holds(A, S) :− restoreSitArg(A, S, F), F; not restoreSitArg(A, S, F)isAtom(A), A.

isAtom(A) :− not(A = −W; A = (W1& W2); A = (W1 => W2);

A= (W1 <=> W2); A = (W1v W2); A = some(X, W); A = all(X, W)).

restoreSitArg(poss(A), S, poss(A, S)).

These clauses suffice to implement a GOLOGinterpreter in Prolog. Reiter thoroughly examines the assumption for a correct Prolog implementation. One problem is how Prolog works on nega- tions. With the “negation as finite failure” strategy, correctness depends on the ordering of Prolog clauses. Negated facts should always ordered past non-negated ones.

This gives an impression of how compact the implementation of the agent programming lan- guage GOLOGis. But many important features to control robots in dynamic domains are missing in the language. Throughout the next sections we will present several extensions to the language GOLOG, without regarding their implementation. In Chapter 4 we come back to the implementa- tion issues of READYLOG. The implementation here shall be seen as a reference implementation to the improvements made over recent years.