\documentstyle[a4,epsf,alltt]{article}
\begin{document}


\include{commands}


\title{Editing your own programs}
\author{Jocelyn Ireson-Paine}
\maketitle


This handout shows you how to construct your own production system
programs. I assume that you've already read the notes on {\it
Introduction to the editor} and {\it Production systems}.


\section{Adapting one of my programs}   

The easiest way to start is by modifying a program that already exists.
This is useful if you just want to take one of my examples and alter its
resolution strategy or initial STM. Let's start by modifying the rules
in \verb/psbug2/. This is the bug that picks up coins and uses them to
get food out of a slot machine.

First, you need to tell the editor to copy the program into your own
{\it directory} or working area. Although the editor lets you examine my
programs via the \verb/showlib/ command, it won't let you change the
master copies. Get into Prolog, and give the editing command
\begin{verbatim}
showlib psbug2
\end{verbatim}
Because this is an editing command, you don't need a dot after it.
The editor will then display the code for \verb/psbug2/ on the screen.
You have done this already, in the production systems handout.

Next, you must tell the editor to copy this code into one of your own
files. Do this by giving the command
\begin{verbatim}
ENTER name mybug.pl RETURN
\end{verbatim}
This will create a file named \verb/MYBUG.PL/, and copy \verb/psbug2/
into it.

Finally, make whatever changes you want. Then exit the edit by doing
\begin{verbatim}
ENTER x RETURN
\end{verbatim}
This will save the file and return you to Prolog.

You can then run the new program by typing
\begin{verbatim}
eps( mybug, psworld2 ).
\end{verbatim}

Four notes on filenames. Firstly, program files must always end in
\verb/.pl/, an abbreviation for ``Prolog''. This suffix is called the
{\it file extension} or (less commonly) {\it file type}. If you omit it
or get it wrong, then various parts of the system will fail to find the
file, and your program will appear to have gone missing, or to be
unrunnable. Filenames can be in upper or lower case, but to save you
having to change case, use lower.

Secondly, when you use the \verb/eps/ command, the name of your bug
should be the same as the name of the filename, but without the
extension.

Thirdly, every time you do ENTER \verb/x/ RETURN, the editor saves a new
copy of your file. This is laid over the old copy, making it appear to
be inaccessible. However, it is actually still there. If you make a
mistake, and need to recover an old copy, I can do so for you.

Fourthly, do not give your files the same name as my examples. If you
do, you won't be able to get at the examples any more, because the
editor will choose your file in preference to mine.              


\section{Starting from scratch}   

If you want to start from scratch, then begin by using the \verb/ved/
command from Prolog. Let's say you wanted to create a brain called
\verb/NEWBUG.PL/. Then you would start by doing
\begin{verbatim}
ved newbug.pl
\end{verbatim}
This creates a new, empty, file.

Then type into it. When you have finished, do
\begin{verbatim}
ENTER x RETURN
\end{verbatim}

You can then use the code via \verb/eps/, in the same way as in the
previous section:
\begin{verbatim}
eps( newbug, psworld2 ).
\end{verbatim}

If you want to copy bits of other files, including ones got via
\verb/showlib/, into your file, there is a way to do so. It involves
marking text and using the ENTER commands \verb/d/ and \verb/yank/
together with ESC \verb/x/. See the \verb/ved3/ TEACH file for details.
You get to this by doing
\begin{verbatim}
teach ved3
\end{verbatim}
from Prolog.

For real experts, there's a shorter method using the \verb/ti/ and
\verb/to/ commands. Ask me for details, or see the \verb/mark/ HELP
file.


\section{Editing an existing file}

You do this in the same way as creating a new file. If your file were
called \verb/MYBUG.PL/, then you'd begin by doing
\begin{verbatim}
ENTER ved mybug.pl RETURN
\end{verbatim}
from Prolog.

Then edit the file and finish with
\begin{verbatim}
ENTER x RETURN
\end{verbatim}

Run it as before:
\begin{verbatim}
eps( mybug, psworld2 ).
\end{verbatim}


\section{Creating your own world}

By now, you might want to try making your own worlds as well as your own
bugs. See my handout on {\it Creating your own worlds} for this.


\section{Reference: syntax of production systems}

This is a short and incomplete summary of what can go into your PS
programs. When resources allow, it may be improved sometime in the
future. Also, I may need to add some more features. If you need help
understanding this, please ask.

A PS program contains the following:
\begin{itemize}

\item A \verb/resolve/ declaration. This is followed by a list containing
some of the letters \verb/p/, \verb/s/, \verb/r/, in some order, separated
by commas. Like all declarations and statements, it ends in a dot. Lists
start and end with square brackets.

Examples:
\begin{verbatim}
resolve [p,s,r].
resolve [s,p].
resolve [].
\end{verbatim}

How does it work? When it matches the rules, the PS may obtain more than
one candidate. If so, it looks at the first letter in the list; the
letters stand for ``priority'', ``specificity'', and ``recency''. Let's
say the first letter is a \verb/p/. Then the PS will sort the rules by
priority. This is a number you can attach with the word \verb/prio/, as
in \verb/psbug3/ --- if it is missing, 0 is assumed. After sorting, the
PS takes all the matched rules with the highest priority, and discards
the others.

Assume the next letter is \verb/s/. The PS then sorts these remaining
rules by complexity of condition, most complex first. At the moment, the
complexity measure is a count of the total number of arguments in the
left-hand side. After sorting, the PS takes the rules with highest
specificity and discards the rest.

Assume the next letter is \verb/r/. This denotes resolution by inverse
rule-firing recency. The PS sorts the remaining rules by order of the
time at which they last fired, never-fired rules counting highest. After
sorting, takes those with the highest score, and discards the rest.

If more than one rule remains, the PS takes one at random.

In \verb/psbug1/ and \verb/psbug2/, the recency resolution method has
been the most important.

\item A \verb/stm/ declaration. This gives the initial contents of STM.
For an example, see \verb/holidays/. Like \verb/resolve/, the thing
following \verb/stm/ is a list, this time of facts to be placed in STM.
Each one will be a predicate with or without arguments: see the handout
on {\it Production Systems (2)}.

Examples:
\begin{verbatim}
[ mp, hot ].
[].
[ loves(john,mary), loves(fred,bert) ].
[ pub(white_horse,broad_street,oxford,halls) ].
\end{verbatim}

\item One of the declarations \verb/stm_predicates/ or
\verb/perceptual_predicates/. For an example, see \verb/holidays/. The
declaration is followed either by the word \verb/all/ or by a list of
predicate names.

\begin{sloppypar}
If the declaration is \verb/stm_predicates/, it means that all the
predicates named (or \verb/all/ of them) are assumed to be in STM; any
others are perceptual. This is the case in \verb/holidays/. If the
declaration is \verb/perceptual_predicates/, it means that all the
predicates named (or \verb/all/ of them) are assumed to be perceptual or
action predicates, such as \verb/can_see/ and \verb/move_towards/. These
don't look at, or change, STM, but access perceptions and actions
directly.
\end{sloppypar}

Examples:
\begin{verbatim}
stm_predicates all.
stm_predicates [ loves, likes ].
perceptual_predicates [ can_see ].
perceptual_predicates all.
\end{verbatim}

If neither declaration is present, \verb/perceptual_predicates all/ is
assumed, as in \verb/psbug1/ and \verb/psbug2/.

\item A set of rules. Each rule has a left-hand side and a right-hand
side, separated by \verb/=>/. Like other statements, rules all end in a
dot. Examples are:                 
\begin{verbatim}
toilet_cleaner => poor, bored.
can_see(w),over(w) => exec([use]).
\end{verbatim}

The left-hand side is a set of {\it goals}, separated by commas. The
goals are predicates with or without arguments, see {\it Production
Systems (2)} for more info. The comma means ``and''. That is, the rule
will match if {\it all} the goals are simultaneously true. That is, if
all the perceptual goals are satisfied by what the bug's perceptions
tell it, and if all the data indicated by the STM goals is in STM.

The right-hand side is a set of actions, separated by commas. Each
action is either an STM goal , or a motor goal. Obeying an
STM goal puts the relevant data into STM; obeying a motor
goal --- well, obeys it.

One special motor goal is \verb/exec/. This takes a primitive
bug-action as argument, where the action is a list. Examples are:
\begin{verbatim}
exec( [forward] )
exec( [right] )
\end{verbatim}

A rule may be preceded by an optional priority, of the form (e.g.)
\verb/1 prio/ or \verb/23 prio/. You can have as many different priority
levels as you want in one program; the default is zero. See the
description above of resolution-by-priority for how priorities are used.
Example of a rule with priority:
\begin{verbatim}
1 prio thirst(T),T>20,can_see(w) => move_towards(w).
\end{verbatim}

\end{itemize}


\subsection{How rule conditions are tested}

The left-hand side of a rule are made up from a series of goals. Each
goal is a predicate, with or without arguments.

The left-hand side is taken to be true (aka ``matches'', or ``is
satisfied'', or ``succeeds'') if all the predicates are true. Only rules
with true left-hand sides are passed on to the resolution stage.

Argumentless goals are just names, such as \verb/mp/. An
argumentless perceptual goal is true if the perceptual condition it
denotes is currently true. (At the moment, I have no such
predicates.)

An argumentless STM goal is true if the same symbol --- its name
--- appears in the current STM. Thus the STM goal \verb/mp/ is
true if the symbol \verb/mp/ is in the current STM.

Goals with arguments consist of a predicate name, immediately followed
by an open bracket, a sequence of arguments separated by commas, and a
close bracket.

Each argument can be:
\begin{itemize}

\item A constant. This is either a number, such as \verb/1/ or
\verb/-4.982/, or a name, such as \verb/w/ or \verb/bug/. Names stand
for particular ``things'': individuals, properties, classes, etc. 

Most names contain only lower-case letters:
\begin{verbatim}
fred
bug_237
pizza2go
\end{verbatim}
Such a name must start with a lower-case letter, and this can be
followed by any number of lower-case letters, digits, or underlines.

If you want a name to contain upper-case letters, it must be surrounded
by single quotes, \verb/'/. This is why, in the slot-machine-using bugs,
the \verb/'S'/ is in quotes. Do not leave the quotes off a name like
\verb/'S'/. If you do, it will be treated as a variable, which means
something quite different. The only time you will need to use such names
is when they are used as Eden objects.

Lower-case names can be quoted, but need not: \verb/w/ and \verb/'w'/
mean the same thing.

Names can also be a special non-alphabetic symbol or sequence of
symbols, such as \verb/+/. Some such symbols have to be quoted, but the
ones I shall use all don't. As with upper-case letters, the
only time you need to use such names is when they are used as Eden
objects.

\item A variable. Variables are either the special underline symbol,
\verb/_/, or start with a capital letter, such as \verb/Someone/ or
\verb/T/. This is the main use of capitals in Prolog.

\end{itemize}

How do predicates with arguments work in goals?

Let's deal with predicates having all constant arguments first.
A perceptual predicate with constant arguments is true if the
corresponding perceptual condition is satisfied. Thus \verb/can_see(w)/
is true only if the bug can currently see water.

An STM predicate with constant arguments is true if exactly the same
group of symbols (the same ``fact'') appears in STM. Thus the STM
predicate \verb/loves(john,mary)/ would be true only if the fact
\verb/loves(john,mary)/ appeared in the current STM. Note that it would
{\it not} be satisfied by any of
\begin{verbatim}
loves(mary,john)
loves(john)
loves
loves(john,mary,today)
\end{verbatim}

Now for predicates with variables. These stand for any constant in what
should be an obvious way. Thus, the perceptual predicate
\verb/can_see(X)/ is true if the bug can see anything at all. In fact,
this condition is always true, since the bug can always see at least a
space!

STM predicates with variable arguments are true if there is a fact with
the same predicate name and number of arguments in STM, and if any
constant arguments match. Thus, the STM predicate \verb/loves(X,mary)/
is true if any of the follwing are in STM:
\begin{verbatim}
loves( john, mary )
loves( bert, mary )
loves( 33.4, mary )
\end{verbatim}

If the same variable occurs twice in a predicate, then it must denote
the same constant. Thus \verb/loves(X,X)/ is satisfied by
\begin{verbatim}
loves(john,john)
\end{verbatim}
and
\begin{verbatim}
loves(mary,mary)
\end{verbatim}


\subsection{``And'' and variables}

A left-hand side is true if all its goals are. When saying this, all the
variables must be interpreted consistently. Thus we might have the
left-hand side
\begin{verbatim}
can_see(X), want(X)
\end{verbatim}
where \verb/want(X)/ is an STM goal. This would be true if the bug wants
food and can see food, or if it wants water and can see water, etc. It
would not be true if the bug wanted only water but could see only food.

There is one special exception to this. If two \verb/_/ variables appear
in the same left-hand side, they need not stand for the same object. So
\begin{verbatim}
can_see(_), want(_)
\end{verbatim}
could be true if the bug wanted only water but could see only food.

Similarly, \verb/loves(_,_)/ could be true if the STM contains only the
fact \verb/loves(john,mary)/.


\subsection{Numerical conditions}

There are a few special conditions, written using the symbols
\begin{verbatim}
>   <
>=  =<
=   \=
\end{verbatim}
These are used in comparisons.

The symbols \verb/</ and \verb/>/ have their usual mathematical meaning.
The symbols \verb/=</ and \verb/>=/ mean ``less than or equal'' and
``greater than or equal''. They can only be used when comparing numbers.
In general, one --- possibly both --- of the numbers will be in a
variable taken from an earlier goal in the same rule. Thus,
\begin{verbatim}
thirst(T), T > 20
\end{verbatim}
For examples, see
\begin{verbatim}
eps( skier, psworld0 ).
\end{verbatim}

The symbols \verb/=/ and \verb/\=/ can compare numbers or names. The
second means ``not equal''.


\subsection{Negation}

Any goal can be enclosed by a \verb/not(...)/. This inverts its truth.
Thus
\begin{verbatim}
not(holding(+))
\end{verbatim}
is true if
\begin{verbatim}
holding(+)
\end{verbatim}
is false, i.e. when the bug is holding something other than food.


\subsection{How rule right-hand sides are obeyed}

A right-hand side can consist of STM goals and motor goals, separated by
commas. These goals are obeyed strictly from left to right.

Obeying an STM goal puts the symbols into STM.

Obeying a motor goal causes the bug to perform (or more accurately, to
try performing) the corresponding action.

One special motor goal is \verb/exec/. As already described, this obeys
a single action.

There is a special STM goal, \verb/erase/. This removes its argument
from STM. Thus the rule
\begin{verbatim}
over(w) => exec([use]), erase( i_need(water) ).
\end{verbatim}
would erase the fact \verb/i_need(water)/ from STM.

\end{document}
