\chapter{Conclusions and Future Work}

In the previous chapters, we described our implementation of Transaction 
Logic Programming in the XSB Prolog environment. The program captures
the features in logic programming and database system by providing
elementary updates as well as bulk updates. We also described 
four prototypes and showed how they can be run in other 
Prolog environments, like Sicstus Prolog and Quintus Prolog, with some 
minor adjustments. It captures the features in logic programming and 
database system by providing elementary updates as well as bulk 
updates.

Our implementation shows the basic prototypes of Transaction 
Logic programming. There are still many issues left 
open, especially optimization issues. This chapter
suggests some possible directions for future work.

\begin{enumerate}

\item {\em Concurrent conjunction}. In the paper [$BK94$], Bonner 
	and Kifer extends Transaction Logic with connectives for 
	modeling the concurrent execution of complex actions. It allows 
	interleaving of transaction formulas, and can be used in 
	situations requiring synchronization and communications 
	between atoms. 

\item {\em More directives}. There are many built-in directives can be 
	added to improve the ease of use of the system. For example, removing
	of a transaction rule, undeclaring a database tuple and 
	destroying all related tuples, etc.

\item {\em Faster implementation on bulk updates}. Although tests showed 
	that execution time for bulk updates is linearly dependent on the 
	number of tuples in the database, the performance, 
	particularly in $bulk\_del/1$, could be improved. In 
	Prototype 4, $bulk\_del/1$ achieves reasonably good performance by 
	sacrificing the backtracking feature. 

\item {\em Write from scratch}. The current implementation is written in a 
	Prolog environment. This is too restrictive because there are 
	many Prolog interpreters, and each of them may provide different 
	built-in directives. If the program is loaded onto a system 
	which does not have the required Prolog interpreter, then users have 
	to modify the program themselves before running it. \\
	It would be better if the program could be run 
	directly from the UNIX environment by implementing Transaction 
	Logic in C. Without the restrictions of a Prolog interpreter, the 
	storage areas in Transaction Logic (transition oracle, 
	transaction base and database) could be separated physically, rather 
	than all residing in the Prolog database and conceptually 
	distinguishing them by the format of the rules.

\item {\em Storage optimization (i.e. garbage collection)}. Unlike Quintus 
	or Sicstus Prolog, XSB Prolog has two different directives for 
	removing predicates from the database, $retract/1$ and $retract\_nr/1$.
	In our implementation of \TRR, $retract/1$ is used to remove a 
	predicate from database. Section 5.1 showed that in XSB Prolog, 
	the \TR implementation takes longer to destroy a tuple than to 
	create one. The reason is that anytime when a tuple is destroyed, 
	the program releases the space used by the tuple. XSB
	Prolog provides a faster directive to retract a predicate, 
	$retract\_nr/1$, which performs what $retract/1$ does except that it
	does not reclaim space used by the retracted clause. 
	Using this directive, \TR can destroy a faster tuple with 
	the drawback that the system does not reclaim any program space for 
	predicates which are no longer in the database, which can result 
	in insufficient space for program execution later on.
	So, the system should reclaim the space automatically at suitable 
	interval, such as after each transaction query, or after 100 updates.

	A better way to destroy a tuple is in a manner similar to 
	$retract/1$ in Quintus Prolog (except that Quintus does not undo 
	updates during backtracking). In Quintus Prolog, the predicate 
	$retract/1$ may be used in a non-determinate fashion. It uses a 
	choice point to keep the data structure of the retracted clause on an 
	internal stack, for backtracking. The choice point is deleted when 
	backtracking is no longer possible on that clause, e.g., by a cut 
	($!$), or when execution terminates. To avoid inconsistencies, 
	the space of a retracted clause is reclaimed only when the system 
	determines there is no choice point on the stack that could 
	allow backtracking to the clause. 

\item {\em Allowing compile mode or database mode}. In many Prolog 
	interpreters, rules in a file can be inserted to the database 
	either by compiling the file or by asserting the rules dynamically. 
	In \TRR , since all updates are performed in database only,
	rules in a transaction base could be compiled. With the compiled
	rules, execution of transaction rules can be more efficient and
	we can also use this method to distinguish transaction base and
	database physically. At present, this method does not work well in 
	most Prolog interpreters because once a predicate is defined to be 
	dynamic, compiled code defining the same predicate cannot be inserted 
	into database. This is a problem because it is possible in Transaction 
	Logic that a database tuple (stored dynamically) and a transaction 
	formula (stored as compiled format) may define the same predicate.

\end{enumerate}


\begin{thebibliography}{}

\bibitem{AG91}
Alan Gibbons,
\newblock Algorithmic Graph Theory.
\newblock Cambridge University Press, 1991.

\bibitem{BK95}
Anthony J. Bonner and Michael Kifer,
\newblock Transaction Logic Programming.
\newblock {\em Technical Report CSRI-323}, Computer Systems Research Institute,
University of Toronto, April 1995. [BK95]

\bibitem{BK94}
Anthony J. Bonner and Michael Kifer,
\newblock Applications of Transaction Logic to Knowledge Representation
\newblock {\em In Proceedings of the International Conference on Temporal Logic (ICTL),
page 67-81}, July 1994.

\bibitem{BK93}
Anthony J. Bonner and Michael Kifer,
\newblock Transaction Logic: An (Early) Expose
\newblock In {\em Proceedings of the Workshop on Formal Methods in Databases and
Software Engineering}, Pringer-Verlag, Workshops in Computing Series, May 1993.

\bibitem{BW87}
Barry Wilkinson,  
\newblock Digital System Design
\newblock Prentice Hall 1987.

\bibitem{DW94}
David S. Warren, Konstantinos F. Sagonas and Terrance Swift,
the XSB Programmer's Manual Version 1.4.1,
SUNY at Stony Brook, 1994.

\bibitem{IB91}
Ivan Bratko,
\newblock Prolog Programming for Artifical Intelligence
\newblock Addison-Wesley, 1991.

\bibitem{JL87}
J. W. Llody,
\newblock Foundations of Logic Programming.
\newblock Springer-Verlag, 1987.

\bibitem{KS91}
Henry F. Korth and Abraham Silberschatz,
\newblock Database System Concepts.
\newblock McGraw-Hill, 1991.

\bibitem{SB89}
Sara Baase,
\newblock Computer Algorithms, Introduction to Design and Analysis.
\newblock Addison-Wesley, 1989.

\bibitem{UL89}
J.D. Ullman,
\newblock Principles of Database and Knowledge Base Systems.
\newblock Computer Science Press, 1989.

\end{thebibliography}
