.\" ------------------------------ sec4.t ------------------------------
.sh 1 "SB-Prolog: Operational Semantics"
.sh 2 "Standard Execution Behaviour"
.pp
The normal execution behaviour of SB-Prolog follows the usual left to right
order of literals within a clause, and the textual top to bottom order of
clauses for a predicate.  This corresponds to a depth first search of the
leftmost SLD-tree for the program and the given query.  Unification without
occurs check is used, and execution backtracks to the most recent choice
point when unification fails.
.sh 2 "Cuts and If-Then-Else"
.pp
This standard execution behaviour of SB-Prolog can be changed using
constructs like \fIcut\fR (`!') and \fIif-then-else\fR (\^`\->'\^).  In
SB-Prolog, cuts are usually treated as \fIhard\fR, i.e. discard choice points
of all the literals to the left of the cut in the clause containing the cut
being executed, and also the choice point for the parent predicate, i.e.
any remaining clauses for the predicate containing the cut being executed.
There are some situations, however, where the scope of a cut is restricted
to be smaller than this.  Restrictions apply under the following conditions:
.np
The cut occurs in a term which has been constructed at runtime and called
through \fIcall\fR/1, e.g. in
.(l C
 ..., X = (p(Y), !, q(Y)), ..., call(X), ...
.)l
In this case, the scope of the cut is restricted to be within the \fIcall\fR,
unless one of the following cases also apply and serve to restrict its
scope further.
.np
The cut occurs in a negated goal, or within the scope of an if-then-else.
In these cases, the scope of the cut is restricted to be within the
negation or the if-then-else.
.lp
In cases involving nested occurrences of these situations, the scope of the
cut is restricted to that for the deepest such nested construct, i.e. most
restricted.  For example, in the construct
.(l C
 ..., not( (p(X) \-> not( (q(X), (r(X) \-> s(X) ; (t(X), !, u(X)))) )) ), ...
.)l
the scope of the cut is restricted to the inner if-then-else, and does not
affect any choice point that may have been set up for q(X).  
.pp
The behaviour of the \fIif-then-else\fR operator `\->' is as follows: when
executing the goal
.(l C
\fIP\fR \-> \fIQ\fR ; \fIR\fR
.)l
if \fIP\fR succeeds, then any alternatives for \fIP\fR are discarded and \fIQ\fR
is tried, while if \fIP\fR fails then \fIR\fR is tried.  Thus, \-> may be
thought of as

.(l
	\fIP\fR \-> \fIQ\fR ; \fIR\fR :\- \fIP\fR, !, \fIQ\fR.
	\fIP\fR \-> \fIQ\fR ; \fIR\fR :\- \fIR\fR.
.)l

The scoping of cuts within if-then-elses is consistent with this
conceptualization.
.sh 2 "Unification of Floating Point Numbers"
.pp
As far as unification is concerned, no type distinction is made between
integers and floating point numbers, and no explicit type conversion is necessary
when unifying an integer with a float.  However, due to the finite precision
representation of floating point numbers and cumulative round-off errors in
floating point arithmetic, comparisons involving floating point numbers may
not always give the expected results.  An effort is made to minimize surprises
by considering two numbers \fIx\fR and \fIy\fR (at least one of which is a float)
to be unifiable if |\^|\^\fIx\fR\^| \- |\^\fIy\fR\^|\^|/\fImin\fR(|\^\fIx\fR\^|, |\^\fIy\fR\^|)
to be less than 10\*[\-5\*].  However, this does not guarantee
immunity against round-off errors.  For the same reason, users are warned
that indexing on predicate arguments (see Section 13) may not give the
expected results if floating point numbers are involved.
.bp
.\" ---------------------- end of sec4.t ----------------------

.