\comment{Introduction} This tutorial provides a step-by-step introduction to CORAL through the use of example programs. All programs and data-sets in this tutorial are available as part of the CORAL release, in the directory named {\em doc/examples}. The file containing the program is named when the program is presented. CORAL is an interactive system that is invoked by the command {\tt coral} at the UNIX prompt. You will then see the CORAL prompt $1>$, from which you can create, modify and execute programs. CORAL can also be used essentially as a C++ extension. In this mode, as usual there is a main program and, possibly, several subprograms. There are many ways to look at CORAL. It can be viewed as a (deductive) database query language, a logic programming language, or as an extension of C++ that provides support for creating and manipulating relations. An extensive {\em declarative} sublanguage is supported, and this can be used to define relations (or views, in relational database terminology). In addition, a layer of constructs is provided to allow easy manipulation of relations --- either explicitly stored relations or defined relations --- in C++ code. \subsection{A Guide to this Document} The following are some of the notable aspects of the CORAL system. They are addressed in detail in one or more sections of this document. \heading{Declarative Language Features} A powerful language based on Horn clause rules is supported. For programs containing only pure Horn clauses, the declarative {\em least fixpoint} or {\em least Herbrand model} semantics is supported. Intuitively, this means that rules can be understood simply as if-then statements in logic, without regard to the order of evaluation. Programs with {\em negation} or {\em set-grouping} are restricted to be {\em left-to-right modularly stratified}. For such programs, the {\em well-founded model} semantics is supported. The intuitive reading of programs as if-then statements is preserved. Programs can also be evaluated in {\em pipelined} fashion, very similar to Prolog execution. {\em Relevant Sections}: ~~~~~~~~~~\ref{chap:declba}, \ref{chap:declne}, \ref{chap:declse}, \ref{chap:declad}, \ref{chap:modules}, \ref{chap:pipe}, \ref{chap:proghints} \heading{The Module System} A CORAL program is a collection of {\em modules}, and every module can be understood simply as defining one or more exported {\em relations}, or sets of facts. {\em Relevant Sections}: ~~~~~~~~~~\ref{chap:modules} \heading{Control Features} The evaluation of declarative modules can be refined by the user through high-level annotations that provide hints to the compiler. In particular, the user can optionally control the use of subsumption checks, add indices, influence the order in which inferences are made and when facts are discarded, choose from a variety of optimizing program transformations, specify when a single answer is sufficient, choose pipelined or memoing evaluation strategies, etc. The user is not required to specify any of this control information since the system makes default decisions in the absence of user-specified annotations. While the range of features available for controlling the evaluation is extensive, efficient programs can be written by keeping in mind some simple points, given a broad understanding of the underlying evaluation techniques. A summary of these points is presented in \ref{chap:proghints}. {\em Relevant Sections} ~~~~~~~~~~~\ref{chap:modules}, \ref{chap:declac}, \ref{chap:proghints} \heading{Persistent Relations} Disk-resident persistent relations are supported using the EXODUS storage manager \cite{cdrs86:exodus:manager}. {\em Relevant Sections} ~~~~~~~~~~~~\ref{chap:cmds} \heading{Multiple Workspaces} A workspace is a collection of relations, each defined by an explicit collection of facts or by a collection of rules. A user can simultaneously maintain several workspaces and switch between them. All queries are evaluated against the current workspace. {\em Relevant Sections}: ~~~~~~~~~~~~\ref{chap:cmds} \heading{I/O} Both fact-at-a-time and relation-at-a-time I/O are supported. Relations can be read in or written out in relational form (i.e. each tuple as a predicate name followed by arguments) or in tabular form (i.e. each tuple as just a vector of arguments), in sorted order if desired. (More information is available through the $help$ command; type $help(io)$.) \heading{Debugging and Profiling} The execution of a program can be traced and profiled. There is also an {\em explanation} facility that allows users to examine the {\em derivation trees} for generated facts using a graphical menu-driven interface. {\em Relevant Sections}: ~~~~~~~~~~\ref{chap:cmds} \heading {CORAL--C++ Interface } CORAL provides an interface to C++. Some constructs are added to C++ to enable the user to manipulate relations easily. This extended C++ can be used to define relations just as in other CORAL modules. However, such code has to be linked with the CORAL system code, and this is a relatively slow process. We therefore recommend that imperative modules be used sparingly. However, imperative modules are very useful in adding new data types to CORAL or in extending the set of built-in functions. {\em Relevant Sections} ~~~~~~~~~~~~~\ref{chap:impmod} and \ref{chap:extens} \heading{Extensibility} CORAL is extensible in many ways: new data types as well as new relation and index implementations can be added. {\em Relevant Sections} ~~~~~~~~~~~~\ref{chap:extens} \subsection{Other Documentation} The reader is referred to ``An Overview of CORAL'' \cite{rsss93:coraloverview} for an overview. The overview complements this tutorial introduction by elaborating upon issues introduced and illustrated here, and the two documents are intended to be used in conjunction. In addition, there is an on-line {\em help} command. See ``Implementation of the CORAL Deductive Database System'' \cite{rsss:coral:impl} for a description of how CORAL is implemented.