\input{preamble}

\title{Resource Analysis: Problem Set 7}% \\ Type Inference and Unification}
\setcounter{section}{7}

\begin{document}
\maketitle

\begin{center}
  \noindent
  \large{Due before 1:30pm on Monday, March 28}
\end{center}

\subsection{(15 Points) Functional Queue Revisited}

In this problem we are interested in the number of cons operations. We
use a metric $M$ with $\cCons = 1$ and $M^K = 0$ for all $K \neq \text{cons}$.

\begin{enumerate}[a)]
\item Consider the function \code{rev\_append} below.
\begin{lstlisting}
let rec rev_append (l1,l2) =
  match l1 with
  | [] -> l2
  | x::xs -> rev_append (xs, x::l2)
\end{lstlisting}
  Give a type derivation using the type system for linear amortized
  analysis that is defined in \pref{fig:trulesLin}.
\item Give a concise description of the set of all annotated function
  types that are derivable for the function \code{rev\_append}.
\item Now consider the following implementation of the functional
  queue from problem set.
\begin{lstlisting}
let rev l = rev_append (l,[])

let enqueue (queue, x) =
  match queue with
  | (inq,outq) ->
     (x::inq, outq)

let rec dequeue (inq,outq) =
  match outq with
  | [] ->
     begin
       match inq with
       | [] -> (([],[]),-1)
       | x::xs -> dequeue ([],rev inq)
     end
  | y::ys -> ((inq, ys), y)
\end{lstlisting}
  Give a derivable resource-annotated types for the functions
  \code{rev}, \code{enqueue}, and \code{dequeue}. (You don't have to
  provide the type derivation.)

\item Give resource-annotated type derivations for the functions $a$
  and $b$ below.
\begin{lstlisting}
let a =
  let qu = ([],[]) in
  let qu = enqueue (qu, 1) in
  let qu = enqueue (qu, 2) in
  let qu = enqueue (qu, 3) in
  dequeue qu

let b = 
  let qu = ([],[]) in
  let qu = enqueue (qu, 1) in
  let qu = enqueue (qu, 2) in
  let qu = enqueue (qu, 3) in
  let _ = dequeue qu in
  dequeue qu
\end{lstlisting}
\end{enumerate}

\subsection{(33 Points) Typeable Functions}

Consider the following first-order functions. As earlier, we use
\emph{tick} functions to define the resource usage. That means that we
use a resource metric that defines cost $q$
for operation \code{Raml.tick q} and cost $0$
for all other operations.

\begin{lstlisting}
let rec insert (x,l) =
  let _ = Raml.tick 1.0 in
  match l with
  | [] -> [x]
  | y::ys ->
     if (y:int) <= x then y::insert (x,ys)
     else x::y::ys
		  
let rec isort l =
  let _ = Raml.tick 1.0 in  
  match l with
  | [] -> []
  | x::xs -> insert (x, isort xs)

let rec omega x = omega x
			
let rec repeat (x,l) =
  let _ = Raml.tick 1.0 in    
  match l with
  | [] -> []
  | y::ys -> x::(repeat (x,ys))

let rec append (l1,l2) =
  let _ = Raml.tick 1.0 in      
  match l1 with
  | [] ->  let _ = Raml.tick (-1.0) in l2
  | x::xs -> let res = x::append (xs,l2) in
	     let _ = Raml.tick (-1.0) in res

let rec append_all l =
  let _ = Raml.tick 1.0 in      
  match l with
  | [] -> []
  | x::xs -> append (x, append_all xs)

let f1 l = repeat (l, append_all l)

let f2 l = if true then l else isort l

let f3 l = let l' = omega l in
	   isort l'

let f4 l = let l' = append_all l in
	   isort l'

let f5 l = append (append (l,[]), l)
\end{lstlisting}

\begin{enumerate}[a)]
\item Manually derive an upper bound on the number of ticks that are executed by each of these functions.
\item Determine if you can derive an upper bound on the number of
  ticks for each function using the type system for linear amortized
  analysis that is defined in \pref{fig:trulesLin}. If you are able to
  derive a bound then provide the annotated type of the respective
  functions and all functions that are used in the type derivation. If
  you are not able to derive a bound with the type rules then explain
  with a couple of sentences why the program is not typeable.
\end{enumerate}


\subsection{(18 Points) Sum Types and Amortized Analysis}

I this problem, we will extend our linear amortized analysis by adding
sum types $T_1 + T_2$
to our language. To this end we define data types as.
$$
\begin{array}{lllll}
T & ::= & X \mid \liT{T} \mid \cdots \mid T_1 + T_2
\end{array}
$$

The syntax is extended as follows:

$$
\begin{array}{llll}
   e &::=& x \\
  && \appS{f}{x}\\
  && \matchLS{x}{ e_1}{x_1}{x_2}{ e_2} \\
  && $\ldots$ \\
  && \text{inl}(x) \\
  && \text{inr}(x)\\
  && \text{matchS}(x,x_1.e_1,x_2.e_2)
\end{array}
$$
We add the following type rules to the affine type system for base types.

\begin{mathpar}
  \Rule{T:InL}
    { 
    } 
    {x:T_1 \tlin \text{inl}(x) : T_1 + T_2
    }

  \Rule{T:InR}
    { 
    } 
    {x:T_2 \tlin \text{inr}(x) : T_1 + T_2
    }

  \Rule{T:MatSL}
    { \Gamma,x_1:T_1 \tlin e_1 : T
    \\ \Gamma,x_2:T_2 \tlin e_2 : T
    }
    {\Gamma,x:T_1+T_2 \tlin \text{matchS}(x,x_1.e_1,x_2.e_2) : T
    }
\end{mathpar}


Values are defined as follows.
$$
v ::= \ell \mid (\ell_1,\ell_2) \mid \trueS \mid \falseS \mid \text{inl}(\ell) \mid \text{inr}(\ell)
$$
%
Finally, we add the following evaluation rules to big-step semantics.
%

\begin{mathpar}
  \Rule{Ee:InL}
    { \heap' = \heap, \ell {\mapsto} \text{inl}(\env(x))
    } 
    {\env; \heap \vdash \text{inl}(x) \bigse{(\ell,\heap')}{M^\text{inl}}
    }

  \Rule{Ee:InR}
    { \heap' = \heap, \ell {\mapsto} \text{inr}(\env(x))
    } 
    {\env; \heap \vdash \text{inr}(x) \bigse{(\ell,\heap')}{M^\text{inr}}
    }

  \Rule{Ee:MatSL1}
    {  \env(x) = \text{inl}(\ell)
    \\ \env[x_1 {\mapsto} \ell]; \heap \vdash e_1 \bigse{(\ell',\heap')}{(q_1,q_2)}
    }
    {\env; \heap \vdash \text{matchS}(x,x_1.e_1,x_2.e_2) \bigse{(\ell',\heap')}{M^\text{matS}{\cdot}(q_1,q_2)}
    }

  \Rule{Ee:MatSL2}
    {  \env(x) = \text{inr}(\ell)
    \\ \env[x_2 {\mapsto} \ell]; \heap \vdash e_2 \bigse{(\ell',\heap')}{(q_1,q_2)}
    }
    {\env; \heap \vdash \text{matchS}(x,x_1.e_1,x_2.e_2) \bigse{(\ell',\heap')}{M^\text{matS}{\cdot}(q_1,q_2)}
    }

\end{mathpar}

\begin{enumerate}[a)]
\item Extend the definitions of linear annotated types and the
  definition of potential functions to sum types $T_1 + T_2$.
\item Define linear resource-annotated type rules for the new syntactic forms for sum types.
\item Show that your rules are sound with respect to the big step
  semantics. Remember that the soundness theorem of amortized analysis
  is proved by a nested induction on the evaluation judgement and the
  type derivation. Consider the cases in which the derivation type
  judgement ends with one of the new type rules for sum types.
\end{enumerate}


\include{linear_types}

\end{document}

%%% Local Variables:
%%% mode: latex
%%% mode: flyspell
%%% TeX-master: t
%%% End: