Small changes.

git-svn-id: https://yap.svn.sf.net/svnroot/yap/trunk@1816 b08c6af1-5177-4d33-ba66-4b1c6b8b522a

docs/index/iclp07.tex

@@ -95,46 +95,49 @@
 
 \section{Introduction}
 %=====================
-The WAM~\cite{Warren83} has been both a blessing and a curse for
+The WAM~\cite{Warren83} has mostly been a blessing but occasionally
-Prolog systems. Its ingenious design has allowed implementors to get
+also a curse for Prolog systems. Its ingenious design has allowed
-byte code compilers with decent performance --- it is not a fluke that
+implementors to get byte code compilers with decent performance --- it
-most Prolog systems are still based on the WAM. On the other hand,
+is not a fluke that most Prolog systems are still based on the WAM. On
-\emph{because} the WAM gives good performance in many cases,
+the other hand, \emph{because} the WAM gives good performance in many
-implementors have felt reluctant to explore alternatives that
+cases, implementors have not incorporated in their systems many
-drastically depart from its basic philosophy.
+features that drastically depart from WAM's basic characteristics.
 %
-For example, first argument indexing makes sense for many Prolog
+For example, first argument indexing is sufficient for many Prolog
-applications. For applications accessing large databases though is
+applications. However, it is clearly sub-optimal for applications
-clearly sub-optimal; for long time now, the database community has
+accessing large databases; for a long time now, the database community
-recognized that good indexing mechanisms are the basis for fast query
+has recognized that good indexing is the basis for fast query
 processing.
 
 As logic programming applications grow in size, Prolog systems need to
 efficiently access larger and larger data sets and the need for any-
 and multi-argument indexing becomes more and more profound. Static
-generation of multi-argument indexing is one alternative. However,
+generation of multi-argument indexing is one alternative. The problem
-this alternative is often unattractive because it may drastically
+is that this alternative is often unattractive because it may
-increase the size of the generated byte code unnecessarily. Static
+drastically increase the size of the generated byte code and do so
-analysis techniques can partly address this concern, but in
+unnecessarily. Static analysis can partly address this concern, but in
 applications that rely on features which are inherently dynamic (e.g.,
 generating hypotheses for inductive logic programming data sets during
-runtime) they are inapplicable or grossly inaccurate. Another
+runtime) static analysis is inapplicable or grossly inaccurate.
-alternative, which has not been investigated so far, is to do flexible
+Another alternative, which has not been investigated so far, is to do
-indexing on demand during program execution.
+flexible indexing on demand during program execution.
 
-This is precisely what we advocate in this paper. More specifically,
+This is precisely what we advocate with this paper. More specifically,
-we present a minimal extension to the WAM that allows for flexible
+we present a small extension to the WAM that allows for flexible
 indexing of Prolog clauses during runtime based on actual demand. For
 static predicates, the scheme we propose is partly guided by the
 compiler; for dynamic code, besides being demand-driven by queries,
-the method needs to cater for code updates during runtime. In our
+the method needs to cater for code updates during runtime. Where our
-experience these schemes pay off. We have implemented \JITI in two
+schemes radically depart from current practice is that they generate
-different Prolog systems (Yap and XXX) and have obtained non-trivial
+new byte code during runtime, in effect doing a form of just-in-time
-speedups, ranging from a few percent to orders of magnitude, across a
+compilation. In our experience these schemes pay off. We have
-wide range of applications. Given these results, we see very little
+implemented \JITI in two different Prolog systems (Yap and XXX) and
-reason for Prolog systems not to incorporate some form of indexing
+have obtained non-trivial speedups, ranging from a few percent to
-based on actual demand from queries. In fact, we see \JITI as only the
+orders of magnitude, across a wide range of applications. Given these
-first step towards effective runtime optimization of Prolog programs.
+results, we see very little reason for Prolog systems not to
+incorporate some form of indexing based on actual demand from queries.
+In fact, we see \JITI as only the first step towards effective runtime
+optimization of Prolog programs.
 
 This paper is structured as follows. After commenting on the state of
 the art and related work concerning indexing in Prolog systems
@@ -231,11 +234,6 @@ support for indexing that the WAM provides, but we will extend this
 support with the technique of \JITI that we describe in the next
 sections.
 
-%\begin{itemize}
-%\item Just-In-Time and dynamic compilation techniques (VITOR, IS THERE
-%  ANYTHING FOR PROLOG?)
-%\end{itemize}
-
 
 \section{Indexing in the WAM} \label{sec:prelims}
 %================================================
@@ -853,6 +851,12 @@ simply be regenerated.
 
 \section{Demand-Driven Indexing of Dynamic Predicates} \label{sec:dynamic}
 %=========================================================================
+We have so far lived in the comfortable world of static predicates,
+where the set of clauses to index is fixed beforehand and the compiler
+can take advantage of this knowledge. Dynamic code introduces several
+complications. However, note that most Prolog systems do provide
+indexing for dynamic predicates. In effect, they already deal with
+these issues.
 
 
 \section{Performance Evaluation} \label{sec:perf}