http:^^www.cs.washington.edu^homes^ctkwok^simon-manual.html

This data set contains WWW-pages collected from computer science departments of various universities

<xmp>
(lcw-match <var> <scope>
           ((<literal>*) <action>*)+)
</xmp>

Consider an example:
<xmp>
(defaction person.domain.action (?goal ?p ?domain)
  (if (contemplate (is-bound ?domain) f)
      (setq ?domain "cs.washington.edu"))   ;; A hack
  (if (and (universal? ?p) (annotation ?goal scope))
      (lcw-match ?p ?s
                 (((lastname ?p ?l) (firstname ?p ?f)) 
                   (progn (call-op (finger-firstname ?f ?domain) ?s)
                          (call-op (finger-lastname ?l ?domain) ?s)))
                 (((lastname ?p ?l)) (finger-lastname ?l ?domain))
                 (((firstname ?p ?f)) (finger-firstname ?f ?domain))
                 )
    (progn 
      ;; because the partial obj scheme is slightly broken
      (if (and (lastname ?p ?lastname) (is-bound ?lastname))
          (call-op (finger-lastname ?lastname ?domain) ?goal)
        (if (and (firstname ?p ?firstname) (is-bound ?firstname))
            (call-op (finger-firstname ?firstname ?domain) ?goal)
          (fail))))
    ))
</xmp>

Here, ?s is bound to the scope of the universally quantified variable
?p.  The match statement is like a case statement, and we try to
determine which combination of literals appears in the scope.<p>

Note that the call-op would fail if the scope mentioned is more
general than the scope in the operator's effect(s). <p>

<!-- Should probably also add info on get-lcw, but I don't know how
this works at all! -->

<hr>
<a name = "Kludges">
<h3>APPENDIX B Kludges in this release</h3>
</a>

These are known problems/bugs/limitations in this release of Simon.  Some
of them may be fixed in the next release but some are more open
questions to be poundered upon.

<ul>
<!--
<li> Simon depends on rodney/stable.
It should use rodney/working and the new model manager 
once the model manager changes are stabilized.
-->
<li> Try statments will only backtrack if it is the last statement of
an action.
<li> The scope of undeclared variables is the block enclosing it's
     first use. This is unwieldy if, for example, we use a new
     variable inside a progn, and then need to reference it in the
     code following the progn.  A workaround is to assign to the
     variable in the outermost scope where the variable is used,
     perhaps by doing a setq to it.
<li> Cannot setq a variable to nil.  This is because the MM uses nil
     to indicate when no bindings are available.
<li> Conditions in if statments may be ignored if they are illegal.  
<li> Dies too miserably if you have syntax error in your SAL code...
<li> Also see Partial objects in Appendix D.  Simon solves partial object
goals partially...
<li> Universally quantified goals are working but dangerous to play with.
<li> Conditional effects in operators seems to work by only checking the model
manager.
</ul>
<p>

<hr>
<a name = "SAL_BNF">
<h3>APPENDIX C SAL BNF</h3>
</a>
<xmp>

<action> :-
<simple-action> |
<do-action> |   
<request-action> |  
<select-action> |
<achieve-action> |
<maintain-action> |  
<foreach-action> |
<assert-action> |
<if-action> |
<while-action> |
<try-action> |
<case-action> |
<find-action> |
<call-operator-action> |
<assert-attribute-action> |
<fail-action> |
<lcw-match-action> |
<get-lcw-action>


<simple-action>    :- (<action-identifier> <value>*)

<do-action>        :- (do <action>* <task-specifier>*)

<request-action>   :- (request <action>* <task-specifier>*)

<select-action>    :- (select (<variable>*) <literal>*)

<achieve-action>   :- (achieve <aliteral>*) |
                      (achieve <xii-goal>)

<maintain-action>  :- (maintain <aliteral>* <task-specifier>*)

<xii-scope> :- (<var> :in (and <scope>+))

<foreach-action>   :- 
(foreach (<variable> <value>) <action>*) |
(foreach <literal> <action>*) |
(foreach (<xii-scope>) <action>*)  

<find-action>      :- (find <literal> <action>*) |
                      (find (<variable> <value>) <action>*) | 
		      (find (<xii-goal>) <action>*)

<assert-action>    :- (assert <literal>*)

<action> :- <simple-action> | (progn <simple-action>+)

<if-action>        :- (if <condition> <action> <action>) |(cond <cond-clause>+)

<cond-clause>      :- ((<condition>) <simple-action>+)

<while-action>     :- (while <condition> <action>*)

<condition>        :- <literal> |
                      <xii-goal> |
                      <action>

<try-action>       :- (try <action>* [t]) | (try <simon-goal> <action>* [t])

<case-action>      :- (case <variable> <case-choice>*)

<case-choice>      :- (<constant> <action>) | (otherwise <action>) |
((<constant>+) <action>)

<literal> :- (pred <args>*)
<goal-obj> :- <var>
<simon-goal> :- <literal> | <goal-obj>

<call-operator-action> :- 
(call-op (<operator-name> <value>*) <simon-goal>) | 
(<operator-name> <value>*)

<fail-action> :- (fail)

<assert-attribute-action> :- (assert-attribute <literal>)

<new-prompt-case-list> :- (<prompt-case>*)

<prompt-case>      :- (<new-prompt> <action>)

<precond-selector> :- <num-list>

<task-specifier>   :- <when-spec> |
                      <duration-spec> |

<task-specifier>   :- <when-spec> |
                      <duration-spec> |
                      <priority-spec> |
                      <frequency-spec>

<when-spec>        :- :when always |
                      :when now |
                      :when <literal> |
                      :when (<literal>*) |
                      :when <xii-goal>

<duration-spec>    :- :duration once |
                      :duration continuous |
                      :duration <literal> |
                      :duration (<literal>*) |
                      :duration <xii-goal>

<frequency-spec>   :- :frequency <value>

<action-identifer> :- <action-name> |
                      <operator-name> |
                      <command-name> |

<value>            :- <object-name> | <lisp-object> | <variable> | <list>
<list>             :- ( <value>* )
<variable>         :- <var> | <rvar> | <avar>
<avar>             :- (<avar-arity>? <avar-direction>? <var>)
<avar-arity>       :- a | the | all
<avar-direction>   :- input | output |
</xmp>



<hr>
<a name = "Partial_objects">
<h3>APPENDIX D Partial objects</h3>
</a>



Most of the time Simon will do the right thing with partial objects and
so you don't need to worry about it.   This section documents how Simon
solves the partial object problem.<p>

Partial objects are variables that have a set of constraints but do not
have enough information to form or bind to an object.<p>

Example:
<xmp>
(achieve (and (find-out (firstname ?p "Terrance"))
	      (find-out (person.domain ?p "cs.washington.edu"))))
</xmp>
Here we're specifying that ?p is an object that has the attributes 
firstname and person.domain that we know about,  but we don't know the
lastname so we cannot completely specify a person object to bind to ?p.
Here our goal is to lookup some person ?p that has firstname Terrance and
domain cs.<p>

Simon solves the goal by caching the conjuncts(*) of these goals into
an object cache.  When required to lookup some facts about ?p,
Simon will look into this cache and obtain the required information.
For example,  in firstname.action,  we call the operator finger-firstname.
Finger-firstname has a precondition (person.domain ?p ?d),  and Simon already
knows (person.domain ?p "cs.washington.edu") from its object cache,  so it
will unify ?d with "cs.washington.edu".<p>

Currently Simon relies on XII's implementation of object constraints.
This means:
<ul>
<li>one cannot have a constraint alit that has other than 2 arguments in its
content (i.e. >2 or <2).
e.g.
<xmp>
(defpredicate firstname (person (firstname 1))
  "First field is a person object.  Second field is the person's first name string.")
</xmp>
This works because there are just 2 arguments 'person' and 'firstname',  but
<xmp>
(defpredicate idle.time (userid machine (number 1))
  "user is active on a machine. third parameter is user's idle time")
</xmp>
would never got asserted into the attribute cache because there are 3 
arguments,  namely 'userid', 'machine' and 'number'.

<li>one cannot have a constraint alit that has N N relationship.
e.g.
<xmp>
(defpredicate person.domain (person domain)
  "A person and their domain.")

(defpredicate lastname (person (lastname 1))
  "First field is a person object.  Second field is the person's lastname")

(defpredicate firstname (person (firstname 1))
  "First field is a person object.  Second field is the person's firstname 
string.")
</xmp>
Of these 3 predicates,  lastname and firstname would get asserted.  
Person.domain will not because it defaults to ((person N) (domain N)).

<li>.f goals are not asserted into attribute cache.
</ul>
<p>

(*) A limitation is that Simon cannot cache disjunctions.  So Simon will
ignore conditions specified in dijunction and will not cache them.

<hr>
<a name = "SAL_tutorial">
<h3>APPENDIX E SAL tutorial</h3>
</a>
A typical sequence of writing SAL actions would be starting with operators.
The operators produces effect terms.  We can start writing actions based on
them. <p>
For example we have the operator CD :
<xmp>
(defoperator CD ((directory ?d) (path ?n))
  (documentation "Change the current working directory")
  (precond (find-out (pathname ?d ?n)))
  (interface ((exec-func execute-unix-command)
              (translation ("cd " ?n))
              (error-func default-unix-error?)
              (terminate-detect read-unix-prompt)))
  (effect (cause (current.directory ?d))))
</xmp>
Here we have the "current.directory" effect.
Hence we begin by writing the rule current.directory.action.
<p>
We want to see how many operators will produce this effect.  
We can get this information from (operator-producing-pred machine.name),  
or the toplevel function opp.
<xmp>
USER(6): :opp current.directory

(PWD CD) 
</xmp>
This says the operators PWD and CD both have current.directory as their
effects.  So based on your knowledge about the domain,  you decide on 
the conditions when each of these operator would be used to solve the
current.directory goal.<p>
Here is the current.directory.action:
<xmp>
(defaction current.directory.action (?goal ?dir)
  (if (annotation ?goal find-out)
      (call-op (pwd ?dir) ?goal)
    (if (contemplate (pathname ?dir ?n))
	(call-op (cd ?dir ?n) ?goal)
      (fail))))
  </xmp>
It basically says if the goal is a find-out goal,  we should use PWD
to find out the current directory.  Otherwise we will do a CD to that
directory.  If none of these is the case,  then we'll fail.  
<p>
SAL actions are developed incrementally.  Here the current.directory.action
only solves .t goals.  We may or may not need to add additional code to
this action to support .f goals.  But initially one just need to focus
on the problem one wants to solved and worry about other cases when need
arise.  In fact most of the SAL actions does not distinguish between
find-out and satisfy goals because typically only the find-out variants
appears.
<p>

<hr>
<a name = "Trouble_Shooting">
<h3>APPENDIX F Trouble Shooting</h3>
</a>


I've tried to incorporate many error catching for Simon but I'm sure there
are still a lot of holes.  If Simon crashes,  please first make sure your
action is syntatically correct.  I've tried to check for syntax errors but
the parser is not powerful enough to catch all the problems.  Simon can
crash in unknown places if the action specification is syntatically incorrect.

If you're sure it's my fault,  then please let me (ctkwok@cs) know.  In 
your bug report it'd be helpful to include the actions involved,  the
action code itself if it's written by you,  and the trace of actions 
if there's any, or even the stack trace from :zoom if possible.
(Believe me... I'm not trying to discourage you :-)
<p>

<hr>
<a name = "The_tracer">
<h3>APPENDIX G The tracer</h3>
</a>
<br><p>
Under ACL 4.2 and CLIM2.0,  one can use a simple browse window to see what
Simon is doing.  Currently the tracer is quite simple and just output
a log of what Simon is trying to achieve as Simon moves along.  <p>

The <b>Options</b> button will bring up a list of options for printing out the
log.  For example if you're only interested in certain options,  you can
toggle them.  Ultimately you can set the default for what is interesting for
you in a variable *print-enabled* which is a list of what is interesting,
if you're interested you can look at interface.lisp and customize the 
variable.<p>

The <b>Clear</b> button removes all the text in the window.<p>

The <b>Save</b> button lets you save the trace in a file.  A dialog box asks 
you
the name of the file to save in,  and the file will be appended with the
trace if the file already exists.  <p>

The 3 checkboxes between menu bar and text window shows Simon's status
(executing, thinking and Idle).  <p>

Note: Whenever you have a new action typed to Simon,  the last trace will
be removed.  So you may want to save it if you want to reference it later.<p>
<p>
<hr>
Questions comments? You can mail me <a href="mailto:[e-mail]">here</a>.
<p><hr>
<tt><address>
  <a href="#top"> 
	Cody Kwok
  </a> <br>
  Last modified: 
	Tue Feb 14 15:07:25 PST 1995
</tt>

</body>
</html>