\chapter{Restrictions and Current Known Bugs}

In this chapter we indicate some features and bugs of XSB that may
affect the users at some point in their interaction with the system.

If at some point in your interaction with the system you suspect that
you have run across a bug not mentioned below, please report it to
{\tt (xsb-contact@cs.sunysb.edu)}.  Please try to find the {\em
smallest} program that illustrates the bug and mail it to this address
together with a script that shows the problem.  We will do our best to
fix it or to assist you to bypass it.

\section{Current Restrictions}
\label{sec:CurrentRestrictions}

\begin{itemize}
\item The maximum arity for predicate and function symbols is 255.
%
\item The maximum length of atoms that can be stored in an XSB
      \emph{object} code file is in principle $2^{32}-1$, but in
      practice it is $2^{28}-1$ (i.e., in 32-bit platforms it is
      bounded by the size of the maximum integer; see below).
%
\item In the current version, you should never try to rename a byte code 
      file generated for a module, though you can move it around in your 
      file system.  Since the module name is stored in the file, renaming it
      causes the system to load it into wrong places.  However, byte code 
      files for non-modules can be renamed at will.
%
\item XSB allows up to 1 Gigabyte of address space for 32-bit SUNs and 512
      Megabytes of address space for other 32-bit platforms.  For SUNs the
      address space for integers is $-2^{28}$---$(2^{28}-1)$.  For
      MIPS-based machines (e.g. Silicon Graphics machines), the
      address space for integers is $-2^{26}$---$(2^{26}-1)$.  For all
      other machines it is $-2^{27}$---$(2^{27}-1)$.  This restriction can
      cause unexpected results when numbers are computed.  The amount
      of space allowed for floating point numbers is similar for each
      machine.  For 64-bit platforms, addresses, integers, and
      floating point numbers are all stored in 60 bits. However, as the
      \emph{object} code file format is the same as for the 32-bit versions,
      compiled constants are subject to 32-bit limitations.
%
\item	Indexing on floating-point numbers does not work, since, as
implemented in XSB, the semantics
      of floating-point unification is murky in the best case. Therefore, it
      is advisable that if you use floating point numbers in the first 
      argument of a procedure,  that you explicitly index the
      predicate in some other argument.
%
\item	The XSB compiler cannot distinguish the occurrences of a
      0-ary predicate and a name of a module (of an import declaration) as
      two different entities.  For that reason it fails to characterise the
      same symbol table entry as both a predicate and a module at the
      same time.  As a result of this fact, a compiler error is issued
      and the file is not compiled.  For that reason we suggest the
      use of mutually exclusive names for modules and 0-ary predicates,
      though we will try to amend this restriction in future versions of
      XSB.
%
\item Subsumption-based tabled predicates may not be \emph{delayed}.
      \index{tabling!subsumption-based!interaction with negation}
      Consequently,
      \begin{itemize}
      \item the truth value of a negative call on a subsumptive predicate
	    must be known at completion of the producing call, thus
	    avoiding a \emph{negative delay} of this negative call, and
      \item only unconditional answers may be derived for a subsumptive
	    predicate, thus avoiding the \emph{positive delay} of calls
	    which consume such an answer.
      \end{itemize}
      Violations of either of these conditions raise an exception and
      abort the computation.
%
\end{itemize}

\section{Known Bugs}

\begin{itemize}
\item The current version of XSB does not fully support dynamic code.
In fact the declartion {\tt :- dynamic} essentially instructs XSB to
fail on that code if it is undefined.
%
\item Currently the C foreign language interface does not work when
      XSB is {\em also} compiled with the Oracle interface on Solaris.
% I think this is mostly fixed: tls
%\item Explicit compilation (using {\tt compile/1}) of {\em very} large
%      files {\em may} cause a core dump due to unfinished memory
%      management.
\item Variables that appear in {\em compiled} arithmetic comparison
      predicates should only be bound to numbers and not evaluable
      arithmetic expressions.  That is, the variables are not evaluated
      to obtain an arithmetic value, but the XSB compiler assumes
      that they are evaluated.  For example, executing compiled code for
      the following program will cause an {\tt "Arithmetic exception"}
      error:
      \begin{verbatim}
            p(X) :- X =:= 1.

            ?- p(cos(0)).
      \end{verbatim}
      This behaviour is only exhibited in {\em compiled} code.
% Currently this solution does not work: kostis
%     For variables that is not known whether they will always be bound to
%     numbers, it is advisable that these variables are evaluated
%     by using {\tt is/2}.  In our example, predicate {\tt p/1} could
%     be written as:
%     \begin{verbatim}
%           p(X) :- X1 is X, X1 =:= 1.
%     \end{verbatim}
\item The reader cannot read an infix operator immediately followed 
      by a left parenthesis.  In such a case you get a syntax error.
      To avoid the syntax error just leave a blank between the infix
      operator and the left parenthesis.  For example, instead of 
      writing:

      \demo{	| ?- X=(a,b).}

      \noindent
      write:

      \demo{	| ?- X= (a,b).}
%
\item The reader cannot properly read an operator defined as both a
      prefix and an infix operator.  For instance the declaration 
      \begin{verbatim}
                :- op(1200,xf,'<=').
                :- op(1200,xfx,'<=').
      \end{verbatim}
      will lead to a syntax error.
%
\item When the code of a predicate is reloaded many times, if the old 
      code is still in use at the time of loading, unexpected errors may 
      occur, due to the fact that the space of the old code is reclaimed
      and may be used for other purposes.
\item Currently, term comparisons ({\tt ==},{\tt @<=},{\tt @<},{\tt
      @>}, and {\tt @>=}) do not work for terms that overflow the
      C-recursion stack (terms that contain more than 10,000 variables
      and/or function symbols).
\end{itemize}

