Event Handling in CTR
                   ---------------------

Syntactically, an event is a function term, and to raise (or throw) an
event, E, a CTR program simply executes the atom throw(E).
Semantically, throw(E) simply inserts an atom of the form event(E)
into the database.  The CTR interpreter currently handles two kinds of
events: exceptions and interrupts.  An exception is a function term of
the form exception(X), and an interrupt is a function term of the form
interupt(X), where in both cases X is a function term.

To catch and handle events, we use what appears to be a second-order
predicate, try(G,E,H), where E is an event, and G (the goal) and H
(the event handler) are TR programs.  (For the time being, G and H
must be atomic formulas, but they can still be complex programs
defined by rules.)  If G throws an event, then its execution is
suspended.  If the event unifies with E, then the handler H is
executed; otherwise, the event is thrown up to the next level, so that
some other try can catch it.

The program (G) that raised the event may or may not be resumed after
the event is handled.  If the event is an interupt, then the program
is resumed.  If the event is an exception, then the program is not
resumed.  For example, suppose that the atom g is defined by the
following rules:

   g <- a x b x c x check x e x f.

   check <- phi.
   check <- [~phi] x throw(exception(yuck)).

Now consider the following program:

        try(g, exception(yuck), ins(error))

It tries to execute the goal g.  In doing so, it first executes a,
then, b, then c.  It then checks that phi is true, and if so, it
continues by executing e and then f.  However, if phi is false, then
it throws the exception "yuck".  The try captures this exception, and
handles it by inserting the atom "error" into the database.  In this
case, g terminates after the exception is handled, so e and f are not
executed.

Semantically, try(G,E,H) is a kind of macro.  The idea is that a CTR
program with trys is transformed into a CTR program without trys.
Thus, try(G,E,H) is a syntactic abbreviation for a more complex CTR
program.  The transformation is global, and it causes every rule in
the transaction base to be modified, but in a pretty simple way.
Intuitively, the modification is equivalent to continual polling of
the database to see if any event tuples have been inserted into it.

The CTR interpreter doesn't actually do the transformation.  The
transformation is a specification of how a CTR program with trys is
suppose to behave, and the interpreter implements the spec through
other means.  In fact, it was not hard to modify the CTR interpreter
to do handle events.  The source code is in the file ctr, which is the
kernel of the CTR interpreter.  This file contains a detailed
description of the implementation of events, as well as of the
implementation of all the CTR operators.


NOTE: the exception handler uses two database predicates which must be
declared in a CTR database by the following two lines:

        updatable event/2.
        updatable maxChannel/1.

These lines can be found in the sample CTR databases in this directory
(ie, the files workflow.db and short.db).