
		 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
		 %	    EXTENSIONS		%
		 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Enabling extensions to the Prolog language}
\label{sec:prologext}

SWI-Prolog has been developed in the context of projects many of which
caused the development to focus on managing Web documents and protocols.
In the previous sections we have described our Web enabling libraries.
In this section we describe extensions to the ISO-Prolog standard
\cite{Deransart:96} we consider crucial for scalable and comfortable
deployment of Prolog as an agent in a Web centred world.

\subsection{Multi-threading}
\label{sec:mt}

% Concurrency requirements

Concurrency is necessary for applications for the following reasons:

\begin{itemize}
    \item
Network delays may cause communication of a single transaction to take
very long. Such clients may not block access for other clients. This
can be achieved using multiplexed I/O, multiple processes handling
requests in a pool or multiple threads in one or more processes handling
requests in a pool.

    \item 
CPU intensive services must be able to deploy multiple CPUs. This can be
achieved using multiple instances of the service and load-balancing or a
single server running on multi-processor hardware or a combination of
the two.
\end{itemize}

As indicated, none of the requirements above require multi-threading
support in Prolog. Nevertheless, we added multi-threading
\cite{Wielemaker:03c} because it resolves the problems mentioned above
for medium-scale applications while greatly simplifying deployment and
debugging in a platform independent way. A multi-threaded server also
allows maintaining state for a specific session or even shared between
multiple sessions simply in the Prolog database. The advantages of this
are described in \cite{aurora-www}, using the or-parallel Aurora to
serve multiple clients. This is particularly interesting for accessing
the RDF database described in \secref{rdfdb}.


\subsection{Atoms and Unicode support}
\label{sec:unicode}

Unicode\footnote{\url{http://www.Unicode.org/}} is a character encoding
system that assigns unique integers (code-points) to all characters of
almost all scripts known in the world. In Unicode 4.0, the code-points
range from 1 to 0x10FFFF. Unicode can handle documents from different
scripts as well as documents that contain multiple scripts in a single
uniform representation, an important feature in applications processing
Web data. Traditional HTML applications commonly insert special symbols
through entities such as the copyright (\copyright) sign, Greek and
mathematical symbols, etcetera. Using Unicode we can represent all
entity values as plain text. As illustrated in the famous
\jargon{Semantic Web layer cake} in \figref{swcake}, Unicode is at the
heart of the Sematic Web.

\begin{figure}
    \centerline{\includegraphics[width=0.3\linewidth]{swcake}}
    \caption{The Semantic Web layer cake by Tim Burners Lee}
    \label{fig:swcake}
\end{figure}

\urldef{\unicodeuri}\url{http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref}%
HTML documents can be represented using Prolog strings because Prolog
integers can represent all Unicode code-points. As we have claimed in
\secref{markupdom} however, using Prolog strings is not the most obvious
choice. XML attribute names and values can contain arbitrary Unicode
characters, which requires the unnatural use of strings for these as
well. If we consider RDF, URIs can have arbitrary Unicode
characters\footnote{\unicodeuri} and we want to represent URIs as atoms
to exploit compact storage as well as fast equivalence testing. Without
Unicode support in atoms we would have to encode Unicode in the atom
using escape sequences. All this patchwork can be avoided if we demand
the properties below for Prolog atoms.

\begin{itemize}
    \item Atoms represent text in Unicode
    \item Atoms have no limit on their length
    \item The Prolog implementation allows for a large number of
          atoms, both to represent URIs and to represent text in
	  HTML/XML documents. SWI-Prolog's limit is $2^{25}$ 
	  (32 million).
    \item Continuously running servers cannot allow memory leaks
          and therefore processing dynamic data using atoms
	  requires atom garbage collection.
\end{itemize}



