%%% 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}
\usepackage{amsmath,amssymb,amsthm,amsfonts,comment,url}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% CS611: Please fill in these macros as appropriate:
\lecture{32} %% Lecture number
\title{Recursive Types}   %% Title of lecture
%\author{Asif-ul Haque, Xin Zheng}  %% name of scribe
\date{22 November 2006}    %% Date of lecture
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% See 611.sty for a variety of macros that will be helpful in
% typesetting the lecture
%
% quotes can be used for typewriter font
% <> can be used for angle brackets

\renewcommand\emptyset\varnothing
\newcommand{\inL}{\ensuremath{\mathsf{inL}}}
\newcommand{\inR}{\ensuremath{\mathsf{inR}}}
\newcommand\caseof[3]{\mathsf{case}~{#1}~\mathsf{of}~{#2}~|~{#3}}

\newtheorem{theorem}{Theorem}
\newtheorem{lemma}[theorem]{Lemma}
\newtheorem{proposition}[theorem]{Proposition}
\newtheorem{corollary}[theorem]{Corollary}
\newtheorem{definition}[theorem]{Definition}

\newcommand{\Z}{\mathbb{Z}}
\newcommand{\group}[1]{\left\langle{#1}\right\rangle}

%\theoremstyle{definition}
%\newtheorem*{defn}{Definition}
\newcommand{\nondet}{\left[\!\kern1pt\right]}
\renewcommand\phi\varphi
\renewcommand\wp[2]{\mathsf{wp}~{#1}~{#2}}
\newcommand\wlp[2]{\mathsf{wlp}~{#1}~{#2}}
\renewcommand\({\begin{eqnarray*}}
\renewcommand\){\end{eqnarray*}}

\newcommand\LOOKUP[2]{\mathrm{LOOKUP}~{#1}~{#2}}
\newcommand\UPDATE[3]{\mathrm{UPDATE}~{#1}~{#2}~{#3}}
\newcommand\MALLOC[2]{\mathrm{MALLOC}~{#1}~{#2}}
\newcommand\EMPTY{\mathrm{EMPTY\mbox{-}STORE}}
\renewcommand\dom[1]{\mathrm{dom}\,{#1}}
\newcommand\p[2]{\langle{#1},\,{#2}\rangle}
\newcommand\bigcdot{\mathrel{\raisebox{1pt}{$\scriptscriptstyle\bullet$}}}
\newcommand\holed[1]{[\,#1\,]}
\newcommand\hole{\holed\bigcdot}
\newcommand\context[1]{E\kern1pt\holed{#1}}
\newcommand\contextHole{\context\bigcdot}
\newcommand\goesto[2]{\underset{#2}{\overset{#1}\to}}
\newcommand\ifthenelse[3]{\mathsf{if\ }#1\mathsf{\ then\ }#2\mathsf{\ else\ }#3}
\newcommand\ifpthenelse[3]{\mathsf{ifp\ }#1\mathsf{\ then\ }#2\mathsf{\ else\ }#3}
\newcommand\whiledo[2]{\mathsf{while\ }#1\mathsf{\ do\ }#2}
\newcommand\letin[3]{\mathsf{let\ }#1 = #2\mathsf{\ in\ }#3}
\newcommand\letrec[5]{\mathsf{letrec\ }#1 = #2\mathsf{\ and\ \ldots\ and\ }#3 = #4\mathsf{\ in\ }#5}
\newcommand\letrecone[3]{\mathsf{letrec\ }#1 = #2\mathsf{\ in\ }#3}
\newcommand\true{\ensuremath{\mathsf{true}}}
\newcommand\false{\ensuremath{\mathsf{false}}}
\newcommand\error{\ensuremath{\mathsf{error}}}
\newcommand\pca[3]{\{#1\}\kern1pt{#2}\kern1pt\{#3\}}
\newcommand\states{\Set{St}}
\newcommand\rtc{^{\textstyle *}}
\newcommand\sat\vDash
\newcommand\force\vdash

\newcommand\hyphen{\mbox{-}}
\newcommand\lookup[2]{\nm{LOOKUP}~#1~\mquote{#2}}
\newcommand\update[3]{\nm{UPDATE}~#1~\mquote{#2}~#3}
\newcommand\SBk[1]{\SB{#1}k}
\newcommand\fix[1]{\mathsf{fix}\,{#1}}

\newlength\reasonwidth
\setlength\reasonwidth{3cm}
\newcommand\reasoning[1]{\def\longest{#1}\settowidth{\reasonwidth}{$\displaystyle\longest$}\addtolength{\reasonwidth}{5mm}}
\newcommand\reason[2]{\makebox[\reasonwidth][l]{$\displaystyle{#1}$}\mbox{#2}}

\renewcommand\inj[1]{\mathsf{in}_{#1}}
\newcommand\proj[1]{\pi_{#1}}
\newcommand{\dlt}{\sqsubseteq}
\newcommand\floor[1]{\lfloor{#1}\rfloor}
\newcommand\cf[1]{[\kern1pt{#1}\kern1pt]}
\newcommand\SBpr[1]{\SB{#1}\,\phi\,\rho}
\renewcommand\C[3]{\Tr C{#1}\kern1pt{#2}\kern1pt{#3}}
\renewcommand\Cr[1]{\C{#1}\Gamma\rho}

\newcommand\judge[3]{{#1}\force{#2}:{#3}}
\newcommand\Gjudge[2]{\judge\Gamma{#1}{#2}}%
\newcommand\forceUSN{\mathrel{\makebox[2pt][l]{$\force$}\raisebox{-3pt}[0pt][0pt]{\tiny{\textit{USN}}}}}
\newcommand\judgeUSN[3]{{#1}\forceUSN{#2}:{#3}}
\renewcommand\C[3]{\Tr C{#1}\kern1pt{#2}\kern1pt{#3}}
\renewcommand\Cr[1]{\C{#1}\Gamma\rho}
\newcommand\Irred[1]{\ensuremath{\mathrm{Irred}(#1)}}

\newcommand\seq[3]{#1_{#2},\ldots,#1_{#3}}
\newcommand\substtwo[5]{\subst{#1}{#2}{#3,\,#4/#5}}
\newcommand\substlist[5]{\subst{#1}{#2}{#3,\ldots,#4/#5}}
\newcommand\Unify[1]{\mathrm{Unify}(#1)}
\newcommand\fa[2]{\forall{#1}\kern1pt.\kern1pt{#2}}%
\newcommand\Judge[4]{\judge{#1;\,#2}{#3}{#4}}
\renewcommand\infer[2]{\ensuremath{\dfrac{#2}{#1}}}%

\newenvironment{proofof}[1]{\addtolength{\topsep}{1mm}\begin{trivlist}\item[]\hspace{\parindent}{\em Proof of #1.}}{\qed\end{trivlist}}

\newcommand\lamcal{$\lambda$-calculus}
\newcommand\mut[2]{\mu#1.\,#2}

\begin{document}
\maketitle

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% CS611: SCRIBE NOTES GO HERE!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Introduction}

Many programming languages have the ability to define recursive data types. For example, suppose we want to define binary trees with integer data at the nodes.  In Java we can write
\begin{flushleft}
\begin{tabular}l
"class Tree" \{\\
\phantom{dd}"Tree leftChild, rightChild;"\\
\phantom{dd}"int data;"\\
\}
\end{tabular}
\end{flushleft}
A binary tree is an object of this class.  In ML we can write
\begin{flushleft}
\begin{tabular}l
"datatype tree = Leaf $\mid$ Node of tree * tree * int"
\end{tabular}
\end{flushleft}
These types are _recursive_ because they are defined in terms of themselves.

In the typed \lamcal, we do not yet have any mechanism to define recursive types.  We would like the type "tree" to satisfy
\begin{align}
"tree" &= "1 + tree * tree * int",\label{eqn:rec0}
\end{align}
where "1" (aka "unit") represents the empty tree; in other words, we would like "tree" to be a solution of the equation
\begin{align}
\alpha &= "1 + \alpha * \alpha * int".\label{eqn:rec1}
\end{align}
However, no such solution exists among the types we have seen so far.

How might we augment our set of types to include solutions to recursive type equations such as \eqref{eqn:rec1}?  There are two basic approaches, called the _equirecursive_ and _isorecursive_ approach, respectively.

\section{Recursive Types as Regular Labeled Trees---The Equirecursive View}

By unwinding \eqref{eqn:rec1}, we can see that
\(
\alpha &=& "1" + \alpha * \alpha * "int"\\
&=& "1" + ("1" + \alpha * \alpha * "int") * ("1" + \alpha * \alpha * "int") * "int"\\
&=& "1" + ("1" + ("1" + \alpha * \alpha * "int") * ("1" + \alpha * \alpha * "int") * "int") * ("1" + ("1" + \alpha * \alpha * "int") * ("1" + \alpha * \alpha * "int") * "int") * "int"\\
&=& \cdots
\)
At each level, we have a finite type with the type variable $\alpha$ appearing at some of the leaves, and we obtain the next level by substituting the right-hand side of \eqref{eqn:rec1} for $\alpha$.  This gives a sequence of deeper and deeper finite trees, where each successive tree is a substitution instance of the previous tree.

If we take the limit of this process, we have an infinite tree.  We can think of this as an infinite labeled graph whose nodes are labeled with the type constructors *, +, "int", and "1".  This is very much like an ordinary type expression, except that it is infinite.  There are no more $\alpha$'s, because we have substituted for all of them all the way down.  This infinite tree is a solution of \eqref{eqn:rec1}, and this is what we take as the type "tree".

In general, let $\Sigma$ be a signature consisting of several type constructors of various arities.  For example, $\Sigma$ might consist of the type constructors $\to$, "*", "+", "1", and "int".  We can form the set of (finite) types over $\Sigma$ inductively in the usual way.  Each such type can be regarded as a finite labeled tree.  For example, the type $"int" \to  "int" \to "int"$ can be viewed as the labeled tree
\begin{center}
\begin{picture}(0,40)(10,0)
\multiput(0,0)(-20,20)2{\makebox(0,0){"int"}}
\put(40,0){\makebox(0,0){"int"}}
\multiput(20,20)(-20,20)2{\makebox(0,0){$\to$}}
\multiput(36,4)(-20,20)2{\line(-1,1){13}}
\multiput(4,4)(-20,20)2{\line(1,1){13}}
\end{picture}
\end{center}

Now let us add some infinite types.  These are infinite labeled trees that respect the arities of the constructors in $\Sigma$; that is, if the constructor is binary (such as "*" or $\to$), any node labeled with that constructor must have exactly two children; and if the constructor is nullary, such at "1", then any node labeled with that symbol must be a leaf.  Within these constraints, the tree may be infinite.

A (finite or infinite) expression with only finitely many subexpressions up to isomorphism is called _regular_.  For example, the infinite type
\begin{center}
\begin{picture}(0,60)(10,-5)
\multiput(0,0)(-20,20)3{\makebox(0,0){"int"}}
\put(44,0){\makebox(0,0){$\ddots$}}
\multiput(20,20)(-20,20)3{\makebox(0,0){$\to$}}
\multiput(36,4)(-20,20)3{\line(-1,1){13}}
\multiput(4,4)(-20,20)3{\line(1,1){13}}
\end{picture}
\end{center}
is regular, since it has only two subexpressions up to isomorphism, namely itself and "int".  The limit of the unwinding of \eqref{eqn:rec1} above, which we took to be the type "tree", is also regular; it has exactly five subexpressions up to isomorphism, namely "tree", "1", "tree * tree * int", "tree * tree", and "int".

Regular trees are all we need to provide solutions to finite systems of type equations of the form \eqref{eqn:rec1}.  Suppose we have $n$ type equations in $n$ variables:
\begin{align}
\alpha_1 &= \tau_1\nonumber\\
& \vdots\label{eqn:rec3}\\
\alpha_n &= \tau_n,\nonumber
\end{align}
where each $\tau_i$ is a finite type over the type constructors $\Sigma$ and type variables $\seq\alpha 1n$.  This system has a solution $\seq\sigma 1n$ in which each $\sigma_i$ is a regular tree.  Moreover, if no right-hand side is a variable, then the solution is unique.

\subsection{The $\mu$ Constructor}

We can specify the infinite solutions to systems of type equations \eqref{eqn:rec3} using a finite syntax involving a new type constructor $\mu$, the _fixpoint type constructor_. If we have an equation $\alpha = \tau$ such that the right-hand side is not $\alpha$, then there is a unique solution, which is a finite or infinite regular tree.  The solution will be infinite if $\alpha$ occurs in $\tau$ and will be finite (in fact it will just be $\tau$) if $\alpha$ does not occur in $\tau$.  We denote this unique solution by $\mut\alpha\tau$.

Syntactically, $\mu$ acts as a binding operator in type expressions as $\lambda$ does in $\lambda$-terms, with the same notions of scope, free and bound variables, $\alpha$-conversion, and safe substitution.

Since $\mut\alpha\tau$ is a solution to $\alpha=\tau$, we have
\begin{align}
\mut\alpha\tau &= \subst\tau{\mut\alpha\tau}\alpha.\label{eqn:rec2}
\end{align}

For example, to get a "tree" type satisfying \eqref{eqn:rec0}, we can define
\begin{align*}
"tree" &\definedas \mut\alpha{"1 + \alpha * \alpha * int"}.
\end{align*}
The desired equation \eqref{eqn:rec0} is just \eqref{eqn:rec2} for this case.

The solutions $\seq\sigma 1n$ to any finite system of the form \eqref{eqn:rec3} can be expressed in terms of $\mu$.  For example, suppose $\tau_1$ and $\tau_2$ are finite type expressions over the type variables $\alpha_1,\alpha_2$ such that neither $\tau_1$ nor $\tau_2$ is a variable.  The system
\begin{align*}
\alpha_1 &= \tau_1 & \alpha_2 &= \tau_2
\end{align*}
has a unique solution $\sigma_1,\sigma_2$ specified by
\begin{align*}
\sigma_1 &= \mut{\alpha_1}{(\subst{\tau_1}{\mut{\alpha_2}{\tau_2}}{\alpha_2})} &
\sigma_2 &= \mut{\alpha_2}{(\subst{\tau_2}{\mut{\alpha_1}{\tau_1}}{\alpha_1})}.
\end{align*}

Mutually recursive type declarations arise quite often in practice.  For example, consider the following Java class definitions for "Node" and "Edge":
\begin{flushleft}
\begin{tabular}l
"class Node" \{\\
\phantom{dd}"Edge[\,] inEdges, outEdges;"\\
\}\\[1em]
"class Edge" \{\\
\phantom{dd}"Node source, sink;"\\
\}
\end{tabular}
\end{flushleft}
Note that "Node" refers to "Edge" and vice versa.  So we must take a mutual fixpoint when assigning types.

\subsection{Typing Rules}

In the equirecursive view, since $\mut\alpha\tau=\subst\tau{\mut\alpha\tau}\alpha$, the typing rules are quite simple:
\[
\begin{array}{c@{\qquad\qquad}c}
\mbox{($\mu$-intro)} \quad \infer{\judge\Gamma e{\mut\alpha\tau}}{\judge\Gamma e{\subst\tau{\mut\alpha\tau}\alpha}}
&
\mbox{($\mu$-elim)} \quad \infer{\judge\Gamma e{\subst\tau{\mut\alpha\tau}\alpha}}{\judge\Gamma e{\mut\alpha\tau}}
\end{array}
\]
Equivalently, we can just allow substitution of equals for equals in type expressions.

\section{Folding and Unfolding---The Isorecursive View}

There is another approach to recursive types, the _isorecursive_ approach.  Here we do not have any infinite types, but rather the expression $\mut\alpha\tau$ is itself a type.  In this approach, $\mut\alpha\tau$ and $\subst\tau{\mut\alpha\tau}\alpha$ are considered different (but isomorphic) types.  

The step of substituting $\mut\alpha\tau$ for $\alpha$ in $\tau$ is called _unfolding_, and the reverse operation is called _folding_.  The conversion of elements between these two types is accomplished by explicit "fold" and "unfold" operations.
\(
"unfold"_{\mut\alpha\tau} &:& \mut\alpha\tau\ \ \to\ \ \subst\tau{\mut\alpha\tau}\alpha\\
"fold"_{\mut\alpha\tau} &:& \subst\tau{\mut\alpha\tau}\alpha\ \ \to\ \ \mut\alpha\tau
\)
(we suppress the subscripts when there is no ambiguity).  In this view, the equality symbol in \eqref{eqn:rec2} is not really an equality, but just an isomorphism.

\subsection{Typing Rules}

In the isorecursive view, the typing rules consist of a pair of introduction and elimination rules for $\mu$-types that explicitly mention "fold" and "unfold":
\[
\begin{array}{c@{\qquad\qquad}c}
\mbox{($\mu$-intro)} \quad \infer{\judge\Gamma{"fold"~e}{\mut\alpha\tau}}{\judge\Gamma e{\subst\tau{\mut\alpha\tau}\alpha}}
&
\mbox{($\mu$-elim)} \quad \infer{\judge\Gamma{"unfold"~e}{\subst\tau{\mut\alpha\tau}\alpha}}{\judge\Gamma e{\mut\alpha\tau}}
\end{array}
\]

\subsection{Structural Operational Semantics}

In the isorecursive view, we also need to augment the operational semantics.  We only need one rule:
\(
"unfold"~("fold"~e) &\to& e.
\)
Intuitively, to access data in a recursive type $\mut\alpha\tau$, we need to unfold it first; but the only way that values of type $\mut\alpha\tau$ could have been created in the first place is via a "fold".

\subsection{An Example}

Suppose we want to write a program to add a list of numbers. The list type is a recursive type, which we can define as
\(
"intlist" &\definedas& \mut\alpha{"1 + int * \alpha"}.
\)
The type "1" (aka "unit") represents the empty list.  It has a single inhabitant "null".  The other case is for a nonempty list consisting of a head, which is an "int", followed by the tail of the list, which is an "intlist"; that is, "int * intlist".

Now we can write a function "sum" to add up an "intlist". This will be a recursive function, so we will need to take a fixpoint.
\[
\letin{"sum"}{"rec"~f : "intlist" \arrow "int" .\, \lam{\ell : "intlist"}{\ldots}}{\ldots}
\]
In the body of this function, we would like to do a "case" on the "intlist" $\ell$.  But to do a "case", we need a sum type, and $\ell$ is a $\mu$-type, so we will have to unfold it first.  (ML does this automatically when it sees a "case".)  So the body would be
\[
\begin{array}l
"case"~"unfold"~\ell:"1 + int * intlist"~"of"\\
\phantom{dd|}\ \lam{u:"1"}0\\
\phantom{dd}|\ \lam{p:"int * intlist"}{(\#1~p) + f~(\#2~p)}
\end{array}
\]

This is just the same code that you would write in ML, except we have broken out some of the things that ML hides for you. In particular, we have explicitly shown the recursion in the definition of the "intlist" type and the "unfold" that is needed to get the exploded view of the type.

\section{Equirecursive vs.\ Isorecursive}

Programming languages deal with recursive types in different ways.  Java and Modula-3 take the equirecursive approach, in which the folded and unfolded types are considered equal, and the "fold"/"unfold" operations are just the identity functions.  Recursive types and their unfoldings are fully substitutable for each other.  
\begin{flushleft}
\begin{tabular}l
"class E" \{\\
\phantom{dd}"String x;"\\
\phantom{dd}"E e;"\\
\phantom{dd}"public String toString()" \{\\
\phantom{dddd}"return e.e.e.e.e.e.e.e.e.e.e.e.e.e.e.e.x;"\\
\phantom{dd}\}\\
\}
\end{tabular}
\end{flushleft}

On the other hand, ML, CLU, and C use isorecursive types, in which $\mut\alpha\tau$ and $\subst\tau{\mut\alpha\tau}\alpha$ are considered different (but isomorphic) types, and the casting operators "fold" and "unfold" are required to go between them.  CLU uses "up" and "down" instead of "fold" and "unfold".  In ML, the "unfold" operator is performed automatically and implicitly by the "case" and "let" statements and the pattern-matching mechanism.  The type constructors in a recursive datatype definition, when applied as functions, act as "fold" operations.
\begin{flushleft}
\begin{tabular}l
"- datatype tree = Leaf $\mid$ Node of tree * tree * int;"\\
"datatype tree = Leaf $\mid$ Node of tree * tree * int"\\
"- Node (Leaf,Leaf,4);"\hspace{2cm}($\leftarrow$ \textit{here we are applying "Node" and "Leaf" as functions})\\
"val it = Node (Leaf,Leaf,4) : tree"
\end{tabular}
\end{flushleft}

\section{Numbers as a Recursive Type}

We started with primitive types "1", "boolean", and "int".  We have already seen that the type "boolean" can be represented as "1 + 1" with values "false" and "true" represented by "inL null" and "inR null", respectively.

Now that we have recursive types, we no longer need to take "int" as primitive, but we can define it as a recursive type. A natural number is either $0$ or a successor of a natural number.  Thus we can take
\begin{align*}
"nat" &\definedas \mut\alpha{"1" + \alpha} &
"0" &\definedas "fold~(inL~null)" &
"1" &\definedas "fold~(inR~0)" &
"2" &\definedas "fold~(inR~1)",
\end{align*}
and so on.  Here $"fold" = "fold"_{"nat"}$, $"inL" = "inL"_{"1+nat"}$, and $"inR" = "inR"_{"1+nat"}$.

We can use the recursive type "nat" to code up all of the usual arithmetic, and all these operations are well-typed. For example, the successor function would be
\[
(\lam{x : "nat"}{"fold"~("inR"~x)}) : "nat \to nat".
\]

So all we really need as primitive types and type constructors are "1" ("unit"), recursive types, products, and sums.  With these we can build all the other types like natural numbers, integers, lists, trees, floating point numbers, and so on.

\section{Self-Application and $\Omega$}

Recall the _paradoxical combinator_ $\Omega$ defined by
\begin{align*}
\omega &\definedas \lam{x}{xx} &
\Omega &\definedas \omega~\omega.
\end{align*}
We can now give these terms recursive types, provided we insert some folding and unfolding.  Since $x$ is applied as a function, it must have some kind of function type, say $\sigma\to\tau$.  But since it is applied to itself as an argument, it must also have type $\sigma$.  This seems to indicate that the type of $x$ must satisfy the equation $\sigma=\sigma\to\tau$.  The recursive type $\mut\alpha{(\alpha\to\tau)}$ appears to be in order (here $\tau$ can be anything).

To actually apply $x$ to $x$, we have to unfold it.  The type of $"unfold"~x$ is
\(
"unfold"~x : (\mut\alpha{(\alpha\to\tau)}) &\to& \tau.
\)
This is a function with domain $\mut\alpha{(\alpha\to\tau)}$, which is the type of $x$, so we can apply it to $x$.  The type of the result $("unfold"~x)~x$ is $\tau$.  Thus the fully typed $\omega$ term is
\(
\omega &\definedas& (\lam{x : \mut\alpha{(\alpha\to\tau)}}{("unfold"~x)~x})\ :\ (\mut\alpha{(\alpha\to\tau)})\to\tau.
\)

If we now fold this, we get
\[
"fold"~\omega : \mut\alpha{(\alpha\to\tau)}.
\]
Therefore, we can apply $\omega$ as a function to $"fold"~\omega$, and the result is
\[
\omega~("fold"~\omega) : \tau.
\]
This is the same as the original $\Omega$ term, but with explicit folding and unfolding.

We can do this in ML:
\begin{flushleft}
\begin{tabular}l
"- datatype U = Fold of U $\to$ U";\\
"datatype U = Fold of U $\to$ U"\\
"- val omega = fn x $\Rightarrow$ case x of Fold f $\Rightarrow$ f x;"\\
"val omega = fn : U $\to$ U"\\
"- val Omega = omega (Fold omega);"\\[1em]
(\textit{and at this point it just sits there forever until you hit control-c})\\[1em]
"Interrupt"\\
"-"
\end{tabular}
\end{flushleft}
So we were finally able to introduce nontermination.  But the point is that it passed typechecking, so the program was well-typed.

\section{Untyped to Typed $\lambda$-Calculus}

In fact, with recursive types, we can type everything in the pure untyped \lamcal.  Every $\lambda$-term can be applied as a function to any other $\lambda$-term, so every $\lambda$-term (with appropriate folds and unfolds inserted) has type $U \definedas \mut\alpha{\alpha\to\alpha}$.  The translation is
\begin{align*}
\Tr Dx &\definedas x\\
\Tr D{e_0~e_1} &\definedas ("unfold"~\Tr D{e_0})~\Tr D{e_1}\\
\Tr D{\lam xe} &\definedas "fold"~\lam{x:U}{\Tr De}.
\end{align*}
Note that every untyped term maps to a term of type $U$.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}