Some comments related to situation calculus:

 
    1) We said in class that object z could have nothing on it if we wanted
       to move block x on to it.  That is fine, but notice that
       this means a block cannot be moved on to the table.
    
       If we wanted to allow such moves by our robot arm,
       we could say "EITHER z is a block with nothing on it
       OR z is a table" (this would mean the table *always*
       has room to place another block on it, which
       is also buggy, but that is a common simplifying assumption).

    2) When we formalized the 'move' action on the "blocks world,"
       we added to the "then" part of the implication
       some "negative facts" about the new state,
       eg, that after doing move(x,y,z),
           (a) there is nothing on y and
           (b) there is nothing on x.

       It is fine to add these to the "then" part of the implication,
       but notice that in the initial state, we didn't explicitly say
       there is nothing on three of the blocks.  Instead
       we only stated "positive" (ie, unnegated) facts
       involving the predicate ON.  So it would be ok
       to only formalize the "positive" facts in the new state
       (i.e., the [unnegated] ON facts in the new state).

       In other words, it would have been fine to leave off:

        [ not ThereExists m on(m, x, newState) ] and
        [ not ThereExists n on(n, y, newState) ]

       Note that we still need the following PRECONDITIONs:

        [ not ThereExists w on(w, x, s) ] and
        [ not ThereExists u on(u, z, s) ]

       since (a) we can't move a block x if something is ON it and
       (b) we can't place x on z if z has something on it (as mentioned
       above, we could also say it is ok if z is a table).

    3) In the 'move' example presented in class, the
       only time-varying (ie, "time stamped") predicate was ON.

       A more common "design" for the Blocks World
       is to have two time-varying predicates, ON and CLEAR_TOP.
       In this case, we would want the formalized 'move' implication
       to use CLEAR_TOP in its preconditions and effects (the effects
       are the facts about the new state on the "right hand side" of
       the implication - another name for 'effects' is 'post conditions').

       If our logical inference rules always
       keep track of which blocks currently have CLEAR_TOP, then we never
       need to use NOT's in our inference rules (except for !=, ie 'notEqual'),
       which means that our inference rules could all be HORN clauses
       and we could use the programming language Prolog
       ('!=' is built into Prolog, so it is OK to use it).

       If CLEAR_TOP is in the vocabulary used to describe states in
       the blocks world, then we need a 'frame axiom' for it for
       each action.  Ie, we need to answer: when does CLEAR_TOP 'persist'
       (remain true) when action A is executed?  For example:

        ForAll a,x,y,z,s
          clear_top(a,s) ^ a != z  ->  clear_top(a, result(move(x,y,z), s))
          // Object 'a' stays clear in a move as long as it isn't the
          // destination of the move (a 'frame axiom').

       (Note that the above frame axiom can be used to infer
       that block x is still clear after moving block x.
       It is ok if this knowledge appears in the formalization
       of 'move' as well as in the frame axiom.  However,
       arguably it is better software engineering to
       put this information in one place only, so we could add
       'a != x' in the preconditions of the above frame axiom.)

As you can seen, formalizing even something as simple
as moving blocks around in the simplified Blocks World can become complicated,
plus there are a valid number of 'design choices.'

Once we get such formalizations into the computer, we can now use logical deduction
to do interesting reasoning, such as answering this query,
where a, b, c, and d are constants:

    ThereExists s  on(a, b, s) ^ on(b, c, s) ^ on(c, d, s)

given the inference rules (including frame axioms) about moving
plus the facts describing the initial state.

If the initial state is:

 state(s0) ^ table(table1) ^ block(a) ^ block(b) ^ block(c) ^ block(d) ^
 on(a,table1,s0) ^ on(b,table1,s0) ^ on(c,table1,s0) ^ on(d,table1,s0)

one possible result is:

    s = result(move(a, table1, b), result(move(b, table1, c), result(move(c,table1,d),s0)))

Notice that by finding the 's' where 'on(a, b, s) ^ on(b, c, s) ^ on(c, d, s)'
is true, you find via deduction a plan, reading right-to-left, for achieving the goal,
ie
    in the initial state, move c from the table on to d
    in the state that results, move b from the table on to c
    in the state that results, move a from the table on to b

In the last problem on HW5 you'll do something like this, where 'paint' is also an action
and a different (much simpler) formalization of 'move' is used.