%%% This is the scribe notes template for CS611
%%% There are several comments preceded by CS611: and boxed in %%%%'s
%%% which indicate where macros should be altered to set up the header
%%% for the paper.  Your Notes should go at the comment SCRIBE NOTES GO HERE!.

%%% In the various .sty files that accompany this .tex file you will
%%% find LaTeX macros that make it easier to typeset inference rules
%%% and programming language constructs.  You must make sure that the
%%% file proof.sty is in a path searched by LaTeX when you try to
%%% use this file.  Take a look to see what macros are available--it
%%% will save you time and make the notes look better.  Feel free to
%%% extend the set of macros--post them to the newsgroup and contact
%%% the course staff if you come up with some good ones so they can be
%%% added to the template.

%%% This template includes examples of how to use some of the macros
%%% to give you an idea of how they work.  (Delete the examples when
%%% you do your scribing.)

\documentclass{article} \usepackage{611-lecture}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% CS611: Please fill in these macros as appropriate:
\lecture{25}                  %% Lecture number
\title{Products, sums, and more}   %% Title of lecture
\author{David Crandall, Lukas Kroc}       %% name of scribe
\date{28 October, 2005}     %% Date of lecture, e.g., 1 January 2001
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% See 611.sty for a variety of macros that will be helpful in
% typesetting the lecture. Here are a few of particular interest:
%
% "x"       x in keyword font (e.g., "if", "#t")
% _x_       x in italics
% \nm{n}    n in slanted font (used for abbreviations)
% <e>       e in angle brackets
% \lt       less-than sign
% \gt       greater-than sign
% \SB{x}    x in semantic brackets
% \Tr x{y}  x[[y]] with x in calligraphic font
%           (if x is more than a single character, use \Tr{x}{y})

\newcommand{\LET}{\impfnt{let}}
\newcommand{\IN}{\impfnt{in}}
\newcommand{\implies}{\Rightarrow}
%LK: I think language keywords like inL and inR should be in "" (they have a special definition of "" for 611), but I don't know how to do that
\newcommand{\inL}{\mbox{ inL }}
\newcommand{\inR}{\mbox{ inR }}
\newcommand{\CASE}{\, \impfnt{case} \,}
\newcommand{\OF}{\, \impfnt{of} \,}
\newcommand{\REC}{\, \impfnt{rec} \,}
\newcommand{\FIX}{\, \mbox{fix} \,}

\renewcommand{\IF}{\, \impfnt{if} \,}
\renewcommand{\THEN}{\, \impfnt{then} \,}
\renewcommand{\ELSE}{\, \impfnt{else} \,}
\renewcommand{\LET}{\, \impfnt{let} \,}
\renewcommand{\IN}{\, \impfnt{in} \,}


\begin{document}

\maketitle

In this lecture, we add constructs to the typed $\lambda$-calculus that
allow working with more complicated data structures, such as pairs,
tuples, records, sums and recursive functions. We also provide
denotational semantics for these new constructs.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Simple data structures}
Each data structure can be added by extending the syntax of
expressions ($e$), types ($\tau$) and values ($v$). The evaluation
contexts ($E$) will also need to be extended, and evaluation 
and type derivation rules added to work with the new syntax. In this
section, we will only show additions and changes to the typed
$\lambda$-calculus syntax and rules introduced in the previous
lecture.

\subsection{Pairs}
Syntax:
\begin{eqnarray*}
    e &::=& \cdots \bnf (e_1, e_2) \bnf "\#1"e \bnf "\#2"e \\
    \tau &::=& \cdots \bnf \tau_1 * \tau_2 \\
    v &::=& \cdots \bnf (v_1, v_2) \\
    E & ::=& \cdots \bnf ([.],e) \bnf (v,[.]) \bnf "\#1"[.] \bnf
    "\#2"[.] \\
\end{eqnarray*}

For every added syntactic form, we observe that we have expressions
that {\em introduce} the form, and expressions that {\em eliminate}
the form. In the case of pairs, the introduction expression is
$(e_1,e_2)$, and the elimination expressions are $\#1e$ and $\#2e$.

Evaluation rules\footnote{Note that these rules define {\em eager}
evaluation, because we only select from a pair when both elements
are evaluated to a value.}:
\[ \Rule{}{"\#1"(v_1,v_2) \stepsone v_1}
\qquad \Rule{}{"\#2"(v_1,v_2) \stepsone v_2} \]

Typing rules:
\[ \Rule{\Gamma \proves e_1:\tau_1 \quad \Gamma \proves
e_2:\tau_2}{\Gamma\proves (e_1,e_2):\tau_1*\tau_2} \qquad
\Rule{\Gamma\proves e:\tau_1*\tau_2}{\Gamma\proves "\#1"e:\tau_1}
\qquad \Rule{\Gamma\proves e:\tau_1*\tau_2}{\Gamma\proves
"\#2"e:\tau_2}\]


\subsection{Tuples}
Syntax:
\begin{eqnarray*}
    e &::=& \cdots \bnf (e_1,\ldots, e_n) \bnf "\#n"e \\
    \tau &::=& \cdots \bnf \tau_1 *\ldots *\tau_n \\
    v &::=& \cdots \bnf (v_1,\ldots, v_n) \\
    E & ::=& \cdots \bnf (v_1,\ldots,v_{i-1},[.],e_{i+1},\ldots,e_n) \bnf "\#n"[.] \\
\end{eqnarray*}

Evaluation rule:
\[ \Rule{}{"\#m"(v_1,\ldots,v_n) \stepsone v_m}
\sidecond{$1\le m \le n$}\]

Type derivation rules:
\[ \Rule{\Gamma \proves e_i:\tau_i \quad i \in \{1,\ldots,n\}}
{\Gamma\proves (e_1,\ldots,e_n):\tau_1*\ldots*\tau_n} \qquad
\Rule{\Gamma\proves e:\tau_1*\ldots*\tau_n}{\Gamma\proves
"\#m"e:\tau_m} \sidecond{1$\le$ m $\le$ n} \]


\subsection{Records}
Syntax:
\begin{eqnarray*}
    e &::=& \cdots \bnf \{x_1=e_1,\ldots, x_n=e_n\} \bnf e.x \\
    \tau &::=& \cdots \bnf \{x_1:\tau_1, \ldots, x_n:\tau_n\} \\
    v &::=& \cdots \bnf \{x_1=v_1,\ldots, x_n=v_n\} \\
    E & ::=& \cdots \bnf \{x_1=v_1,\ldots,x_{i-1}=v_{i-1},[.],
    x_{i+1}=e_{i+1},\ldots,x_n=e_n) \bnf [.].x \\
\end{eqnarray*}

Evaluation rule:
\[ \Rule{}{\{x_1=v_1,\ldots,x_n=v_n).x_i \stepsone v_i}
\sidecond{1$\le$ i $\le$ n}\]

Type derivation rules:
\[ \Rule{\Gamma \proves e_i:\tau_i \quad i \in \{1,\ldots,n\}}
{\Gamma\proves \{x_1=e_1,\ldots,x_n=e_n):\{x_1:\tau_1, \ldots,
x_n:\tau_n\}} \qquad \Rule{\Gamma\proves e:\{x_1:\tau_1, \ldots,
x_n:\tau_n\}}{\Gamma\proves e.x_i:\tau_i} \sidecond{1$\le$ i $\le$
n}
\]


\subsection{Sums}
Sums are useful for representing datatypes that can have multiple
forms. For example, a tail of a list can either be another non-empty
list, or null.

Syntax:
\begin{eqnarray*}
    e &::=& \cdots \bnf \inL_{\tau_1+\tau_2} e \bnf \inR_{\tau_1+\tau_2} e
        \bnf "case"~e_0~"of"~e_1|e_2 \\
    \tau &::=& \cdots \bnf \tau_1+\tau_2 \\
    v &::=& \cdots \bnf \inL_{\tau_1+\tau_2} v \bnf \inR_{\tau_1+\tau_2}
    v\\
    E & ::=& \cdots \bnf \inL[.] \bnf \inR[.] \bnf "case"~[.]~"of"~e_1|e_2 \\
\end{eqnarray*}
The \inL construct is called {\em left injection}, and \inR is {\em
right injection}.

Evaluation rules:
\[ \Rule{}{"case"~\inL_{\tau_1+\tau_2}v~"of"~e_1|e_2  \stepsone e_1~v}
\qquad \Rule{}{"case"~\inR_{\tau_1+\tau_2}v~"of"~e_1|e_2  \stepsone
e_2~v}
\]
In the evaluation rules above, $e_1$ and $e_2$ are functions, and
must have the same codomain type in order for the whole "case"
expression to have a type.

Type derivation rules:
\[ \Rule{\Gamma \proves e:\tau_1}{\Gamma\proves
\inL_{\tau_1+\tau_2}e:\tau_1+\tau_2} \qquad \Rule{\Gamma \proves
e:\tau_2}{\Gamma\proves \inR_{\tau_1+\tau_2}e:\tau_1+\tau_2} \qquad
\Rule{\Gamma\proves e_0:\tau_1+\tau_2 \quad \Gamma\proves
e_1:\tau_1\to\tau_3 \quad \Gamma\proves
e_2:\tau_2\to\tau_3}{\Gamma\proves "case"~e_0~"of"~e_1|e_2:\tau_3}
\]

To give an example of the sum type, consider a type 1+1 (sum of two
unit types). This type has exactly two elements: \inL("null") and
\inR("null"), and thus is isomorphic to the "bool" type (with
elements "true" and "false"). The $"if"~b~"then"~e_1~"else"~e_2$
statement can be written as
$"case"~b~"of"~\lam{z}{e_1}|\lam{z}{e_2}$.

\paragraph{}
SML has a construct that is a generalization of the sum type:
\begin{eqnarray*}
    e &::=& \cdots \bnf x_i(e) \\
    \tau &::=& \cdots \bnf [x_1:\tau_1,\ldots,x_n:\tau_n] \\
\end{eqnarray*}
The SML syntax is then \verb+datatype t=x1 of t1 | ... | xn of tn+.
Such datatypes are also called _variants_. The \verb|xi| are
constructors, and must be globally (across all types) unique to
avoid confusion as to which type a particular constructor
is referring to (in our sum type, the confusion is alleviated by using
$\tau_1+\tau_2$ subscripts in \inL and \inR).


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Denotational semantics}

We now write the denotational semantics for type domains of
$\lambda^{\rightarrow + *}$, the strongly-typed lambda calculus
with sum and product types:

\[ \Tr{}{\tau \rightarrow \tau'} = \Tr{}{\tau} \rightarrow \Tr{}{\tau'} \]
\[ \Tr{}{\tau_1 * \tau_2} = \Tr{}{\tau_1} \times \Tr{}{\tau_2} \]
\[ \Tr{}{\tau_1 + \tau_2} = \Tr{}{\tau_1} + \Tr{}{\tau_2} \]

\noindent Our ``contract'' for this language is that the following
statement holds:

\[ \rho \models \Gamma \implies \Tr{}{\Gamma \vdash e : \tau} \rho \in
\Tr{}{\tau}\]

\noindent Then the remaining typing rules are:


\[ \Tr{}{\Gamma \vdash (e_1, e_2) : \tau_1 * \tau_2} \rho =
<\Tr{}{\Gamma \vdash e_1 : \tau_1} \rho, \Tr{}{\Gamma \vdash e_2 :
\tau_2} \rho> \in \Tr{}{\tau_1 * \tau_2}\]
\[ \Tr{}{\Gamma \vdash \# 1 e : \tau_1} \rho = \pi_1\left(
   \Tr{}{\Gamma \vdash e : \tau_1 * \tau_2} \rho \right) \in \Tr{}{\tau_1}\]
\[ \Tr{}{\Gamma \vdash \# 2 e : \tau_1} \rho = \pi_2\left(
   \Tr{}{\Gamma \vdash e : \tau_1 * \tau_2} \rho \right) \in \Tr{}{\tau_2}\]

\noindent where $\pi_n$ is a (mathematical) projection operator that
selects the $n$-th element of a pair.

\[ \Tr{}{\Gamma \vdash \inL_{\tau_1 + \tau_2} e} \rho =
  \mbox{in}_1(\Tr{}{\Gamma \vdash e: \tau_1} \rho) \in
  \Tr{}{\tau_1} + \Tr{}{\tau_2} \]
\[ \Tr{}{\Gamma \vdash \inR_{\tau_1 + \tau_2} e} \rho =
  \mbox{in}_2(\Tr{}{\Gamma \vdash e: \tau_2} \rho) \in
  \Tr{}{\tau_1} + \Tr{}{\tau_2} \]
\begin{eqnarray*}
 \Tr{}{\Gamma \vdash \CASE e_0 \OF e_1 | e_2 : \tau_3} \rho & =
   & (\CASE \Tr{}{\Gamma \vdash e_0: \tau_1 + \tau_2} \rho
   \\ && \OF x_1.(\Tr{}{\Gamma \vdash e_1: \tau_1 \rightarrow \tau_3} \rho) x_1
   \\ && | \, x_2.(\Tr{}{\Gamma \vdash e_2: \tau_2 \rightarrow \tau_3} \rho) x_2 ) \in \tau_3
\end{eqnarray*}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Adding nontermination}

So far this language is obviously not Turing-complete because there
is no possibility of non-termination. There are several possible
ways to add non-termination to the language, including adding
recursive types or a reference mechanism. The easiest way, however,
is to add support for recursive functions.

To do this, we first extend the definition of an expression:

\[ e ::= ... | \REC y:\tau\rightarrow\tau'.\lam{x:\tau}{e_1} \]

\noindent The new keyword $\REC$ defines a recursive function named
$y$, such that both $x$ and $y$ are in scope inside $e_1$. For
example, we would write the following recursive function:

\[ f(x) = \IF x \gt 0 \THEN 1 \ELSE f(x + 1) \]

\noindent as:

\[ \REC \mbox{foo}: \INT \rightarrow \INT. \lam{x}{\IF x \gt 0 \THEN 1
   \ELSE \mbox{foo}(x+1)} \]

The small-step operational semantics evaluation rule for $\REC$ is:

\[ \infer{\REC y: \tau \rightarrow \tau'. \lam{x}{e} \longrightarrow
   \lam{x:\tau}{e \{ (\REC y.\lam{x}{e})/y \}}}{} \]

\noindent and the typing rule for $\REC$ is:

\[ \infer{\Gamma \vdash \REC y : \tau \rightarrow \tau'.\lam{x}{e} :
          \tau \rightarrow \tau'}{\Gamma, y: \tau \rightarrow \tau',
          x:\tau \vdash e : \tau'} \]

The denotational semantics are:

\[ \FIX \lam{f \in \Tr{}{\tau \rightarrow \tau'}}{
            {\Tr{}{\Gamma \vdash \REC y:\tau \rightarrow \tau'.\lam{x}{e}:
  \tau \rightarrow \tau'}} \rho =
\lam{z \in \Tr{}{\tau}}{\Tr{}{\Gamma, y: \tau \rightarrow \tau',
x:\tau
  \vdash e}} (\rho [x \mapsto z, y \mapsto f])} \]

Of course, whenever we take a fixed point, we have to make sure that
a fixed point exists. We know that the function satisfies continuity
and monotonicity because we're writing in the metalanguage. However,
for a fixed point to exist, $\Tr{}{\tau \rightarrow \tau'}$  must be
a pointed CPO. But for this to be true, we have to add $\bot$ to the
codomain of the function:

\[ \Tr{}{\tau \rightarrow \tau'} = \Tr{}{\tau} \rightarrow \Tr{}{\tau'}_{\bot} \]

\noindent where $\Tr{}{\tau'}_{\bot}$ is just a shorthand notation
for the set $\Tr{}{\tau'} \cup \{\bot\}$. We also have to change our
contract to account for the possibility of non-termination:

\[ \rho \models \Gamma \implies \Tr{}{\Gamma \vdash e : \tau} \rho \in
\Tr{}{\tau}_{\bot}\]

And add an additional rule:

\[ \Tr{}{\tau \rightarrow \tau'} =
\Tr{}{\tau} \rightarrow \Tr{}{\tau'}_{\bot} \]

Finally, we have to ``lift'' our semantics to take non-termination
into account. We can do this by using the \LET construct of the
metalanguage. For example, the rule for pairs must be changed to:

\begin{eqnarray*}
 \Tr{}{\Gamma \vdash (e_1, e_2) : \tau_1 * \tau_2} \rho & = &
\lfloor <\Tr{}{\Gamma \vdash e_1 : \tau_1} \rho,
\Tr{}{\Gamma \vdash e_2 : \tau_2} \rho> \rfloor \\
& = &
\LET v_1 =  \Tr{}{\Gamma \vdash e_1 : \tau_1} \rho \IN \\
& & \,\,\,\,\,\, \LET v_2 = \Tr{}{\Gamma \vdash e_2 : \tau_2} \rho \IN \\
& & \,\,\,\,\,\,\,\,\,\,\,\, <v_1, v_2> \\
\end{eqnarray*}

\end{document}
