% File: tycoondemo.tex
% Date: 20.9.1991
% Author: FM
% Subject: FIDE Tycoon demo

\documentstyle[11pt,a4,epsf]{article}

\title{FIDE Tycoon Environment Demonstration}
\author{2nd Annual FIDE Review Meeting, Glasgow \\ \ \\
J.W.~Schmidt, F.~Kirch, F.~Matthes, S.~M\"ussig \\
Hamburg University}
\date{September 1991}

\newcommand{\k}[1]{{\tt #1}}
\newcommand{\figwidth}{14cm}

\pagestyle{myheadings}
\markright{FIDE Tycoon Environment Demonstration, September 1991}
\begin{document}
\maketitle

\section*{Objectives of the Demo}
\begin{itemize}
\item In addition to traditional database system services (data storage,
data sharing, access optimization and integrity management), novel demands of
future database applications have to be addressed by FIDE languages and
supported by their language processors:
      \begin{itemize}
      \item Generic, reusable application software;
      \item Safe, generic interfaces to services in open systems;
      \item Non-standard data structures;
      \item Non-standard execution paradigms (functions, methods, rules,
            triggers).
      \end{itemize}

\item The Tycoon project complements the DBPL project efforts by
focussing on these novel, highly generic aspects of data-intensive
applications. The first phase of the Tycoon project exploits existing
state-of-the-art language technology to investigate

\begin{description} 
\item[Linguistic Support] \ 
  \begin{itemize}
  \item types as first-class language entities \\ (naming, kinding,
        parameterization, recursion, scoping) 
  \item module and binding mechanisms for database environments
  \item higher-order functions
  \item exception handling
  \end{itemize}

\item[Add-On Library Support] \
  \begin{itemize}
  \item user-defined types, type operators and kinds
  \item iteration abstractions
  \item generalized bulk structures
  \item external call interfaces
  \end{itemize}

\item[Built-In System Support] \
  \begin{itemize}
  \item persistence management and object identification
  \item garbage collection
  \item stability mechanisms 
  \item interactive interfaces and dynamic binding
  \end{itemize}
\end{description}
\end{itemize}

\newpage
\section*{Structure of the Demo}
\begin{enumerate}
\item Tycoon Environment Overview
\item Strongly-Typed, Generic User Interface Construction
     \begin{enumerate}
     \item Display example data
     \item Show database schema
     \item Update, insert and delete example data
     \item Instantiate a generic display routine
     \item Extend the example display program
     \item Introduce integrity checking code
     \end{enumerate}
%\item Add-On Iteration Abstraction
%     \begin{enumerate}
%     \item Iteration over add-on bulk structures
%     \item Boolean query
%     \item Selection query
%     \item Join query
%     \item View definition
%     \end{enumerate}
\item Built-In Persistence Management
     \begin{enumerate}
     \item Checkpointing the database
     \item Garbage collection
     \item Program recovery
     \end{enumerate}
\end{enumerate}


\newpage
\section{Tycoon Environment Overview}

\begin{itemize}
\item Tycoon application programming environment:
    \begin{itemize}
    \item standard environment (27 modules)
    \item bulk environment (18 modules)
    \item graphic environment (6 modules)
    \item (machine environment (3 modules))
    \end{itemize}

\item Quest language processor: interactive top-level, compiler front-end,
compiler back-end generating portable byte code, run-time debugger (19K
lines Quest code);

\item Portable persistent abstract machine (10K lines Modula-3 code);

\item Persistent object store (C library provided by the
University of St.~Andrews).
\end{itemize}

\begin{center} \leavevmode
\epsfxsize=\figwidth
\epsffile{Tycoon-Architecture.ps}
\ \\ \centerline{Current Tycoon system architecture}
\end{center}




\newpage
\section{Strongly-Typed, Generic User Interface Construction}

\begin{description}
\item[Task] {\em Generic} tool support for the construction of typical database
applications:
\begin{itemize}
\item Statically verified application consistency \\
(database schema, program, user interface)
\item Orthogonality
\item ``Universality''
\item State-of-the-art functionality
\item Extensibility
\end{itemize}

\item[Approach] A core graphical environment tailored to typical
database application requirements consisting of four layers:
\begin{itemize}
\item Asynchronous communication with (remote) display server (module 
\k{news});

\item Access to classes, methods and display objects implementing the
Sun NeWS {\em Open Look} user interface (module \k{openLook});

\item Internal, abstract representation of typed Tycoon language objects
with their associated display attributes (module \k{editorRep});

\item External interface for the type-safe creation, display and manipulation 
of hierachically structured editor objects (module \k{editor}).
\end{itemize}


\item[Test Data] Data imported from the DBPL system demo.

\end{description}


\begin{center} \leavevmode
\epsfxsize=\figwidth
\epsffile{Editor-Architecture.ps}
\ \\ \centerline{Framework for the interactive access to database variables}
\end{center}

\newpage
\subsection{Display example data}

After importing a pre-linked application module into the interactive top level
environment and invoking it,
\begin{verbatim}
   import moduleDemo :Main;
   moduleDemo.go();
\end{verbatim}

two new windows appear on the workstation screen that allow the user to
browse through a database of module and identifier
descriptions.\footnote{The test database was initialized with data
imported from the DBPL system demonstration.} Text fields, numeric
fields, checkboxes, buttons, drop-down menues and scrollbars provide
type-specific display representations for hierarchically nested
database objects.

\begin{center} \leavevmode
\epsfxsize=\figwidth
\epsffile{Dump-Mods-Ids.ps}
\ \\ \centerline{Browsing in an {\em Open Look} environment}
\end{center}

Issues:
\begin{itemize}
\item Separation between re-usable generic functionality and 
application-specific functionality
\item Support for complex objects
\item Support for sets and lists
\item Need for type abstraction
\item Identity-based vs.~value-based object identification
\end{itemize}

\newpage
\subsection{Show database schema}

\begin{center} \leavevmode
%\epsfxsize=\figwidth
\epsffile{Demo-Architecture.ps}
\ \\ \centerline{Modules of the demo application}
\end{center}

The interface \k{ModuleDatabase} exports global database types, views on
the database variables and primitive update transactions.
\begin{center}
\begin{verbatim}
interface ModuleDatabase
import
  iter :Iter
  optional :Optional
export
  Def IdKind = Option
    dbplModule, procedure, type, constant, variable, field, predicate 
  end

  Def TypeKind = Option
    base, set, pointer, relation, procedure,
    enumeration, subrange, dbplArray, record, predicate, nil
  end

  Def ModuleKind = Option
    definition, implementation, main, standard
  end

  Def DeclarationKind = Option
    inModule, inRecord, inEnumeration 
  end
\end{verbatim}
\centerline{The module database interface in file \k{ModuleDatabase.spec} (1)}
\newpage
\begin{verbatim}
(* --- Entity types: *)

  Def Module = Tuple
    id :Int
    var filename :String
    var kind :ModuleKind       
  end
  Def Modules = Iter_T(Module)

  Def Occurence = Tuple
    var inModule :Module         
    var inLine :Int    
  end
  Def Occurences = Iter_T(Occurence)

  Def Rec Identifier = Tuple
    id :Int                 (* unique key issued by the DBPL compiler *)
    var name :String        
    var anonymous :Bool         
    var kind :IdKind   
    var type :TypeKind      (* the type of a type identifier          *)
    var declModule :Module  (* compilation unit that exports the Id.  *)
    var declKind :DeclarationKind
    var declLine :Int       (* declaration line number                *)
    var scopeId :optional.T(Identifier) 
                            (* identifier denoting the scope          *)
                            (* "nil" for modules                      *)
    var dependsOn :Identifiers
    var occurences :Occurences
  end
  and Identifiers = Iter_T(Identifier)

(* --- Database views: *)

  modules() :Modules
  identifiers() :Identifiers
  highestIdUsed() :Int
  standardModule :Module
  (* a pre-existing built-in module *)
\end{verbatim}
\ \\ \centerline{The module database interface in file \k{ModuleDatabase.spec} (2)}
\newpage
\begin{verbatim}
(* --- Basic transactions: *)

  error :Exception(String)
  (* raised when an integrity constraint is violated. *)

  setModules(:Modules) :Ok
  setIdentifiers(:Identifiers) :Ok
  addModule(:Module) :Ok
  addIdentifier(:Identifier) :Ok
  removeModule(:Module) :Ok
  removeIdentifier(:Identifier) :Ok
  newId() :Int
  (* issue a new, unique identifier *)
end;
\end{verbatim}
\end{center}
\ \\ \centerline{The module database interface in file \k{ModuleDatabase.spec} (3)}

\newpage
\subsection{Update, insert and delete example data}

The user can use menues, buttons as well as cut and paste techniques to
directly modify the database state. The particular implementation of the
module database  guarantees the uniqueness of the attribute \k{Id} in
the set of modules and identifers, enforces domain constraints, rejects
illegal ``null values'' and checks simple inter-attribute constraints.

\begin{center} \leavevmode
\epsfysize=10cm
\epsffile{Dump-Constraint.ps}
\ \\ \centerline{Detecting a constraint violation (``Name missing'')}
\end{center}

Issues:
\begin{itemize}
\item Support for ``early'' database constraint validation:
\begin{itemize}
\item attribute or domain constraints
\item collection constraints (e.g. key constraints)
\item subset constraints
\end{itemize}
\item ``Null values''
\end{itemize}


\newpage
\subsection{Instantiate a generic display routine}

By executing the following program fragment, a simple string editor
(variable \k{stringEd}) is created that is bound by its \k{put} and
\k{get} routines to the global mutable variable \k{state.x}. As soon as the
displayed editor window is closed by the user, the value of the variable
\k{state.x} is returned.

\begin{center}
\begin{verbatim}
import 
  editor :Editor 
  news :News;

let state = tuple let var x = ``Your Name'' end

let stringEd = editor.newString(
  let get = fun() state.x   
  let put = fun(new :String) state.x:= new);

begin
  editor.display(stringEd ``Hello'')
  while editor.visible(stringEd) do
    news.waitEvent()
  end
  state.x
end;
\end{verbatim}
\end{center}
\ \\ \centerline{Creation of a simple string editor}

\begin{center} \leavevmode
%\epsfxsize=\figwidth
\epsffile{Dump-StringEd.ps}
\ \\ \centerline{The string editor window}
\end{center}

\begin{itemize}
\item Heavy use of pre-existing library functionality
\item Programming with higher-order functions
\end{itemize}

\newpage
\subsection{Extend the example display program}

Once a simple editor is created, it can be used as a component in a more
complex editor. The following program fragment embeds the string editor
together with two other editors imported from the module
\k{moduleDisplay} and a simple string value into a record editor.
\begin{verbatim}
import 
  moduleDisplay :ModuleDisplay
  moduleDatabase: ModuleDatabase;

let moduleEd = editor.newRecord of
  tuple "Your Name"   stringEd 
  end
  tuple "Modules"     moduleDisplay.newModulesEditor(
                        moduleDatabase.modules
                        moduleDatabase.setModules) 
  end
  tuple "Identifiers" moduleDisplay.newIdentifiersEditor(
                        moduleDatabase.identifiers
                        moduleDatabase.setIdentifiers) 
  end
  tuple "Highest Id"  editor.newStringVal(
                        fun() fmt.int(moduleDatabase.highestIdUsed())) 
  end
end;
\end{verbatim}

\begin{center} \leavevmode
\epsfxsize=\figwidth
\epsffile{Dump-Browser.ps}
\ \\ \centerline{The record editor window}
\end{center}

\newpage
\subsection{Introduce integrity checking code}

The definition of an editor for the \k{line} attribute of an identifier
exemplifies how to check typical database integrity constraints as early
as possible (i.e. at data-entry-time) by attaching them to the \k{put()}
routine of an editor:
\begin{verbatim}
      tuple
        "Line" editor.newInt(
             fun() i.x.declLine
             fun(new :Int)
               if new < 0 then
                 raise editor.illegal with "Line must be positive" end
               else
                 i.x.declLine:= new
               end)
      end
\end{verbatim}
Dependencies between multiple attributes of a record can also be
enforced by attaching them to the \k{put} routine of the last attribute.

\ \\ \ \\ \begin{itemize}
\item Exception handling
\item Exception typing
\item Systematic approach to IC attachment
\end{itemize}


%\newpage
%\section{Add-On Iteration Abstraction}

\newpage
\section{Built-In Persistence Management}

\subsection{Checkpointing the database}

The lowest layer of the storage manager makes all updates to the store
recoverable by transparently saving before-images of updated pages in
the persistent store. The operation
\begin{verbatim}
   store.stabilise();
\end{verbatim}
exported by the module \k{store} that is part of the standard Tycoon
environment atomically checkpoints the store. Thereby, all modifications
to the store are committed and become persistent.

In the demo, this checkpointing is illustrated by undoing modifications
performed via the interactive interface.


\subsection{Garbage collection}

The persistence model of PQuest is based on transitive reachability from
the top-level interactive environment. There is no (unsafe) explicit
object deletion mechanism. Garbage collection is either invoked
explicitely,
\begin{verbatim}
   store.garbageCollect();
\end{verbatim}
or implicitely, as soon as the system runs out of (persistent) memory.
Since the demo store has a fixed size of 5.7MB, the following program
fragment triggers a garbage collection:
\begin{verbatim}
   let createGarbage(count :Int) :Ok =
     (* create count arrays with 10000 integer elements *)
     for i= 1 upto count do
       let dummy = arrayOp.new(10000 0)
     end;

createGarbage(100);  (* allocate 4.000.000 bytes *)
createGarbage(100);  (* allocate 4.000.000 bytes *)
\end{verbatim}

\newpage
\subsection{Program suspension}

The P-Quest implementation provides a mechanism to suspend the execution
of a program at arbitrary points in time and to return to the calling
Unix process.
\begin{verbatim}
   store.halt();
\end{verbatim}
The command \k{PQuestRecover} restarts the P-Quest program with its
original state (at the next statement following the \k{halt} function
call). 

The following program fragment makes use of this suspension mechanism:
\begin{verbatim}
let rec stopAfter(depth :Int) :Ok =
  if depth is 0 then 
    store.halt()
  else
    print.string("Entering, depth = " <> fmt.int(depth) <> "\n")
    stopAfter(depth-1)
    print.string("Leaving, depth = " <> fmt.int(depth) <> "\n")
  end;
\end{verbatim}
\begin{center}
\begin{verbatim}
stopAfter(5);
..let stopAfter : All(depth:Int) Ok = <fun stopAfter()>
Entering, depth = 5
Entering, depth = 4
Entering, depth = 3
Entering, depth = 2
Entering, depth = 1
Exception: 
florian@dbis1> PQuestRecover
                                      ___   
     _____    _____ __ __ _____ _____|   |_ 
    |     |__|     |  |  |  _  |   __|    _|
    |  |  |__|  |  |     |   __|__   |   |  
    |   __|  |__   |_____|_____|_____|___|  
    |__|        |__|                        

    Hamburg University
    Tycoon Language Environment Release 1.1
    
    Restart from last checkpoint ...
    
Leaving, depth = 1
Leaving, depth = 2
Leaving, depth = 3
Leaving, depth = 4
Leaving, depth = 5
\end{verbatim}
\end{center}
\centerline{Resuming a suspended program execution}
 
\end{document}
