\documentclass[10pt]{article}

%% ODER: format ==         = "\mathrel{==}"
%% ODER: format /=         = "\neq "
\makeatletter

\usepackage{amstext}
\usepackage{amssymb}
\usepackage{stmaryrd}
\DeclareFontFamily{OT1}{cmtex}{}
\DeclareFontShape{OT1}{cmtex}{m}{n}
  {<5><6><7><8>cmtex8
   <9>cmtex9
   <10><10.95><12><14.4><17.28><20.74><24.88>cmtex10}{}
\DeclareFontShape{OT1}{cmtex}{m}{it}
  {<-> ssub * cmtt/m/it}{}
\newcommand{\texfamily}{\fontfamily{cmtex}\selectfont}
\DeclareFontShape{OT1}{cmtt}{bx}{n}
  {<5><6><7><8>cmtt8
   <9>cmbtt9
   <10><10.95><12><14.4><17.28><20.74><24.88>cmbtt10}{}
\DeclareFontShape{OT1}{cmtex}{bx}{n}
  {<-> ssub * cmtt/bx/n}{}
\newcommand{\tex}[1]{\text{\texfamily#1}}	% NEU

\newcommand{\Sp}{\hskip.33334em\relax}

\newlength{\lwidth}\setlength{\lwidth}{4.5cm}
\newlength{\cwidth}\setlength{\cwidth}{8mm} % 3mm

\newcommand{\Conid}[1]{\mathit{#1}}
\newcommand{\Varid}[1]{\mathit{#1}}
\newcommand{\anonymous}{\kern0.06em \vbox{\hrule\@width.5em}}
\newcommand{\plus}{\mathbin{+\!\!\!+}}
\newcommand{\bind}{\mathbin{>\!\!\!>\mkern-6.7mu=}}
\newcommand{\sequ}{\mathbin{>\!\!\!>}}
\renewcommand{\leq}{\leqslant}
\renewcommand{\geq}{\geqslant}
\newcommand{\NB}{\textbf{NB}}
\newcommand{\Todo}[1]{$\langle$\textbf{To do:}~#1$\rangle$}

\makeatother

%\usepackage{haskell}

\usepackage{proof}
\usepackage{fullpage}

\bibliographystyle{plain}

\parskip=\medskipamount
\parindent=0pt

\newcommand{\isa}{\ensuremath{\; {:}{:}{=} \;}}
\newcommand{\ora}{\ensuremath{\;\mid\;}}
\newcommand{\IF}{\ensuremath{\mathtt{ if \;}}}
\newcommand{\THEN}{\ensuremath{\mathtt{\; then \;}}}
\newcommand{\ELSE}{\ensuremath{\mathtt{\; else \;}}}
\newcommand{\TRUE}{\ensuremath{\mathtt{ true \;}}}
\newcommand{\FALSE}{\ensuremath{\mathtt{\; false \;}}}
\newcommand{\BOOL}{\ensuremath{\mathtt{\; Bool \;}}}

\title{EECS 762 - Project 3 Solution}
\author{Perry Alexander \\
  The University of Kansas EECS Department\\
  \texttt{alex@ittc.ku.edu}}

\begin{document}

\maketitle

\section{Introduction}

The objective of Project 3 is to write an interpreter for simply typed
lambda calculus with subtyping and records ($\lambda_{<:}$)
expressions as defined in \emph{Types and Programming
Languages}~\cite{Pie02a}, Chapters 15 and 16.  In addition, you were
to include booleans and the $\IF$ special form.  The definition of the
abstract syntax provides the following three forms for $\lambda_{<:}$
terms, values and types in:

\begin{eqnarray*}
  t & \isa & x \ora \lambda x:T.t \ora t\; t \ora \\
    &      & t.l \ora \{l_i=t_i^{i\in 1..n}\} \\
  v & \isa & \lambda x:T.t \ora \TRUE \ora \FALSE \ora \{l_i=v_i^{i\in 1..n}\}\\
  T & \isa & \BOOL \ora T \rightarrow T \ora \{l_i:T_i^{i\in 1..n}\} \ora Top
\end{eqnarray*}

The definition for call-by-value evaluation provides the following
evaluation rules that will define the evaluation function:

\[\vcenter{\infer[\textsc{E-App1}]
	{t_1 t_2 \longrightarrow t_1^{'} t_2}
	{t_1\longrightarrow t_1^{'}}}\]

\[\vcenter{\infer[\textsc{E-App2}]
	{t_1 t_2 \longrightarrow t_1 t_2^{'}}
	{t_2\longrightarrow t_2^{'}}}\]

\[\vcenter{\infer[\textsc{E-AppAbs}]
	{(\lambda x:T.t_{12})v_2 \longrightarrow [x\rightarrow v_2]t_{12}}
	{}}\]

\[\vcenter{\infer[\textsc{E-IfTrue}]
	{t_2}
	{\IF \TRUE \THEN t_2 \ELSE t_3}}\]

\[\vcenter{\infer[\textsc{E-IfFalse}]
	{t_3}
	{\IF \FALSE \THEN t_2 \ELSE t_3}}\]

\[\vcenter{\infer[\textsc{E-If}]
  {\IF t_1 \THEN t_2 \ELSE t_3 \rightarrow \IF t_1^{'} \THEN t_2 \ELSE t_3}
  {t\rightarrow t_1^{'}}}\]

\[\vcenter{\infer[\textsc{E-ProjRcd}]
  {\{l_i=v_i^{i\in 1..n}\}.l_j \longrightarrow v_j}
  {}}\]

\[\vcenter{\infer[\textsc{E-Proj}]
  {t_1.l \longrightarrow t_1^{'}.l}
  {t_1 \longrightarrow t_1^{'}}}\]

Finally, the definition provides the following typing rules that will
define the type inference function:

\[\vcenter{\infer[\textsc{T-Var}]{\Gamma\vdash x:T}{x:T\in\Gamma}}\]

\[\vcenter{\infer[\textsc{T-Abs}]
  {\Gamma\vdash\lambda x:T_1.t_2 : T_1\rightarrow T_2}
  {\Gamma,x:T_1\vdash t_2 : T_2}}
\]

\[\vcenter{\infer[\textsc{T-App}]
  {\Gamma\vdash t_1\; t_2 : T_{12}}
  {\Gamma\vdash t_1 : T_{11}\rightarrow T_{12} & \Gamma\vdash t_2:T_{11}}}
\]

\[\vcenter{\infer[\textsc{T-If}]
  {\Gamma\vdash \IF t_1 \THEN t_2 \ELSE t_3 : T}
  {\Gamma\vdash t_1 : \BOOL & \Gamma\vdash t_2 : T & \Gamma\vdash t_3 : T}}
\]

\[\vcenter{\infer{\TRUE:\BOOL}{}}\]

\[\vcenter{\infer{\FALSE:\BOOL}{}}\]

Our objective is to: (i) define a data structure for representing
$\lambda_{<:}$ terms embodying the abstract syntax; (ii) a type
derivation function for $\lambda_{<:}$ terms embodying the type
rules; and (iii) an evaluation function for $\lambda_{<:}$
terms embodying the evaluation rules.

\section{SubtypedLambdaMonad Module}

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\mathbf{module}\;\Conid{SubtypedLambdaMonad}\;(\Conid{Term}\;(\mathinner{\ldotp\ldotp}))}$\\
${\hskip2.00em\relax\mathbf{where}}$
\end{tabbing}
The \ensuremath{\Conid{SubtypedLambdaMonad}} module provides the basic definitions for
manipulating simply typed lambda calculus expressions with subtyping
and records added.  As indicated by the module name, a monad is used
to implement the evaluation and type checking processes.  The data
type representing terms and types is first defined, followed by the
type checking function, subtyping function, and the evaluation
function.

\subsection{Data Types}

An abstract type \ensuremath{\Varid{T}}, is defined to represent the two possible
types in $\lambda_{<:}$.  A constant represents the Boolean
type while a pair of types represents the $\rightarrow$ type former
application.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\mathbf{import}\;\Conid{\Conid{Data}.List}}$\\
${\mathbf{data}\;\Conid{Retval}\;\Varid{a}\mathrel{=}}$\\
${\hskip2.00em\relax\Conid{Value}\;\Varid{a}\mid \Conid{Error}\;\Conid{String}}$\\
${\hskip2.00em\relax\mathbf{deriving}\;(\Conid{Eq},\Conid{Show})}$\\
${}$\\
${\mathbf{instance}\;\Conid{Monad}\;\Conid{Retval}\;\mathbf{where}}$\\
${\hskip2.00em\relax\Conid{Error}\;\Varid{s}\bind \Varid{k}\mathrel{=}\Conid{Error}\;\Varid{s}}$\\
${\hskip2.00em\relax\Conid{Value}\;\Varid{a}\bind \Varid{k}\mathrel{=}\Varid{k}\;\Varid{a}}$\\
${\hskip2.00em\relax\Varid{return}\mathrel{=}\Conid{Value}}$\\
${\hskip2.00em\relax\Varid{fail}\mathrel{=}\Conid{Error}}$\\
${}$\\
${\mathbf{data}\;\Varid{T}\mathrel{=}}$\\
${\hskip2.00em\relax\Conid{TyBool}\mid }$\\
${\hskip2.00em\relax\Conid{TyTop}\mid }$\\
${\hskip2.00em\relax\Conid{TyArr}\;\Varid{T}\;\Varid{T}\mid }$\\
${\hskip2.00em\relax\Conid{TyTpl}\;[\mskip1.5mu \Varid{T}\mskip1.5mu]\mid }$\\
${\hskip2.00em\relax\Conid{TyRec}\;[\mskip1.5mu (\Conid{String},\Varid{T})\mskip1.5mu]}$\\
${\hskip2.00em\relax\mathbf{deriving}\;(\Conid{Eq},\Conid{Show})}$\\
${}$\\
${\Varid{dom}\mathbin{::}\Varid{T}\to \Conid{Retval}\;\Varid{T}}$\\
${\Varid{dom}\;\Varid{t}\mathrel{=}}$\\
${\phantom{\Varid{dom}\;\mbox{}}\mathbf{case}\;\Varid{t}\;\mathbf{of}}$\\
${\phantom{\Varid{dom}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyArr}\;\Varid{d}\;\anonymous \to \Varid{return}\;\Varid{d}}$\\
${\phantom{\Varid{dom}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyBool}\to \Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~find~domain~of~a~boolean~type\char34}}$\\
${\phantom{\Varid{dom}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyRec}\;\anonymous \to \Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~find~domain~of~a~record~type~\char34}}$\\
${\phantom{\Varid{dom}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyTpl}\;\anonymous \to \Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~find~the~domain~of~a~tuple~tye\char34}}$\\
${\phantom{\Varid{dom}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyTop}\to \Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~find~the~domain~of~top\char34}}$\\
${}$\\
${\Varid{ran}\mathbin{::}\Varid{T}\to \Conid{Retval}\;\Varid{T}}$\\
${\Varid{ran}\;\Varid{t}\mathrel{=}}$\\
${\phantom{\Varid{ran}\;\mbox{}}\mathbf{case}\;\Varid{t}\;\mathbf{of}}$\\
${\phantom{\Varid{ran}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyArr}\;\anonymous \;\Varid{r}\to \Varid{return}\;\Varid{r}}$\\
${\phantom{\Varid{ran}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyBool}\to \Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~find~range~of~a~boolean~type\char34}}$\\
${\phantom{\Varid{ran}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyRec}\;\anonymous \to \Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~find~range~of~a~record~type\char34}}$\\
${\phantom{\Varid{ran}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyTpl}\;\anonymous \to \Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~find~the~range~of~a~tuple~tye\char34}}$\\
${\phantom{\Varid{ran}\;\mbox{}}\phantom{\mathbf{case}\;\Varid{t}\;\mbox{}}\Conid{TyTop}\to \Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~find~range~of~top\char34}}$\\
${}$\\
${\Varid{isArr}\mathbin{::}\Varid{T}\to \Conid{Bool}}$\\
${\Varid{isArr}\;(\Conid{TyArr}\;\anonymous \;\anonymous )\mathrel{=}\Conid{True}}$\\
${\Varid{isArr}\;\anonymous \mathrel{=}\Conid{False}}$\\
${}$\\
${\Varid{isRec}\mathbin{::}\Varid{T}\to \Conid{Bool}}$\\
${\Varid{isRec}\;(\Conid{TyRec}\;\anonymous )\mathrel{=}\Conid{True}}$\\
${\Varid{isRec}\;\anonymous \mathrel{=}\Conid{False}}$\\
${}$\\
${\Varid{isTpl}\mathbin{::}\Varid{T}\to \Conid{Bool}}$\\
${\Varid{isTpl}\;(\Conid{TyTpl}\;\anonymous )\mathrel{=}\Conid{True}}$\\
${\Varid{isTpl}\;\anonymous \mathrel{=}\Conid{False}}$
\end{tabbing}
A constructed type, \ensuremath{\Conid{Term}}, is defined to represent the abstract
syntax for $\lambda_{<:}$ terms.  Note that this definition is
identical to that used in $\lambda_{<:}$ except \ensuremath{\Conid{Lambda}}
includes a type annotation, the \ensuremath{\Conid{If}} construct is defined, and boolean
costants have been added.  The implementation of the \ensuremath{\Conid{Term}} type is a
Maybe type that either represents a legal term or a form that cannot
be evaluated.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\mathbf{data}\;\Conid{Term}\mathrel{=}}$\\
${\hskip2.00em\relax\Conid{TmTrue}\mid \Conid{TmFalse}\mid }$\\
${\hskip2.00em\relax\Conid{If}\;\Conid{Term}\;\Conid{Term}\;\Conid{Term}\mid }$\\
${\hskip2.00em\relax\Conid{Var}\;\Conid{Int}\mid }$\\
${\hskip2.00em\relax\Conid{Lambda}\;\Varid{T}\;\Conid{Term}\mid }$\\
${\hskip2.00em\relax\Conid{AppV}\;\Conid{Term}\;\Conid{Term}\mid }$\\
${\hskip2.00em\relax\Conid{AppN}\;\Conid{Term}\;\Conid{Term}\mid }$\\
${\hskip2.00em\relax\Conid{Rec}\;[\mskip1.5mu (\Conid{String},\Conid{Term})\mskip1.5mu]\mid }$\\
${\hskip2.00em\relax\Conid{Tpl}\;[\mskip1.5mu \Conid{Term}\mskip1.5mu]\mid }$\\
${\hskip2.00em\relax\Conid{ProjRcd}\;\Conid{Term}\;\Conid{String}\mid }$\\
${\hskip2.00em\relax\Conid{ProjTpl}\;\Conid{Term}\;\Conid{Int}}$\\
${\hskip2.00em\relax\mathbf{deriving}\;(\Conid{Eq},\Conid{Show})}$
\end{tabbing}
The \ensuremath{\Varid{value}} function defines a predicate that specifies $\lambda_{<:}$
terms that are values.  By definition, \ensuremath{\Conid{TmTrue}}, \ensuremath{\Conid{TmFalse}}, \ensuremath{\Conid{Lambda}}
forms, \ensuremath{\Conid{Rec}} and \ensuremath{\Conid{Tpl}} are constructors for values.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{value}\mathbin{::}\Conid{Term}\to \Conid{Bool}}$\\
${\Varid{value}\;\Conid{TmTrue}\mathrel{=}\Conid{True}}$\\
${\Varid{value}\;\Conid{TmFalse}\mathrel{=}\Conid{True}}$\\
${\Varid{value}\;(\Conid{Lambda}\;\anonymous \;\anonymous )\mathrel{=}\Conid{True}}$\\
${\Varid{value}\;(\Conid{Rec}\;\anonymous )\mathrel{=}\Conid{True}}$\\
${\Varid{value}\;(\Conid{Tpl}\;\anonymous )\mathrel{=}\Conid{True}}$\\
${\Varid{value}\;\anonymous \mathrel{=}\Conid{False}}$
\end{tabbing}
The \ensuremath{\Conid{TmTrue}} and \ensuremath{\Conid{TmFalse}} values represent the Boolean
values true and false respectively.  The \ensuremath{\Conid{If}} constructor
defines a classical if-expression.  The \ensuremath{\Conid{Var}} construtor
identifies the index for a variable and corresponds with the $x$ form
in the abstract syntax.  The \ensuremath{\Conid{Lambda}} constructor defines an
abstraction by specifying a term and corresponds with the $\lambda
x:T.t$ form in the abstract syntax.  The \ensuremath{\Conid{AppV}} cosntructor
defines the application of one term to another using call-by-value
semantics.  Similarly, the \ensuremath{\Conid{AppN}} constructor defines the
appliation of one term to another using call-by-name semantics.  Both
forms correspond with the \ensuremath{\Varid{t}\;\Varid{t}} form in the abstract syntax.

The original $\lambda$ language implemented untyped lambda
calculus.  Thus, the maintenance of context information was
unnecessary.  For $\lambda_{<:}$, the types of variables must
be maintained as a part of context for type checking.  The
\ensuremath{\Varid{\Gamma}} type is used to store a list of variable bindings that
will be used to maintain the types associated with variables in
context.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\mathbf{type}\;\Varid{\Gamma}\mathrel{=}[\mskip1.5mu \Varid{T}\mskip1.5mu]}$
\end{tabbing}
To mainipulate the context, the following functions are defined:

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{addBinding}\mathbin{::}\Varid{\Gamma}\to \Varid{T}\to \Varid{\Gamma}}$\\
${\Varid{addBinding}\;\Varid{\gamma}\;\Varid{t}\mathrel{=}\Varid{t}\mathbin{:}\Varid{\gamma}}$\\
${}$\\
${\Varid{getTypeFromContext}\mathbin{::}\Varid{\Gamma}\to \Conid{Int}\to \Conid{Retval}\;\Varid{T}}$\\
${\Varid{getTypeFromContext}\;\Varid{c}\;\Varid{v}\mathrel{=}\mathbf{if}\;((\Varid{length}\;\Varid{c})\geq \Varid{v})}$\\
${\phantom{\Varid{getTypeFromContext}\;\Varid{c}\;\Varid{v}\mathrel{=}\mbox{}}\mathbf{then}\;\Varid{return}\;(\Varid{c}\mathbin{!!}\Varid{v})}$\\
${\phantom{\Varid{getTypeFromContext}\;\Varid{c}\;\Varid{v}\mathrel{=}\mbox{}}\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~Variable~out~of~scope\char34}}$\\
${}$\\
${\Varid{findField}\mathbin{::}\Varid{\Gamma}\to \Conid{String}\to \Varid{T}\to \Conid{Retval}\;\Varid{T}}$\\
${\Varid{findField}\;\Varid{\gamma}\;\Varid{s}_1\;(\Conid{TyRec}\;\Varid{l})\mathrel{=}\Varid{findField2}\;\Varid{\gamma}\;\Varid{s}_1\;\Varid{l}}$\\
${}$\\
${\Varid{findField2}\mathbin{::}\Varid{\Gamma}\to \Conid{String}\to [\mskip1.5mu (\Conid{String},\Varid{T})\mskip1.5mu]\to \Conid{Retval}\;\Varid{T}}$\\
${\Varid{findField2}\;\anonymous \;\anonymous \;[\mskip1.5mu \mskip1.5mu]\mathrel{=}\Varid{fail}\;\text{\tt \char34 Type~Error~-~Field~name~not~found\char34}}$\\
${\Varid{findField2}\;\Varid{\gamma}\;\Varid{s}_1\;((\Varid{s}_2,\Varid{t})\mathbin{:}\Varid{l})\mathrel{=}\mathbf{if}\;\Varid{s}_1\equiv \Varid{s}_2}$\\
${\phantom{\Varid{findField2}\;\Varid{\gamma}\;\Varid{s}_1\;((\Varid{s}_2,\Varid{t})\mathbin{:}\Varid{l})\mathrel{=}\mbox{}}\mathbf{then}\;\Varid{return}\;\Varid{t}}$\\
${\phantom{\Varid{findField2}\;\Varid{\gamma}\;\Varid{s}_1\;((\Varid{s}_2,\Varid{t})\mathbin{:}\Varid{l})\mathrel{=}\mbox{}}\mathbf{else}\;\Varid{findField2}\;\Varid{\gamma}\;\Varid{s}_1\;\Varid{l}}$\\
${}$\\
${\Varid{findProj}\mathbin{::}\Varid{\Gamma}\to \Conid{Int}\to \Varid{T}\to \Conid{Retval}\;\Varid{T}}$\\
${\Varid{findProj}\;\anonymous \;\Varid{i}\;(\Conid{TyTpl}\;\Varid{tl})\mathrel{=}\mathbf{if}\;\Varid{i}\geq \mathrm{0}\mathrel{\wedge}\Varid{i}\mathbin{<}(\Varid{length}\;\Varid{tl})}$\\
${\hskip9.00em\relax\mathbf{then}\;\Varid{return}\;(\Varid{tl}\mathbin{!!}\Varid{i})}$\\
${\hskip9.00em\relax\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~Tuple~index~out~of~range\char34}}$
\end{tabbing}
\subsection{Type Derivation}

Type derivation is achieved using the \ensuremath{\Varid{typeof}_{<:}} function.  Each
case directly corresponds to one of the typing rules defined for
$\lambda_{<:}$.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{typeof}_{<:}\mathbin{::}\Varid{\Gamma}\to \Conid{Term}\to \Conid{Retval}\;\Varid{T}}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;\Conid{TmTrue}\mathrel{=}\Varid{return}\;\Conid{TyBool}}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;\Conid{TmFalse}\mathrel{=}\Varid{return}\;\Conid{TyBool}}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{Rec}\;\Varid{l})\mathrel{=}\mathbf{do}\;\Varid{tl}\leftarrow \Varid{mapM}\;(\lambda (\anonymous ,\Varid{x})\to (\Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{x}))\;\Varid{l}}$\\
${\phantom{\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{Rec}\;\Varid{l})\mathrel{=}\mathbf{do}\;\mbox{}};\Varid{return}\;(\Conid{TyRec}\;(\Varid{zip}\;(\Varid{map}\;(\lambda (\Varid{x},\anonymous )\to \Varid{x})\;\Varid{l})\;\Varid{tl}))}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{Tpl}\;\Varid{l})\mathrel{=}\mathbf{do}\;\Varid{tl}\leftarrow \Varid{mapM}\;(\lambda \Varid{x}\to (\Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{x}))\;\Varid{l}}$\\
${\phantom{\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{Tpl}\;\Varid{l})\mathrel{=}\mathbf{do}\;\mbox{}};\Varid{return}\;(\Conid{TyTpl}\;\Varid{tl})}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{ProjRcd}\;\Varid{t}\;\Varid{s})\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{rectype}\leftarrow \Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\mathbf{if}\;(\Varid{isRec}\;\Varid{rectype})}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\mathbf{then}\;\Varid{findField}\;\Varid{\gamma}\;\Varid{s}\;\Varid{rectype}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~project~a~non-record~type.\char34}}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{ProjTpl}\;\Varid{t}\;\Varid{i})\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{tpltype}\leftarrow \Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\mathbf{if}\;(\Varid{isTpl}\;\Varid{tpltype})}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\mathbf{then}\;\Varid{findProj}\;\Varid{\gamma}\;\Varid{i}\;\Varid{tpltype}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~Cannot~project~a~non-tuple~type.\char34}}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{If}\;\Varid{t}_1\;\Varid{t}_2\;\Varid{t}_3)\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{if}\;(\Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}_1)\equiv \Varid{return}\;\Conid{TyBool}}$\\
${\hskip2.00em\relax\phantom{\mathbf{if}\;\mbox{}}\mathbf{then}\;\mathbf{let}\;\Varid{tt}_1\mathrel{=}\Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}_2;\Varid{tt}_2\mathrel{=}\Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}_3\;\mathbf{in}}$\\
${\hskip2.00em\relax\phantom{\mathbf{if}\;\mbox{}}\phantom{\mathbf{then}\;\mathbf{let}\;\mbox{}}\mathbf{if}\;\Varid{tt}_1\equiv \Varid{tt}_2\;\mathbf{then}\;\Varid{tt}_2}$\\
${\hskip2.00em\relax\phantom{\mathbf{if}\;\mbox{}}\phantom{\mathbf{then}\;\mathbf{let}\;\mbox{}}\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~If~branches~of~different~types\char34}}$\\
${\hskip2.00em\relax\phantom{\mathbf{if}\;\mbox{}}\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~If~conditional~not~boolean\char34}}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{Var}\;\Varid{x})\mathrel{=}(\Varid{getTypeFromContext}\;\Varid{\gamma}\;\Varid{x})}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{AppV}\;\Varid{t}_1\;\Varid{t}_2)\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{tt}_1\leftarrow \Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}_1}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{tt}_2\leftarrow \Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}_2}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{dtt}_1\leftarrow \Varid{dom}\;\Varid{tt}_1}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\mathbf{if}\;\Varid{isArr}\;\Varid{tt}_1\;\mathbf{then}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\mathbf{if}\;(\Varid{subtype}\;\Varid{tt}_2\;\Varid{dtt}_1)\;\mathbf{then}\;\Varid{return}\;\Varid{tt}_2}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\phantom{\mathbf{if}\;\mbox{}}\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~Argument~type~is~not~a~subtype~of~domain\char34}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\hskip1.50em\relax\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~Term~is~not~an~abstraction\char34}}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{AppN}\;\Varid{t}_1\;\Varid{t}_2)\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{tt}_1\leftarrow \Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}_1}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{tt}_2\leftarrow \Varid{typeof}_{<:}\;\Varid{\gamma}\;\Varid{t}_2}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{dtt}_1\leftarrow \Varid{dom}\;\Varid{tt}_1}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\mathbf{if}\;\Varid{isArr}\;\Varid{tt}_1\;\mathbf{then}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\mathbf{if}\;(\Varid{subtype}\;\Varid{tt}_2\;\Varid{dtt}_1)\;\mathbf{then}\;\Varid{return}\;\Varid{tt}_2}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\phantom{\mathbf{if}\;\mbox{}}\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~Argument~type~is~not~a~subtype~of~domain\char34}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\hskip1.50em\relax\mathbf{else}\;\Varid{fail}\;\text{\tt \char34 Type~Error~-~Term~is~not~an~abstraction\char34}}$\\
${\Varid{typeof}_{<:}\;\Varid{\gamma}\;(\Conid{Lambda}\;\Varid{ty}\;\Varid{t})\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{tt}\leftarrow \Varid{typeof}_{<:}\;(\Varid{addBinding}\;\Varid{\gamma}\;\Varid{ty})\;\Varid{t}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\Varid{tt}\leftarrow \mbox{}};\Varid{return}\;(\Conid{TyArr}\;\Varid{ty}\;\Varid{tt})}$
\end{tabbing}
The \ensuremath{\Varid{subtype}} function defines when one type is a subtype of another.
\ensuremath{\Conid{TyBool}} is only a subtype of itself.  A function type, \ensuremath{\Conid{TyArr}\;\Varid{ty11}\;\Varid{ty12}} is a subtype of \ensuremath{\Conid{TyArr}\;\Varid{ty21}\;\Varid{ty22}} if \ensuremath{\Varid{subtype}\;\Varid{ty21}\;\Varid{ty11}} and
\ensuremath{\Varid{subtype}\;\Varid{ty12}\;\Varid{ty22}}.  A record, \ensuremath{\Conid{TyRec}} is a subtype of another if
it's list of label, type pairs intersects with the other's label, type
pairs.  \ensuremath{\Conid{TyTop}} is by definition a supertype of everything while all
other subtyping attempts are illegal.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{subtype}\mathbin{::}\Varid{T}\to \Varid{T}\to \Conid{Bool}}$\\
${\Varid{subtype}\;\Conid{TyBool}\;\Conid{TyBool}\mathrel{=}\Conid{True}}$\\
${\Varid{subtype}\;(\Conid{TyArr}\;\Varid{ty11}\;\Varid{ty12})\;(\Conid{TyArr}\;\Varid{ty21}\;\Varid{ty22})\mathrel{=}}$\\
${\hskip2.00em\relax\Varid{subtype}\;\Varid{ty21}\;\Varid{ty11}\mathrel{\wedge}\Varid{subtype}\;\Varid{ty12}\;\Varid{ty22}}$\\
${\Varid{subtype}\;(\Conid{TyRec}\;\Varid{l1})\;(\Conid{TyRec}\;\Varid{l2})\mathrel{=}(\Varid{intersect}\;\Varid{l1}\;\Varid{l2})\equiv \Varid{l1}}$\\
${\Varid{subtype}\;(\Conid{TyTpl}\;\Varid{l1})\;(\Conid{TyTpl}\;\Varid{l2})\mathrel{=}(\Varid{isPrefixOf}\;\Varid{l1}\;\Varid{l2})}$\\
${\Varid{subtype}\;\anonymous \;\Conid{TyTop}\mathrel{=}\Conid{True}}$\\
${\Varid{subtype}\;\anonymous \;\anonymous \mathrel{=}\Conid{False}}$
\end{tabbing}
\subsection{Shifting and Substituting}

Our implementation uses de Brujin indices as a basis for
representation and evaluation.  Thus, definitions of \ensuremath{\Varid{shift}}
and \ensuremath{\Varid{subst}} are required to implement elements of the evalation
function.  These functions are largely the same as those used in
Project 1 except they must deal with type information.

The \ensuremath{\Varid{shift}} definition provides a case for shifting over each
valid $\lambda$ form as defined in the \ensuremath{\Conid{Term}} data type.  This
definition follows directly from the standard definition of shift from
TPL Chapter 8:

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{shift}\mathbin{::}\Conid{Term}\to \Conid{Int}\to \Conid{Int}\to \Conid{Term}}$\\
${\Varid{shift}\;\Conid{TmTrue}\;\Varid{c}\;\Varid{d}\mathrel{=}\Conid{TmTrue}}$\\
${\Varid{shift}\;\Conid{TmFalse}\;\Varid{c}\;\Varid{d}\mathrel{=}\Conid{TmFalse}}$\\
${\Varid{shift}\;(\Conid{Rec}\;\Varid{l})\;\Varid{c}\;\Varid{d}\mathrel{=}}$\\
${\hskip2.00em\relax(\Conid{Rec}\;(\Varid{map}\;(\lambda (\Varid{str},\Varid{t})\to (\Varid{str},(\Varid{shift}\;\Varid{t}\;\Varid{c}\;\Varid{d})))\;\Varid{l}))}$\\
${\Varid{shift}\;(\Conid{Tpl}\;\Varid{l})\;\Varid{c}\;\Varid{d}\mathrel{=}}$\\
${\hskip2.00em\relax(\Conid{Tpl}\;(\Varid{map}\;(\lambda \Varid{t}\to (\Varid{shift}\;\Varid{t}\;\Varid{c}\;\Varid{d}))\;\Varid{l}))}$\\
${\Varid{shift}\;(\Conid{ProjRcd}\;\Varid{r}\;\Varid{s})\;\Varid{c}\;\Varid{d}\mathrel{=}(\Conid{ProjRcd}\;(\Varid{shift}\;\Varid{r}\;\Varid{c}\;\Varid{d})\;\Varid{s})}$\\
${\Varid{shift}\;(\Conid{ProjTpl}\;\Varid{t}\;\Varid{i})\;\Varid{c}\;\Varid{d}\mathrel{=}(\Conid{ProjTpl}\;(\Varid{shift}\;\Varid{t}\;\Varid{c}\;\Varid{d})\;\Varid{i})}$\\
${\Varid{shift}\;(\Conid{Var}\;\Varid{x})\;\Varid{c}\;\Varid{d}\mathrel{=}\mathbf{if}\;\Varid{x}\mathbin{<}\Varid{c}\;\mathbf{then}\;(\Conid{Var}\;\Varid{x})\;\mathbf{else}\;(\Conid{Var}\;(\Varid{x}\mathbin{+}\Varid{d}))}$\\
${\Varid{shift}\;(\Conid{Lambda}\;\Varid{ty}\;\Varid{t})\;\Varid{c}\;\Varid{d}\mathrel{=}(\Conid{Lambda}\;\Varid{ty}\;(\Varid{shift}\;\Varid{t}\;(\Varid{c}\mathbin{+}\mathrm{1})\;\Varid{d}))}$\\
${\Varid{shift}\;(\Conid{AppV}\;\Varid{t}_1\;\Varid{t}_2)\;\Varid{c}\;\Varid{d}\mathrel{=}(\Conid{AppV}\;(\Varid{shift}\;\Varid{t}_1\;\Varid{c}\;\Varid{d})\;(\Varid{shift}\;\Varid{t}_2\;\Varid{c}\;\Varid{d}))}$\\
${\Varid{shift}\;(\Conid{AppN}\;\Varid{t}_1\;\Varid{t}_2)\;\Varid{c}\;\Varid{d}\mathrel{=}(\Conid{AppN}\;(\Varid{shift}\;\Varid{t}_1\;\Varid{c}\;\Varid{d})\;(\Varid{shift}\;\Varid{t}_2\;\Varid{c}\;\Varid{d}))}$
\end{tabbing}
\ensuremath{\Conid{Lambda}}, \ensuremath{\Conid{AppV}}, and \ensuremath{\Conid{AppN}} terms are shifted by
shifting their identified terms.  Shifting a \ensuremath{\Conid{Var}} term
requires application of the definition from Chapter 8.  Specifically,
the index for a variable is shifted by \ensuremath{\Varid{d}} if its index is
greater than \ensuremath{\Varid{c}}.

The \ensuremath{\Varid{subst}} definition again provides a case for substitution
over each value $\lambda$ as defined in the \ensuremath{\Conid{Term}} data
type.  This definition follows directly from teh standard definition
of substitution from TPL Chapter 8:

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{subst}\mathbin{::}\Conid{Int}\to \Conid{Term}\to \Conid{Term}\to \Conid{Term}}$\\
${\Varid{subst}\;\Varid{j}\;\Varid{s}\;(\Conid{Var}\;\Varid{x})\mathrel{=}\mathbf{if}\;\Varid{x}\equiv \Varid{j}\;\mathbf{then}\;\Varid{s}\;\mathbf{else}\;(\Conid{Var}\;\Varid{x})}$\\
${\Varid{subst}\;\Varid{j}\;\Varid{s}\;(\Conid{Lambda}\;\Varid{ty}\;\Varid{t})\mathrel{=}(\Conid{Lambda}\;\Varid{ty}\;(\Varid{subst}\;(\Varid{j}\mathbin{+}\mathrm{1})\;(\Varid{shift}\;\Varid{s}\;\mathrm{0}\;\mathrm{1})\;\Varid{t}))}$\\
${\Varid{subst}\;\Varid{j}\;\Varid{s}\;(\Conid{AppV}\;\Varid{t}_1\;\Varid{t}_2)\mathrel{=}(\Conid{AppV}\;(\Varid{subst}\;\Varid{j}\;\Varid{s}\;\Varid{t}_1)\;(\Varid{subst}\;\Varid{j}\;\Varid{s}\;\Varid{t}_2))}$\\
${\Varid{subst}\;\Varid{j}\;\Varid{s}\;(\Conid{AppN}\;\Varid{t}_1\;\Varid{t}_2)\mathrel{=}(\Conid{AppN}\;(\Varid{subst}\;\Varid{j}\;\Varid{s}\;\Varid{t}_1)\;(\Varid{subst}\;\Varid{j}\;\Varid{s}\;\Varid{t}_2))}$\\
${\Varid{subst}\;\anonymous \;\anonymous \;\Conid{TmTrue}\mathrel{=}\Conid{TmTrue}}$\\
${\Varid{subst}\;\anonymous \;\anonymous \;\Conid{TmFalse}\mathrel{=}\Conid{TmFalse}}$\\
${\Varid{subst}\;\Varid{j}\;\Varid{s}\;(\Conid{Rec}\;\Varid{l})\mathrel{=}}$\\
${\hskip2.00em\relax(\Conid{Rec}\;(\Varid{map}\;(\lambda (\Varid{str},\Varid{t})\to (\Varid{str},(\Varid{subst}\;\Varid{j}\;\Varid{s}\;\Varid{t})))\;\Varid{l}))}$\\
${\Varid{subst}\;\Varid{j}\;\Varid{s}\;(\Conid{Tpl}\;\Varid{l})\mathrel{=}}$\\
${\hskip2.00em\relax(\Conid{Tpl}\;(\Varid{map}\;(\lambda \Varid{t}\to (\Varid{subst}\;\Varid{j}\;\Varid{s}\;\Varid{t}))\;\Varid{l}))}$\\
${\Varid{subst}\;\Varid{j}\;\Varid{s}\;(\Conid{ProjRcd}\;\Varid{r}\;\Varid{str})\mathrel{=}}$\\
${\hskip2.00em\relax(\Conid{ProjRcd}\;(\Varid{subst}\;\Varid{j}\;\Varid{s}\;\Varid{r})\;\Varid{str})}$\\
${\Varid{subst}\;\Varid{j}\;\Varid{s}\;(\Conid{ProjTpl}\;\Varid{t}\;\Varid{i})\mathrel{=}}$\\
${\hskip2.00em\relax(\Conid{ProjTpl}\;(\Varid{subst}\;\Varid{j}\;\Varid{s}\;\Varid{t})\;\Varid{i})}$
\end{tabbing}
\subsection{Call By Value Evaluation Function}

The \ensuremath{\Varid{eval}_{<:}} function provides a standard definition of
call-by-value evaluation following from TPL Chapter 5.  The function
definition is split up into cases corresponding to the evaluation
rules.  Note that only \ensuremath{\Conid{AppN}} and \ensuremath{\Conid{AppV}} forms can be
evaluated.  \ensuremath{\Conid{Lambda}} forms are values and \ensuremath{\Conid{Var}} forms
are not closed.  Although passing a context is allowed in this
function, in this project we are concerned only with close terms.
Thus, the context can be safely ignored in all evaluation cases.

The form of the evaluation function is a mapping from \ensuremath{\Varid{\Gamma}} and
\ensuremath{\Conid{Term}} to another \ensuremath{\Conid{Term}}:

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{expr}\mathbin{::}\Conid{Term}\to \Conid{Term}}$\\
${\Varid{expr}\;(\Conid{Lambda}\;\Varid{ty}\;\Varid{t})\mathrel{=}\Varid{t}}$\\
${}$\\
${\Varid{proj}\mathbin{::}[\mskip1.5mu (\Conid{String},\Conid{Term})\mskip1.5mu]\to \Conid{String}\to \Conid{Retval}\;\Conid{Term}}$\\
${\Varid{proj}\;[\mskip1.5mu \mskip1.5mu]\;\anonymous \mathrel{=}\Varid{fail}\;\text{\tt \char34 Evaluation~Error~-~Field~not~defined\char34}}$\\
${\Varid{proj}\;((\Varid{s}_1,\Varid{v})\mathbin{:}\Varid{l})\;\Varid{s}_2\mathrel{=}\mathbf{if}\;\Varid{s}_1\equiv \Varid{s}_2}$\\
${\hskip11.00em\relax\mathbf{then}\;\Varid{return}\;\Varid{v}}$\\
${\hskip11.00em\relax\mathbf{else}\;(\Varid{proj}\;\Varid{l}\;\Varid{s}_2)}$
\end{tabbing}
\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{eval}_{<:}\mathbin{::}\Conid{Term}\to \Conid{Retval}\;\Conid{Term}}$\\
${}$\\
${\Varid{eval}_{<:}\;\Conid{TmTrue}\mathrel{=}\Varid{return}\;\Conid{TmTrue}}$\\
${\Varid{eval}_{<:}\;\Conid{TmFalse}\mathrel{=}\Varid{return}\;\Conid{TmFalse}}$\\
${\Varid{eval}_{<:}\;(\Conid{Rec}\;\Varid{x})\mathrel{=}\Varid{return}\;(\Conid{Rec}\;\Varid{x})}$\\
${\Varid{eval}_{<:}\;(\Conid{Tpl}\;\Varid{x})\mathrel{=}\Varid{return}\;(\Conid{Tpl}\;\Varid{x})}$\\
${}$\\
${\Varid{eval}_{<:}\;(\Conid{AppV}\;\Varid{t}_1\;\Varid{t}_2)\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{nt1}\leftarrow \Varid{eval}_{<:}\;\Varid{t}_1}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{nt2}\leftarrow \Varid{eval}_{<:}\;\Varid{t}_2}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{eval}_{<:}\;(\Varid{shift}\;(\Varid{subst}\;\mathrm{0}\;(\Varid{shift}\;\Varid{nt2}\;\mathrm{0}\;\mathrm{1})\;(\Varid{expr}\;\Varid{nt1}))\;\mathrm{0}\;(\mathbin{-}\mathrm{1}))}$\\
${}$\\
${\Varid{eval}_{<:}\;(\Conid{AppN}\;\Varid{t}_1\;\Varid{t}_2)\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{nt1}\leftarrow \Varid{eval}_{<:}\;\Varid{t}_1}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{eval}_{<:}\;(\Varid{shift}\;(\Varid{subst}\;\mathrm{0}\;(\Varid{shift}\;\Varid{t}_2\;\mathrm{0}\;\mathrm{1})\;(\Varid{expr}\;\Varid{nt1}))\;\mathrm{0}\;(\mathbin{-}\mathrm{1}))}$\\
${}$\\
${\Varid{eval}_{<:}\;(\Conid{Lambda}\;\Varid{ty1}\;\Varid{t}_1)\mathrel{=}\Varid{return}\;(\Conid{Lambda}\;\Varid{ty1}\;\Varid{t}_1)}$\\
${}$\\
${\Varid{eval}_{<:}\;(\Conid{Var}\;\Varid{t}_1)\mathrel{=}\Varid{fail}\;\text{\tt \char34 Evaluation~Error~-~Cannot~evaluate~free~variable\char34}}$\\
${}$\\
${\Varid{eval}_{<:}\;(\Conid{If}\;\Conid{TmTrue}\;\Varid{t}_2\;\Varid{t}_3)\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{tr}\leftarrow \Varid{eval}_{<:}\;\Varid{t}_2}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{return}\;\Varid{tr}}$\\
${\Varid{eval}_{<:}\;(\Conid{If}\;\Conid{TmFalse}\;\Varid{t}_2\;\Varid{t}_3)\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{fl}\leftarrow \Varid{eval}_{<:}\;\Varid{t}_3}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{return}\;\Varid{fl}}$\\
${\Varid{eval}_{<:}\;(\Conid{If}\;\Varid{t}_1\;\Varid{t}_2\;\Varid{t}_3)\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{cond}\leftarrow (\Varid{eval}_{<:}\;\Varid{t}_1)}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{eval}_{<:}\;(\Conid{If}\;\Varid{cond}\;\Varid{t}_2\;\Varid{t}_3)}$\\
${\Varid{eval}_{<:}\;(\Conid{ProjRcd}\;(\Conid{Rec}\;\Varid{r})\;\Varid{l})\mathrel{=}(\Varid{proj}\;\Varid{r}\;\Varid{l})}$\\
${\Varid{eval}_{<:}\;(\Conid{ProjTpl}\;(\Conid{Tpl}\;\Varid{t})\;\Varid{i})\mathrel{=}\Varid{return}\;(\Varid{t}\mathbin{!!}\Varid{i})}$
\end{tabbing}
\section{Type Checking and Evaluation}

The objective of type checking is to statically predict the runtime
behavior of a code element with respect to the kinds of values
produced and expected.  Specifically, does a program element always
product the kind of value espected?  The \texttt{typeof} function
provides a capability for generating the type associated with a
$\lambda_{<:}$ term.  If such a type exists, then the term is
well-typed and should be executed.

To combine type checking and evaluation is a simple matter of: (i)
determining the type of a term; and (ii) executing the term if the
type exists.  This process can be specified using the following
template:

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{interpTemplate}\mathbin{::}(\Conid{Term}\to \Conid{Retval}\;\Varid{T})\to }$\\
${\phantom{\Varid{interpTemplate}\mathbin{::}\mbox{}}(\Conid{Term}\to \Conid{Retval}\;\Conid{Term})\to }$\\
${\phantom{\Varid{interpTemplate}\mathbin{::}\mbox{}}\Conid{Term}\to }$\\
${\phantom{\Varid{interpTemplate}\mathbin{::}\mbox{}}\Conid{Retval}\;\Conid{Term}}$\\
${\Varid{interpTemplate}\;\Varid{typeof}_{<:}\;\Varid{eval}_{<:}\;\Varid{term}\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{termtype}\leftarrow (\Varid{typeof}_{<:}\;\Varid{term})}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{term'}\leftarrow (\Varid{eval}_{<:}\;\Varid{term})}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\Varid{return}\;\Varid{term'}}$\\
${}$\\
${\Varid{evalTemplateStar}\mathbin{::}(\Conid{Term}\to \Conid{Retval}\;\Conid{Term})\to \Conid{Term}\to \Conid{Retval}\;\Conid{Term}}$\\
${\Varid{evalTemplateStar}\;\Varid{eval}_{<:}\;\Varid{term}\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{do}\;\Varid{term'}\leftarrow (\Varid{eval}_{<:}\;\Varid{term})}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}};\mathbf{if}\;(\Varid{value}\;\Varid{term'})}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\mathbf{then}\;\Varid{return}\;\Varid{term'}}$\\
${\hskip2.00em\relax\phantom{\mathbf{do}\;\mbox{}}\phantom{;\mathbf{if}\;\mbox{}}\mathbf{else}\;(\Varid{evalTemplateStar}\;\Varid{eval}_{<:})\;\Varid{term'}}$
\end{tabbing}
\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{interpret}\mathbin{::}\Conid{Term}\to \Conid{Retval}\;\Conid{Term}}$\\
${\Varid{interpret}\mathrel{=}\Varid{interpTemplate}\;(\Varid{typeof}_{<:}\;[\mskip1.5mu \mskip1.5mu])\;\Varid{eval}_{<:}}$
\end{tabbing}
\section{Testing and Evaluation}

To test the interpreter, some functions from the book are provided
here.  They include the identity combinator, Church Boolean funtions,
some Church Numbers and the successor function defined for Church
numbers.

Note that with the introduction of types, all parameters must have
associated type annotations.  Although significant static checking
results, the flexibility of these functions is diminished.
Specifically, for the \texttt{ident} combinator a new combinator must
be written for each type.  No polymorphism exists and the type system
is strict, so there is no way to reuse the \texttt{ident} combinator
definition.  Such strictness is common in older programming languages,
but new polymorphism implementations render the approach obscolete.

\subsection{Identity Combinator}

Redefine the \ensuremath{\Varid{ident}} combinator to operate over \ensuremath{\Conid{Top}} to take
advantage of subtyping.  Evaluating the \ensuremath{(\Conid{App}\;\Varid{indent}\;\Varid{t})} combinator on
term defined in $\lambda_{<:}$ should result in \ensuremath{\Varid{t}} regardless of its type:

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{ident}\mathbin{::}\Conid{Term}}$\\
${\Varid{ident}\mathrel{=}(\Conid{Lambda}\;\Conid{TyTop}\;(\Conid{Var}\;\mathrm{0}))}$\\
${}$\\
${\Varid{testIdent}\mathbin{::}[\mskip1.5mu \Conid{Retval}\;\Conid{Term}\mskip1.5mu]}$\\
${\Varid{testIdent}\mathrel{=}}$\\
${\hskip2.00em\relax\Varid{map}\;\Varid{interpret}\;[\mskip1.5mu \Varid{ident},}$\\
${\hskip2.00em\relax\phantom{\Varid{map}\;\Varid{interpret}\;[\mskip1.5mu \mbox{}}(\Conid{Rec}\;[\mskip1.5mu (\text{\tt \char34 1\char34},\Conid{TmTrue}),(\text{\tt \char34 2\char34},\Conid{TmFalse}),(\text{\tt \char34 3\char34},\Varid{ident})\mskip1.5mu]),}$\\
${\hskip2.00em\relax\phantom{\Varid{map}\;\Varid{interpret}\;[\mskip1.5mu \mbox{}}(\Conid{ProjRcd}\;(\Conid{Rec}\;[\mskip1.5mu (\text{\tt \char34 1\char34},\Conid{TmTrue}),(\text{\tt \char34 2\char34},\Conid{TmFalse}),(\text{\tt \char34 3\char34},\Varid{ident})\mskip1.5mu])\;\text{\tt \char34 1\char34})\mskip1.5mu]}$\\
${}$\\
${\Varid{testRecord}\mathbin{::}[\mskip1.5mu \Conid{Retval}\;\Conid{Term}\mskip1.5mu]}$\\
${\Varid{testRecord}\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{let}\;\Varid{r}\mathrel{=}(\Conid{Rec}\;[\mskip1.5mu (\text{\tt \char34 1\char34},\Conid{TmTrue}),(\text{\tt \char34 2\char34},\Conid{TmFalse}),(\text{\tt \char34 3\char34},\Varid{ident})\mskip1.5mu])\;\mathbf{in}}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\Varid{map}\;\Varid{interpret}\;}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\phantom{\Varid{map}\;\mbox{}}[\mskip1.5mu (\Conid{ProjRcd}\;\Varid{r}\;\text{\tt \char34 1\char34}),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\phantom{\Varid{map}\;\mbox{}}\phantom{[\mskip1.5mu \mbox{}}(\Conid{ProjRcd}\;\Varid{r}\;\text{\tt \char34 3\char34}),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\phantom{\Varid{map}\;\mbox{}}\phantom{[\mskip1.5mu \mbox{}}(\Conid{ProjRcd}\;\Varid{r}\;\text{\tt \char34 4\char34}),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\phantom{\Varid{map}\;\mbox{}}\phantom{[\mskip1.5mu \mbox{}}(\Conid{AppV}\;(\Conid{ProjRcd}\;\Varid{r}\;\text{\tt \char34 3\char34})\;\Varid{r})\mskip1.5mu]}$\\
${}$\\
${\Varid{testRecSubtype}\mathbin{::}[\mskip1.5mu \Conid{Retval}\;\Conid{Term}\mskip1.5mu]}$\\
${\Varid{testRecSubtype}\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{let}\;\Varid{l}\mathrel{=}(\Conid{Lambda}\;(\Conid{TyRec}\;[\mskip1.5mu (\text{\tt \char34 1\char34},\Conid{TyBool}),(\text{\tt \char34 2\char34},\Conid{TyBool}),(\text{\tt \char34 3\char34},\Conid{TyBool})\mskip1.5mu])}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\Varid{l}\mathrel{=}(\mbox{}}(\Conid{ProjRcd}\;(\Conid{Var}\;\mathrm{0})\;\text{\tt \char34 2\char34}))\;\mathbf{in}}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\Varid{map}\;\Varid{interpret}\;}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\hskip4.00em\relax[\mskip1.5mu (\Conid{AppV}\;\Varid{l}\;(\Conid{Rec}\;[\mskip1.5mu (\text{\tt \char34 1\char34},\Conid{TmTrue}),(\text{\tt \char34 2\char34},\Conid{TmFalse}),(\text{\tt \char34 3\char34},\Conid{TmTrue})\mskip1.5mu])),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\hskip4.00em\relax\phantom{[\mskip1.5mu \mbox{}}(\Conid{AppV}\;\Varid{l}\;(\Conid{Rec}\;[\mskip1.5mu (\text{\tt \char34 1\char34},\Conid{TmTrue}),(\text{\tt \char34 2\char34},\Conid{TmFalse})\mskip1.5mu])),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\hskip4.00em\relax\phantom{[\mskip1.5mu \mbox{}}(\Conid{AppV}\;\Varid{l}\;(\Conid{Rec}\;[\mskip1.5mu (\text{\tt \char34 2\char34},\Conid{TmFalse}),(\text{\tt \char34 3\char34},\Conid{TmTrue})\mskip1.5mu])),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\hskip4.00em\relax\phantom{[\mskip1.5mu \mbox{}}(\Conid{AppV}\;\Varid{l}\;(\Conid{Rec}\;[\mskip1.5mu (\text{\tt \char34 1\char34},\Conid{TmTrue}),(\text{\tt \char34 4\char34},\Conid{TmFalse}),(\text{\tt \char34 3\char34},\Conid{TmTrue})\mskip1.5mu]))\mskip1.5mu]}$\\
${}$\\
${\Varid{testTuple}\mathbin{::}[\mskip1.5mu \Conid{Retval}\;\Conid{Term}\mskip1.5mu]}$\\
${\Varid{testTuple}\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{let}\;\Varid{r}\mathrel{=}(\Conid{Tpl}\;[\mskip1.5mu \Conid{TmTrue},\Conid{TmFalse},\Varid{ident}\mskip1.5mu])\;\mathbf{in}}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\Varid{map}\;\Varid{interpret}\;}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\phantom{\Varid{map}\;\mbox{}}[\mskip1.5mu (\Conid{ProjTpl}\;\Varid{r}\;\mathrm{0}),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\phantom{\Varid{map}\;\mbox{}}\phantom{[\mskip1.5mu \mbox{}}(\Conid{ProjTpl}\;\Varid{r}\;\mathrm{2}),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\phantom{\Varid{map}\;\mbox{}}\phantom{[\mskip1.5mu \mbox{}}(\Conid{ProjTpl}\;\Varid{r}\;\mathrm{3}),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\phantom{\Varid{map}\;\mbox{}}\phantom{[\mskip1.5mu \mbox{}}(\Conid{AppV}\;(\Conid{ProjTpl}\;\Varid{r}\;\mathrm{2})\;\Varid{r})\mskip1.5mu]}$\\
${}$\\
${\Varid{testTupleSubtype}\mathbin{::}[\mskip1.5mu \Conid{Retval}\;\Conid{Term}\mskip1.5mu]}$\\
${\Varid{testTupleSubtype}\mathrel{=}}$\\
${\hskip2.00em\relax\mathbf{let}\;\Varid{l}\mathrel{=}(\Conid{Lambda}\;(\Conid{TyTpl}\;[\mskip1.5mu \Conid{TyBool},\Conid{TyBool},\Conid{TyBool}\mskip1.5mu])}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\Varid{l}\mathrel{=}(\mbox{}}(\Conid{ProjTpl}\;(\Conid{Var}\;\mathrm{0})\;\mathrm{1}))\;\mathbf{in}}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\Varid{map}\;\Varid{interpret}\;}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\hskip4.00em\relax[\mskip1.5mu (\Conid{AppV}\;\Varid{l}\;(\Conid{Tpl}\;[\mskip1.5mu \Conid{TmTrue},\Conid{TmFalse},\Conid{TmTrue}\mskip1.5mu])),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\hskip4.00em\relax\phantom{[\mskip1.5mu \mbox{}}(\Conid{AppV}\;\Varid{l}\;(\Conid{Tpl}\;[\mskip1.5mu \Conid{TmTrue},\Conid{TmFalse}\mskip1.5mu])),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\hskip4.00em\relax\phantom{[\mskip1.5mu \mbox{}}(\Conid{AppV}\;\Varid{l}\;(\Conid{Tpl}\;[\mskip1.5mu \Conid{TmFalse},\Conid{TmTrue}\mskip1.5mu])),}$\\
${\hskip2.00em\relax\phantom{\mathbf{let}\;\mbox{}}\hskip4.00em\relax\phantom{[\mskip1.5mu \mbox{}}(\Conid{AppV}\;\Varid{l}\;(\Conid{Tpl}\;[\mskip1.5mu \Conid{TmTrue},\Varid{ident},\Conid{TmTrue}\mskip1.5mu]))\mskip1.5mu]}$
\end{tabbing}
\subsection{Church Boolean Definitions}

The boolean combinators must have typed parameters.  Real booleans are
chosen for simplicity.  Church Booleans don't make a great deal of
sense in a strongly typed language like this.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{tru}\mathbin{::}\Conid{Term}}$\\
${\Varid{tru}\mathrel{=}(\Conid{Lambda}\;\Conid{TyTop}\;(\Conid{Lambda}\;\Conid{TyTop}\;(\Conid{Var}\;\mathrm{1})))}$\\
${\Varid{fls}\mathbin{::}\Conid{Term}}$\\
${\Varid{fls}\mathrel{=}(\Conid{Lambda}\;\Conid{TyTop}\;(\Conid{Lambda}\;\Conid{TyTop}\;(\Conid{Var}\;\mathrm{0})))}$\\
${}$\\
${\Varid{testTru}\mathbin{::}\Conid{Retval}\;\Conid{Term}}$\\
${\Varid{testTru}\mathrel{=}\Varid{interpret}\;(\Conid{AppV}\;(\Conid{AppV}\;\Varid{tru}\;\Varid{ident})\;\Varid{fls})}$\\
${}$\\
${\Varid{testFls}\mathbin{::}\Conid{Retval}\;\Conid{Term}}$\\
${\Varid{testFls}\mathrel{=}\Varid{interpret}\;(\Conid{AppV}\;(\Conid{AppV}\;\Varid{fls}\;\Varid{fls})\;\Varid{ident})}$
\end{tabbing}
\subsection{Church Number Definitions}

The number combinators must have typed parameters.  Real booleans are
chosen for simplicity.  In a word, these definitions are not appropriate
anymore, but they are retained for testing.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{c}_0\mathbin{::}\Conid{Term}}$\\
${\Varid{c}_0\mathrel{=}(\Conid{Lambda}\;\Conid{TyBool}\;(\Conid{Lambda}\;\Conid{TyBool}\;(\Conid{Var}\;\mathrm{0})))}$\\
${}$\\
${\Varid{c}_1\mathbin{::}\Conid{Term}}$\\
${\Varid{c}_1\mathrel{=}(\Conid{Lambda}\;\Conid{TyBool}\;(\Conid{Lambda}\;\Conid{TyBool}\;(\Conid{AppV}\;(\Conid{Var}\;\mathrm{1})\;(\Conid{Var}\;\mathrm{0}))))}$\\
${}$\\
${\Varid{c}_2\mathbin{::}\Conid{Term}}$\\
${\Varid{c}_2\mathrel{=}(\Conid{Lambda}\;\Conid{TyBool}\;(\Conid{Lambda}\;\Conid{TyBool}\;(\Conid{AppV}\;(\Conid{Var}\;\mathrm{1})\;(\Conid{AppV}\;(\Conid{Var}\;\mathrm{1})\;(\Conid{Var}\;\mathrm{0})))))}$\\
${}$\\
${\Varid{scc}\mathbin{::}\Conid{Term}}$\\
${\Varid{scc}\mathrel{=}(\Conid{Lambda}\;\Conid{TyBool}}$\\
${\phantom{\Varid{scc}\mathrel{=}(\mbox{}}(\Conid{Lambda}\;\Conid{TyBool}}$\\
${\phantom{\Varid{scc}\mathrel{=}(\mbox{}}\phantom{(\mbox{}}(\Conid{Lambda}\;\Conid{TyBool}\;(\Conid{AppV}\;(\Conid{Var}\;\mathrm{1})}$\\
${\phantom{\Varid{scc}\mathrel{=}(\mbox{}}\phantom{(\mbox{}}\phantom{(\Conid{Lambda}\;\Conid{TyBool}\;(\mbox{}}(\Conid{AppV}\;(\Conid{Var}\;\mathrm{2})}$\\
${\phantom{\Varid{scc}\mathrel{=}(\mbox{}}\phantom{(\mbox{}}\phantom{(\Conid{Lambda}\;\Conid{TyBool}\;(\mbox{}}\phantom{(\mbox{}}(\Conid{AppV}\;(\Conid{Var}\;\mathrm{1})\;(\Conid{Var}\;\mathrm{0})))))))}$
\end{tabbing}
\subsection{Omega}

With the introduction of types, the omega combinator must type its
parameter.  Boolean is selected here for the sake of simplicity, but
other types could be used.

\begin{tabbing}
\qquad\=\hspace{\lwidth}\=\hspace{\cwidth}\=\+\kill
${\Varid{\Omega}\mathbin{::}\Conid{Term}}$\\
${\Varid{\Omega}\mathrel{=}(\Conid{Lambda}\;\Conid{TyTop}\;(\Conid{AppV}\;(\Conid{Var}\;\mathrm{0})\;(\Conid{Var}\;\mathrm{0})))}$
\end{tabbing}
\section{Notes}

The evaluation function is built to handle both call-by-value and
call-by-name function application.  This may end up causing problems
if the arguments to record and tuple references are treated as types
in the language rather than Haskell string and integer types.

Are record and tuple projections too aggressive for call-by-name
application?  They are not true functions in the langauge due to the
types of their reference values.

\bibliography{prog-langs}

\end{document}


% !TeX root = ../diss.tex

\chapter{Implementation}

\section{C implementation}
\label{sec:C_impl}

\subsection{Initial implementation}
\label{sec:Initial_C_impl}

First, I implemented Smith-Waterman’s algorithm in single-threaded C code.
I started with a simple implementation that stored the entire grid in a 2D array and calculated grid cells sequentially, which involved rewriting the definitions of the Smith-Waterman algorithm in C.
An excerpt (where \lstinline{decideCellSW} is similar to a \lstinline{max} function but also returns a pointer) is \cref{lst:c_sw}.

\begin{lstlisting}[language=C,float,basicstyle=\linespread{0.9}\ttfamily\footnotesize, label={lst:c_sw},captionpos=b,caption={Excerpt from C implementation of Smith-Waterman algorithm}]
for (unsigned long i = 0; i < len1; i++) {
    for (unsigned long j = 0; j < len2; j++) {
        decisions[i+1][j+1] = decideCellSW(
                decisions[i][j].score + match(seq1[i], seq2[j]),
                decisions[i][j+1].score + GAP_PENALTY,
                decisions[i+1][j].score + GAP_PENALTY
        );
        if (decisions[i+1][j+1].score >= bestCell->score) {
            bestCell->score = decisions[i+1][j+1].score;
            bestCell->i = i+1;
            bestCell->j = j+1;
        }
    }
}
\end{lstlisting}
This simple implementation did not perform very well, especially with long strings.
It is single-threaded, and the grid takes $O(NM)$ space for sequences of lengths $N$ and $M$.
Space was a major issue; working with the large grid in RAM was costly.
The number of alignments that could be run in parallel was limited due to memory constraints.
This is quantified in \cref{sec:C_impls_eval}.
However, this quadratic space implementation was used as a component of the linear space variant, and it also was the basis of my correctness testing (\cref{sec:Correctness_eval}).

\subsubsection{Back-tracing}
\label{sec:Initial_C_back_tracing}
In this implementation, nearly all of the time was spent filling out the of the grid (\cref{sec:C_occupancy}).
After this, an alignment was produced using a process called back-tracing (\cref{sec:SW_Back_tracing}). Stored with each grid cell is a ``pointer'' which locates the previous cell in the best alignment ending with that cell.

Using these pointers, starting at the best cell in the grid, a pair of aligned sequences is built up from back to front by following the pointers upwards and leftwards to a cell with a $Nil$ pointer.
This takes as many steps as there is symbols in the alignment, and an upper bound on this is $N+M$ steps for sequences of lengths $N$ and $M$.

\subsubsection{Linear space implementation}
\label{sec:Initial_C_Linear}
This implementation was a direct implementation of the algorithm described in \cref{sec:SW_Linear_Prep}.
It was slower than the quadratic space implementation, which was unsurprising because twice as much arithmetic was involved (\cref{sec:SW_Linear_Complexity}).
However, the implementation only took $50\%$ longer due to decreased memory usage and associated memory overheads (\cref{sec:C_impls_eval}).
Due to decreased memory usage there were not issues with performing multiple alignments at the same time, and the structure of the algorithm was amenable to parallelisation.

\subsection{Multi-threaded implementation}
\label{sec:Multi_threaded_C_impl}
This linear-space algorithm (\cref{sec:SW_Linear_Prep}) was simple to parallelise, because each grid could be processed in parallel.
Memory consistency is trivial to maintain because no data is shared between running threads; threads just join after processing their grid segment.
However, given infinite threads there is still a finite speedup, because the number of different segments of the grid available for evaluation is limited.
This limit increases as the algorithm progresses.
At the start, there are two grid segments (each taking half of the whole grid) being evaluated to find their middle columns.
If the optimal alignment crosses the middle column, the algorithm is applied recursively between the chosen cell in the middle column, and the top-left or bottom-right of the rest of the grid.
This has four sub-grids (a forwards and backwards one on each side of the middle column), covering a total area of half of the grid. Assuming infinite threads, this generalises to:
$$\text{Cells evaluated } = \frac{1}{2} \times NM + \frac{1}{4} \times \frac{NM}{2} + \frac{1}{8} \times \frac{NM}{4} + \cdots \leq \frac{1}{2} \times NM \sum_{i=0}^\infty 2^{-2i} = \frac{2NM}{3}$$

This limit was not reached in practice (\cref{sec:C_impls_eval}) but it is useful to consider.
To improve on this limit, there would need multiple threads working on each segment of the grid.
A major concern with this is synchronising threads such that they only evaluate cells when the cells they depend on have been evaluated by a different thread.
This could yield poor performance due to threads waiting on each other, and for this reason I did not prioritise implementing this approach, and I did not have time to do so.
GPUs and FPGAs are attractive platforms for solving this problem because they make it very simple to schedule threads relative to one another.

\subsubsection{Synchronisation and scheduling of work}
\label{sec:Sync_and_scheduling_of_multi-threaded_C}
I used the Native POSIX Thread Library, part of the GNU C Library, to implement this multithreaded solution.
The scheduling of threads is handled by the library and the host operating system.
By assigning the work to fill out the two halves of a grid to two different threads, and also the two recursive calls of the linear space solver to different threads, the linear space algorithm is straightforward to parallelise.
This can be seen in \cref{fig:Linear_Space_Structure}, where the numbered blocks can each be evaluated by a different thread.

My implementation was slightly more complex, allowing me to investigate how the number of available CPU cores changed the throughput of my implementation.
The results of this are presented in \cref{sec:C_params_eval}.
This was achieved using a counting semaphore to represent the number of concurrent threads performing arithmetic.
This semaphore guards the regions that were evaluating grid cells, which corresponds to the \cref{lst:pseudo_sw,lst:pseudo_sw_col}.
Threads about to enter these regions wait on the semaphore, and signal the semaphore when they leave those regions.
The effect of different numbers of working threads could be evaluated by changing the size of the semaphore.
The highest throughput on my 6-core SMT CPU was achieved using 12 threads (\cref{sec:C_params_eval}).

\subsection{Sequence similarity functions and scoring gaps}
\label{sec:Scoring_in_C_impl}
The two forms of sequence similarity function discussed in \cref{sec:SW_similarity_functions} were implemented, and the performance was evaluated later (\cref{sec:C_scoring_eval}).

Both the linear and affine gap scoring mechanisms were implemented.
The linear space implementation needed to account for horizontal gaps being opened on one side of the middle column but continued through to the other side.
This can be solved by adding the middle columns coming for both the the gap matrix $P_{i,j}$ and the score matrix $H_{i,j}$.
These decisions also need to be propagated into the sub-problems as well.
This was the approach taken by Myers and Miller \cite{MyersMiller} in their adaption of Hirschberg’s algorithm \cite{Hirschberg} to local alignment.

\section{CUDA implementation}
\label{sec:CUDA_impl}
My implementation in CUDA took a similar approach to the C implementation but using a streaming multiprocessor to evaluate many grid cells in parallel on the same device.
The SIMT (single-instruction, multiple-thread) architecture makes it is easier to synchronise work between multiple threads running the same instructions.
In CUDA there are two broad categories of parallelism: parallelism between threads (parallelism inside a multiprocessor), and parallelism between blocks (parallelism between multiprocessors).
Each of these were utilised in my implementation.

\subsection{Parallelism between threads}
\label{sec:Thread_Parallelism_in_CUDA}
Multiple threads run inside of a block simultaneously, scheduled in warps of $32$ threads, with shared memory and barrier synchronisation to allow for cooperation between threads in different warps.
I built up a diagonal front of threads, so that threads only depend on results that other threads have already computed.
This is similar to the approach taken by Ling et al. \cite{Ling_GPU}, however in their approach they exploit parallelism between blocks by running multiple alignments at the same time, whereas I chose to use multiple blocks in a single alignment.
Under my design multiple different alignments can also be running in parallel, but large and difficult alignments can exploit more than one streaming multiprocessor.

Threads on the anti-diagonal to the grid have no data dependencies and can be executed in parallel.
This is the basis for much of the parallelisation in the GPU and FPGA implementations.
This can be seen in \cref{fig:Diagonalised_Grid}, where dark grey cells have already been computed, and light grey cells can all be computed in parallel.
Dependencies between cells are shown as red arrows.

\begin{figure}
  \centering
  \includegraphics[width=\textwidth/2]{figs/diagonalised_grid.pdf}
  \caption{An anti-diagonal of data dependencies in Smith-Waterman’s algorithm}
  \label{fig:Diagonalised_Grid}
\end{figure}

The general approach is to assign each column to a thread and stagger the threads so that if thread $t$ is working on row $r$, then thread $t+1$ is working on row $r+1$.
Threads are then synchronised using a barrier so that only one anti-diagonal is being computed at a time.
With an unlimited number of threads, the time spent calculating the grid changes from being quadratic to linear in sequence length, taking $N + M - 1$ steps because there are that many anti-diagonals in a grid of dimensions $N\times M$.

In reality, there is a limit to the number of threads allowed in a block in CUDA ($1024$ threads), and only $32$ threads of a given block can be executing at once.
Therefore, every column cannot be assigned its own exclusive thread.
My first approach was to have a single block of threads generate the entire grid, by generating blocks of columns at a time, where each individual column had its own thread and upon reaching the end of the columns, new blocks of columns were generated.
However, when profiling my program using NVProf, it suggested that a way to improve performance might be to spread my work out over multiple thread blocks, which would spread the work over multiple streaming multiprocessors.
This had a noticeable performance improvement (\cref{sec:CUDA_single_multi_block_eval}).

\subsection{Parallelism between blocks}
\label{sec:Block_Parallelism_in_CUDA}

The opportunity for parallelism described in \cref{sec:Thread_Parallelism_in_CUDA} exists between blocks of threads, as well as threads themselves.
Although squares in \cref{fig:Diagonalised_Grid} represent threads, it also is an accurate representation when squares represent blocks as well.
This is the basis of my implementation for generating the grid using multiple blocks at once.

However, a different approach needs to be taken for communications between different anti-diagonals.
It is possible to impose an ordering of execution between threads in a block, but it is not possible to impose an ordering between blocks of a kernel grid.
There is no guarantee on the order in which blocks may be executed, there is a limit to the number of blocks that can be resident on the device, and blocks cannot leave the device until they have finished executing.
Therefore, attempting to impose an ordering by building up concurrency primitives from global memory may lead to deadlock.

Therefore, the kernel needs to be broken up into multiple smaller kernels, where blocks have no dependencies on one another.
This is done using the approach outlined above on the block-scale, where a kernel is made up of an anti-diagonal of blocks, and the number of blocks depends on the size of the grid and which anti-diagonal is being computed.
Each block writes out its right and bottom edges to global memory on the device, ready for the next block from the next kernel to consume.
All the data remains on the device so there is relatively little overhead in making many blocks for relatively short periods of time.

\subsection{Memory types}
\label{sec:Memory_in_CUDA}

The grid of scores and pointers is stored in the global memory, which is the GDDR5 VRAM used by the GPU.
There is $\SI{4}{\gibi\byte}$ of this in my laptop and it has much higher bandwidth than the DDR4 main memory in the laptop.
GPUs are designed to hide memory access latency for this memory by context switching between many different threads, so it is a good fit for this algorithm with many loads and stores.

Alternatively, shared memory (on the die of the GPU) could have been used but this is too small with only $\SI{1152}{\kibi\byte}$ available.
A block of $1024$ threads has access to only $\SI{48}{\kibi\byte}$, with room for a $78\times78$ cell grid.
With a capacity of $\SI{4}{\gibi\byte}$, the GDDR5 VRAM, was the best choice for storing the grid.

\subsection{Back-tracing}
\label{sec:Back_tracing_in_CUDA}

Back-tracing is performed on the GPU.
Even though it is a sequential process that only uses one thread of a $32$-thread multiprocessor, it is significantly quicker than it would be to copy the entire grid out of VRAM into RAM, and have the CPU run the back-tracing.
To back-trace on the CPU, too much time would be wasted copying over unwanted data: only $N+M$ grid cells could be needed out of the $N\times M$ cell grid, and finding which are needed is the process of back-tracing.

\subsection{Linear space improvements}
\label{sec:Linear_space_CUDA}

For similar reasons to the C implementation, there are performance limitations when using this quadratic space algorithm.
For large sequences memory will simply run out; a $\SI{23710}{} \times \SI{23170}{}$ grid is the largest grid that will fit in the $\SI{4}{\giga\byte}$ VRAM.
Fortunately, the linear space algorithm (\cref{sec:SW_Linear_Prep}) can also be implemented in CUDA using the same techniques discussed in \cref{sec:Thread_Parallelism_in_CUDA,sec:Block_Parallelism_in_CUDA,sec:Memory_in_CUDA,sec:Back_tracing_in_CUDA}.

Using this approach the problem is divided in half repeatedly; calculating the scores for the middle column using linear space to decide where to divide.
The control logic was implemented on the host device (the CPU), but the evaluation of grid cells and back-tracing of alignments was done on the GPU.
This was a sensible choice because most of the control flow decisions are sequential which would poorly utilise 32-thread multiprocessor on the GPU.
Moreover, the CPU achieves a much higher clock frequency and sequential throughput than the GPU.

Calculating a half-grid segment requires multiple kernel invocations for each segment, so the control logic was also multi-threaded where each segment had its own thread.
This was facilitated by CUDA Streams, which are similar to OS processes or threads.
When evaluating a grid, all of the blocks on the current anti-diagonal need to have finished before the next anti-diagonal can be processed, and the CPU can only synchronise with the GPU when either the entire GPU finishes all available work, or when all work in a stream has finished.
With each thread of C code assigned its own CUDA stream, the thread can synchronise with the work it has sent to the GPU whilst leaving other streams (and therefore threads) to utilise the GPU at the same time.
The first few and last few anti-diagonals of a grid will have fewer blocks of work than streaming multiprocessors available, so utilisation of these multiprocessors can be increased by using multiple concurrent streams of work, working on different parts of the alignment.

Using this implementation to compare multiple sequences at once is trivial, simply a new thread and stream is created for each alignment, and all subsequent new threads and streams required will be created by the alignment program.
All scheduling is done by the operating system and GPU hardware, which should lead to maximum resource utilisation provided there is the work to consume it.

\subsection{Sequence similarity functions and scoring gaps}
\label{sec:Scoring_in_CUDA_impl}

The same approach to sequence similarity functions and scoring gaps taken for the C implementation (\cref{sec:Scoring_in_C_impl}) was also used for the CUDA implementation.
The more complex scoring mechanisms such as similarity matrices and affine gaps had a performance penalty which is discussed in \cref{sec:CUDA_scoring_eval}.

\section{SystemVerilog implementation for FPGA}
\label{sec:SV_impl}

My SystemVerilog implementation was a systolic array.
This is an approach which has been used before \cite{FPGA_Impl}, and is sensible given the structure of the problem.
A systolic array is a sequence of processing elements (PEs), where each element produces signals to be used by the next element in the array.
This can be used to encode the horizontal data dependencies between grid cells in SystemVerilog, which in turn will lead to the data dependencies being represented in routing hardware.
The vertical data dependencies can be encoded into each PE.

The approach is simplest to explain using small fixed-length sequences, but it can be generalised to arbitrary length sequences.
Each PE calculates the scores and pointers for a different column in the grid, where the PE can evaluate a cell every cycle.
The value above the current cell was calculated by the same PE and is remembered by that PE.
The values to the left and diagonal are calculated by the previous PE, and this passed from one PE to the next.

The cells being evaluated in the array follow an anti-diagonal of the grid.
This is achieved by passing `enable' signals down the array to form a shift register, with the first PEs to be enabled also are the first to be disabled because they reach the bottom of the grid first.
This architecture is called a systolic array, with data pumping in and out of the array like a heart pumping blood \cite{SystolicArrays}.

Each PE only needs to store one sequence symbol for the column, because this remains constant, and the symbol relating to the row can propagate through the array.
Each PE also keeps a running maximum score and position, and sends this down the array.
The last element will output the maximum score and position for the entire grid, which is where the back-tracer will start from.

The scores are only required for a brief period; they are only used in the evaluation of three cells. Instead of storing this in some external data structure, this can be embedded in the registers of each processing element and stored within the systolic array.
An array of pointers still needs to be maintained for back-tracing, and this became a limiting factor of my design.

To modify this design to work with sequences of variable length, a first-in first-out (FIFO) queue is required to buffer a column of scores.
Each column is still processed by one PE, but for an array of length $n$ the PE at index $i$ will process columns $kn+i < N$ for integers $k$ and sequence length $N$.
The PE at the end of the array writes its scores out to the FIFO, and when the first PE reads these scores from the FIFO to produce the next block of columns.
This approach will work for sequences of any length, but in practice is limited by memory capacity for storing this FIFO and grid of pointers.
\Cref{fig:Medium_Systolic_Array} is an overview of the systolic array, and \cref{fig:PE_Cell} shows the structure of a processing element.

\begin{figure}
    \centering
    \includegraphics[width=0.9\textwidth]{figs/med_systolic_array.pdf}
    \caption{An overview of the systolic array}
    \label{fig:Medium_Systolic_Array}
\end{figure}

\begin{figure}
    \centering
    \includegraphics[width=0.75\textwidth]{figs/pe_cell.pdf}
    \caption{The structure of a single processing element in the systolic array}
    \label{fig:PE_Cell}
\end{figure}

\subsection{Device memory limitations}
\label{sec:Memory_in_SV}

The limiting factor is needing to store this array of pointers.
Each pointer can be one of four values, so $\SI{2}{\bits}$ per pointer was required.
For two sequences of lengths $N$ and $M$, $N\times M$ such pointers are required.
In each cycle each PE could be writing out a pointer, and this bandwidth requirement also influenced the choice of what type of memory to use.

There are several different types of memory on the development board I used, with different characteristics (\cref{tab:FPGA_Memories}).
Bandwidth limitations to the highest capacity memory devices (the $\SI{64}{\mebi\byte}$ SDRAM for the FPGA, and the $\SI{1}{\gibi\byte}$ SDRAM for the HPS) would have limited the size of the systolic array to $8$ or $32$ PEs respectively, due to their 16-bit and 64-bit buses.
I instead chose to use the M10K embedded memory blocks, which is the largest collection of memory that does not have these bandwidth limitations.

Instead, the design was limited by the number of M10K blocks available.
There are $397$ M10K blocks on the board I was using, giving $\SI{3970}{\kibi\bit}$ of total memory; approximately 2 million possible pointers or a $1425\times1425$ grid.
In practice, $5$ M10K blocks were used in the interface between the HPS and FPGA, and the FIFO needed to be stored.
The FIFO is either $N$ or $M$ $\SI{16}{\bit}$ twos-complement integers long.
On top of this, each processing element needs exclusive access to the memory blocks for each part of the grid, if each processing element is to write every cycle.
Sharing blocks between PEs would have added complexity, and likely caused delays and hazards in the design.

With these constraints in mind, I chose the maximum sequence lengths of this implementation to be $1024\times1536$ symbols.
This grid can fit in $384$ M10K blocks, using $96.7\%$ of the blocks available.
The FIFO is $1024$ words long, and fits in $2$ M10Ks.
The systolic array had $48$ PEs, with each PE writing to $8$ M10K blocks of pointer grid.
Due to the factor of $3$ in $1536$, the length of the systolic array needs to be a multiple of $3$ to allow each M10K to be assigned to exactly one PE.
Due to this addressing constraint, the next largest systolic array that would work under this arrangement would have $96$ elements each with $4$ M10Ks.
However, the $48$ PE array requires $62\%$ of the logic elements when aligning DNA, and $93\%$ when aligning proteins (\cref{sec:FPGA_utilisation}).
In both cases, doubling the number of PEs was not possible without a larger FPGA.

With a more modern FPGA, such as a similarly priced Cyclone 10 FPGA to the Cyclone V when that was first sold, would have nearly double the logic elements and quadruple the amount of embedded memory \cite{Cyclone10}.
My design would likely be able to be instantiated as a $96$ PE array, and could align sequences of lengths $2048$ and $3072$, probably at a higher clock speed as well.

\subsection{Back-tracing}
\label{sec:Back_tracing_in_SV}

Back-tracing involves starting at the best cell found by the systolic array, and following the pointers through the grid.
A minor challenge was that it takes a cycle between requesting an address from a M10K block and getting the data out.
It is possible to pipeline requests, where the next address is requested whilst the previous address is being read out, but this would have been complex to implement.
This meant that back-tracing takes two cycles per aligned symbol, with an upper bound on the number of cycles spent back-tracing being $2\times(N+M)$.

I chose not to pipeline this because back-tracing only takes a small amount of the overall execution time.
When aligning sequences of lengths of $1024$ and $1536$, only $13\%$ of the time is spent back-tracing (\cref{sec:Processing_time_on_FPGA}).
Using Amdahl’s law, if I could improve back-tracing to only take one cycle per symbol, the expected speedup is $1.07$ times; it would not have a significant impact overall processing time.
$$Speedup = \frac{1}{87\% + \frac{1}{2}\times 13\%} = 1.07 $$

\subsection{Processing time}
\label{sec:Processing_time_on_FPGA}
It is possible to derive exactly the amount of time it will take to align two sequences when working with FPGAs with constant clock frequencies.
For the design described above, with $48$ PEs in the systolic array, and sequences of lengths $N$ and $M$, the runtime is as follows.

For a 48-column section of the grid, it takes $48$ cycles for the last column to begin being evaluated, and then $N$ cycles to reach the bottom of that last column, requiring $N+48$ cycles in all.
One additional cycle is required, to find the diagonal score for the first column.
In conclusion, each 48-column section of the grid takes $N+49$ cycles to evaluate.

The number of 48-column segments in the grid is $\left \lceil \frac{M}{48} \right \rceil$.
Even when processing the last segment, which may have fewer than $48$ columns to consider, the device must wait $N+49$ cycles because the best score and location needs to propagate to the last PE, from which it is read by the back-tracing logic.
Combining this, the number of cycles required to produce the grid is ${(N+49) \times \left \lceil \frac{M}{48} \right \rceil}$

As discussed in the \cref{sec:Back_tracing_in_SV}, the amount of time required by the back-tracing logic is bounded by $2\times(N+M)$, so the number of cycles required for an alignment is:
$$\text{Runtime} = (N+49) \times \left \lceil \frac{M}{48} \right \rceil + 2 \times (N+M)$$

This expression is $O(NM)$.
Evaluating this expression with the maximum sequence lengths of $1024$ and $1536$ from previous section:
$$\text{Runtime} = (1024+49) \times \left \lceil \frac{1536}{48} \right \rceil + 2 \times (1024+1536) = \SI{39456}{\cycles}$$
Where $5120$ of the $\SI{39456}{}$ cycles ($13\%$) are spent back-tracing and the rest on filling the grid.
For the design which aligned DNA sequences I was able to clock my logic at $\SI{79}{\mega\hertz}$ using a PLL, so this pair of DNA sequences requires $\SI{499.4}{\micro\s}$ to execute.
Due to the additional complexity when aligning proteins my design could only run at $\SI{60}{\mega\hertz}$, so this pair of protein sequences requires $\SI{657.6}{\micro\s}$ to execute.
These limitations are discussed in \cref{sec:SV_Fmax}.

\subsection{Sequence similarity functions and scoring gaps}
\label{sec:Scoring_in_SV_impl}

Sequence similarity functions and gap penalty values were compiled into the hardware.
This reduces the flexibility of a compiled design, but this was sufficient for the testing I was doing.
For aligning nucleotides, I used a constant sequence similarity function and for aligning proteins I used the BLOSUM50 scoring matrix.
Representing one of four nucleotides takes $\SI{2}{\bits}$ but representing one of $22$ amino acids takes $\SI{5}{\bits}$.
This increased representational cost, alongside the quadratically scaled lookup table to align symbols, leads to the increased logic utilisation for the protein aligning circuit and also a lower maximum clock speed of that design (\cref{sec:FPGA_utilisation}).

I did not have the time to implement an affine gap scoring mechanism (\cref{sec:SW_gaps}) in my FPGA implementation, but the entire FPGA implementation was a project extension.
I expect it would not have had a major performance penalty.
The number of scores that need to be stored will triple (to cover three grids instead of one), but the systolic array only stores a small number of these scores to begin with.
The number of comparisons inside PEs would increase by two per cycle (one for each gap matrix), and only increase the comparison tree depth by one level.

\section{Repository overview}
\label{sec:Repo_overview}

My source code repository is divided into three sections (\lstinline{cpu_code}, \lstinline{gpu_code}, \lstinline{fpga_code}) which reflect the three major implementations of my project.
All code in it has been written from scratch, apart from the FPGA-HPS interfaces (\lstinline{fpga_code/systemverilog/*_avalon.sv}, and the contents of \lstinline{fpga_code/c_interface/}) which are based on code from my supervisor Peter Rugg, as discussed in \cref{sec:Starting_Point}.
A detailed overview can be found in \cref{fig:Repo_tree}.

\input{repo_overview}


\subsection{Complex differentiation}


%
% begin in Jan. 19th, 2010
%
%
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Energy Derivatives in Quantum Chemistry}
%
%
%
In quantum chemistry, the evaluating for the energy derivatives with
respect to the changes of system is overwhelming important, for many
aspects; such as energy surface study, the vibration etc. are all have
to employ such technic. Hence in this chapter, we will gather all of
such technics systematically together, and all of content are mainly
from the book written by  Yukio Yamaguchi, John D. Goddard, Yoshihiro
Osamura and Henry
Schaefer\cite{New_Dimension_for_Derivatives_Calculation}. However,
actually many people had made great contribution to this area,
especially Pulay\cite{Pulay1, Pulay2, Pulay3, Pulay4, Pulay5,
Pulay6, pulay:5043}, and other people\cite{bishop:3515,
RevModPhys.45.22, jorgensen:334, king:5645, meyer:2109}. However, the
book by Henry Schaefer etc. is representing a generalization of
nearly all the views or ideas, and the author recommends that
the further reference for each detailed topic can be found in this
book.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
In quantum chemsitry, the core idea for approximating general wave
function is called ``single electron approximation'' (in DFT, it's
called non-interacting system mapping relationship). This important
idea introduces the idea of molecular orbital, where the general wave
functions for the whole system is building from it. The relation
between the MO and the general wave function etc. is depicted in the
figure\ref{derivatives_fig:1}.
\begin{figure}[bhtp]
 \centering
 \includegraphics[scale=0.7]{mo_in_energy_drv.eps}
 \caption{MO general description}
 \label{derivatives_fig:1}
\end{figure}

Here as what has been demonstrated in (\ref{derivatives_fig:1}), the
MO is composed by two parts: one is the basis set functions (we can
know it always takes the GTO or STO form, the other form like plane
wave function is rarely used), the other is the MO coefficients
before each basis sets function. Hence, all the energy derivatives
will finally be expressed based on the basis sets function integrals
derivatives and the MO coefficient derivatives. Now in this section
we will give some analysis to this part.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Derivatives expressions for the integrals and the MO
coefficients}
%
%
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{General Perturbation method}
%
%
%
The energy derivatives could be considered as a small preturbation on
the Hamiltonian (because of the geometrical changes or the adding on
some electric fields). Just let's take geometrical change as an
example, hence the Hamiltonian can be expressed as some Talor
expansion:
\begin{equation}
\label{General_Perturbation_method_eq:1}
 \hat{H} =
\hat{H}_{0}+\lambda_{a}\hat{H}_{a}^{'}+\lambda_{b}\hat{H}_{b}^{'} +
\frac{1}{2}\lambda_{a}^{2}\hat{H}_{a}^{''} +
\frac{1}{2}\lambda_{b}^{2}\hat{H}_{b}^{''} +
\lambda_{a}\lambda_{b}\hat{H}_{ab}^{''}    + \cdots
\end{equation}
Here the $\lambda$ character the order of perturbation (similar with
the $\lambda$ in the \ref{PTIQMeq:1}, but as an extension), and the
$\hat{H}^{'}$ and $\hat{H}_{a}^{''}$ are the perturbed operators for
Hamiltonian, $a$ and $b$ characterize different direction for the
geometrical perturbation.

Then according to the perturbation theory, the integrals as well as
the the MO coefficients are all able to expressed in terms of
perturbation series:
\begin{equation}
\label{General_Perturbation_method_eq:2}
 S_{\mu\nu}^{perturbed} =
S_{\mu\nu}+
\lambda_{a}\frac{\partial S_{\mu\nu}}{\partial a} +
\lambda_{b}\frac{\partial S_{\mu\nu}}{\partial b} +
\frac{1}{2}\lambda_{a}^{2}
\frac{\partial^{2} S_{\mu\nu}}{\partial a^{2}} +
\frac{1}{2}\lambda_{b}^{2}
\frac{\partial^{2} S_{\mu\nu}}{\partial b^{2}} +
\lambda_{a}\lambda_{b}
\frac{\partial^{2} S_{\mu\nu}}{\partial a\partial b} +
\cdots
\end{equation}
This is for the overlap integrals in AO. For the MO coefficients, the
expression is same:
\begin{equation}
\label{General_Perturbation_method_eq:3}
 C_{i}^{perturbed} =
C_{i}+
\lambda_{a}\frac{\partial C_{i}}{\partial a} +
\lambda_{b}\frac{\partial C_{i}}{\partial b} +
\frac{1}{2}\lambda_{a}^{2}
\frac{\partial^{2} C_{i}}{\partial a^{2}} +
\frac{1}{2}\lambda_{b}^{2}
\frac{\partial^{2} C_{i}}{\partial b^{2}} +
\lambda_{a}\lambda_{b}
\frac{\partial^{2} C_{i}}{\partial a\partial b} +
\cdots
\end{equation}
This is the starting point for further study.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "../../main"
%%% End:


\chapter{Animation}

{\Rayshade}\ provides basic animation animation support by
allowing time-varying
transformations to be associated with primitives and aggregate objects.
Commands are provided for controlling the amount of time between each
frame, the speed of the camera shutter, and the total number of frames
to be rendered.

By default, {\rayshade} renders a single frame, with the shutter open for
an instant (0 units of time, in fact).  The shutter speed in no way
changes the light-gathering properties of the camera, i.e., frames
rendered using
a longer exposure will not appear brighter than those with a shorter
exposure.  The only change will be in the potential amount of movement
that the
frame ``sees'' during the time that the shutter is open.

Each ray cast by {\rayshade} samples a particular moment in time.
The time value assigned to a ray
ranges from the starting time of the current frame to the starting
time plus the amount of time the shutter is open.  When
a ray encounters an object or texture that possesses an animated
transformation, the transformed
entity is moved into whatever position is appropriate
for the ray's current time value before intersection, shading, or texturing
computations are performed.

The starting time of the current frame is computed using the
length of each frame
the current frame number, and the starting time of the first frame.

\begin{defkey}{shutter}{{\em t}}
	Specifies that the shutter is open for t units of
	time for each exposure.
\end{defkey}
A larger value of {\em t} will lead to more motion blur in the final
image.   Note that {\em t} may be greater than the actual length
of a frame.  By default, {\em t} is zero, which prevents all motion blur.

\begin{defkey}{framelength}{{\em frameinc}}
	Specifies the time increment between frames.
\end{defkey}
The default time between frames is 1 unit.

\begin{defkey}{starttime}{{\em time}}
	Specifies the starting time of the first frame.
\end{defkey}
By default, {\em time} is zero.

Variables may be defined thorugh the use of the {\tt define} keyword:

\begin{defkey}{define}{{\em name value}}
	Associate {\em name} with the given {\em value}.  Value may
	be a constant or a parenthesized expression.
\end{defkey}
The variable {\em name} may thereafter be used in expressions in the
input file.

An animated transformation is one for which animated expressions have
been used to define one or more of its parameters (e.g. the angle through
which a rotation occurs).  An animated expression is one that makes
use of a time-varying (``animated'') variable or function.

There are two supported animated variables.
The first, {\tt time}, is equal to the current time.
When a ray encounters an animated
transformation defined using an expression containing {\tt time}, the ray
substitutes its time value into the expression before evaluation.
Using the {\tt time} variable in an animated expression is the most
basic way to create blur-causing motion.

The second animated variable, {\tt frame}, is equal to the current
frame number.  Unlike the {\tt time} variable, {\tt frame} takes on
a single value for the duration of each frame.  Thus, transforms
animated through the use of the {\tt frame} variable will not exhibit
motion blurring.

Also supported is the {\tt linear} function.  This function uses
{\tt time} implicitly to interplate between two values.

\begin{defkey}{linear}{{\tt (} {\em Stime, Sval, Etime, Eval} {\tt )}}
	Linearly interpolate between {\em Sval} at time
	{\em Stime} and {\em Eval} at time {\em Etime}.
	If the current time is less than {\em Stime}, the function
	returns {\em Sval}.  If the current time is greater than
	{\em Etime}, {\em Eval} is returned.
\end{defkey}

The following example shows the use of the {\tt time} variable to
animate a sphere by translating it downwards over five frames.
Note thet the {\tt shutter} keyword is used to set the shutter duration
in order to induce motion blurring.

\begin{verbatim}
    frames 5
    shutter 1
    sphere 1 0 0 2 translate 0 0 (-time)
\end{verbatim}

Further examples of animation may be found in the Examples directory
of the {\rayshade} distribution.


\section{Design of the Framework}

\newpar Our analysis supports input programs in the \textit{TIP} language described by Schwartzbach \cite{spa}. The \textit{TIP} language resembles a subset of \textit{C} and we have therefore implemented support for a subset of \textit{C} resembling \textit{TIP}. The following sections give an overview of the supported language.

\subsection{Expressions}
The basic expressions all denote integer values: \\

$
\begin{aligned}
    I & \rightarrow -1\;|\;0\;|\;1\;|\;2\;|\;... \\
    X & \rightarrow x\;|\;y\;|\;z\;... \\
    E & \rightarrow { I } \\
    & \rightarrow { X } \\
    & \rightarrow E\texttt{+}E\:|\:E\texttt{-}E\:|\:E \texttt{*} E\:|\:E \texttt{/} E\:|\:E\texttt{>}E\:|\:E\texttt{==}E \\
    & \rightarrow\texttt{(}E\texttt{)} \\
    & \rightarrow\texttt{input}
\end{aligned}
$

\subsection{Statements}
The simple statements are similar to C: \\

$
\begin{aligned} S & \rightarrow X = E \\
& \rightarrow \texttt {output } E ; \\
& \rightarrow S\:S \\
& \rightarrow \texttt{if(}E\texttt{)}\{S\} \\
& \rightarrow \texttt{if(} E \texttt{)}\{S\} \texttt { else }\{S\} \\
& \rightarrow \texttt {while (}E\texttt{)}\{ S\}
\end{aligned}
$

\subsection{An Example Program}
A program implemented in the supported subset of C can be seen in Fig. \ref{exampleprogram}.

\begin{figure}[H]
    \centering
    \begin{minted}{c}
        int main()
        {
            int x;
            x = 1;
            int y;
            y = 0;
            int z;
            z = 0 + 1;
            if (y == 0) {
                while(1) {
                    x = 0;
                }
            }
            else {
                x = 1;
            }
            return x + y;
        }
    \end{minted}
    \caption{An example program in \textit{TIP}-inspired subset of C.}
    \label{exampleprogram}
\end{figure}

\newpar A requirement of this project was that the user of the analyzer should be able to supply their own analyses. We decided to enable this by having the user define a lattice and transfer functions which are then used by the analyzer in order to gain knowledge about input programs.

\newpar Due to the requirement of a user passing their own analyses to the framework and the fact that these analyses need to be loaded at runtime, Python was used for the implementation of our analyzer. Given the dynamic nature of the Python programming language, evaluating Python scripts dynamically at runtime is supported by the language and therefore relatively easy. An implementation in a compiled language,OCaml, was initially attempted, but this turned out to be too unstable in practice, given the static strongly typed nature of the language. Loading arbitrary user code is to a great extent not supported in compiled languages and this dynamic loading of arbitrary modules is where dynamic languages shine.

\newpar The user supplies our framework with a list of file names containing Python class definitions. The framework dynamically loads these analyses which the user is expected to formulate as individual Python scripts. These scripts must implement and expose an \texttt{Analysis} class containing the components our framework implementation expects to be present in order to analyze.

\newpar A disadvantage in using a dynamic language is the lack of type checks. Python supports type annotations, but these are generally ignored by interpreters. The type annotations read more like comments in the source code than actual safety guarantees. This means that we have no way of enforcing that the analyses supplied by the user adhere to an interface or a class definition, and we can only provide examples for the user to follow when implementing their analyses. This is unfortunate, since the framework will simply throw an \texttt{Error} when attempting to evaluate the users' analyses. Using a compiled language would allow us to specify a signature for the analyses of the user to implement, guaranteeing that the analysis could be run without errors --- provided that the users' own implementations does not raise errors.

\newpar The framework is invoked with a list of filenames of analysis files. These files are implemented as very basic Python modules, which are then imported at runtime. An invocation of the two analyses \texttt{AnalysisA} and \texttt{AnalysisB} would require the user to provide the list of analyses as to the framework as \texttt{"AnalysisA:AnalysisB"} and the framework then attempts to import these modules.
User analyses are expected to be located in the \texttt{analyzers} subfolder of the framework implementation in a corresponding subfolder. Due to the way Python expects modules to be structured, a file named \texttt{\_\_init\_\_.py} needs to be co-located with the analysis implementation file. This is merely a consequence of using the Python module system. An illustration of the module structure can be seen in Fig. \ref{fig:modulestructure}.

\begin{figure}[H]
    \centering
    \includegraphics{implementation/figures/folderstructure}
    \caption{The folder structure for three analyses provided by the user.}
    \label{fig:modulestructure}
\end{figure}

\newpar An analysis provided by the user must expose an instance of an \texttt{Analysis} class. This class requires a list of transfer functions, variables and expressions to be provided for instantiation. The analyzer extracts this instance and applies the transfer functions for each provided \texttt{Analysis} to the input file. The result of applying an analysis results in a transformed input program, which is fed forward to the next provided \texttt{Analysis}. When all analyses have been run, the transformed input program is given as output to the user. An illustration of this can be seen in Fig. \ref{fig:programflow}.

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{implementation/figures/programflow}
    \caption{The program flow for analyzing a program with multiple provided analyses.}
    \label{fig:programflow}
\end{figure}

\newpar The implementation of this project, instructions for running the analyses and example input files are available on GitHub, at \href{https://github.com/andersfischernielsen/ASA-Analyzer/}{\texttt{https://github.com/andersfischernielsen/ASA-Analyzer/}}.

\newpar Only set-based analyses have been implemented at the time of writing and these are the only implementations supported by the dynamic loading of the framework, as described in the following section.