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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% CS611: Please fill in these macros as appropriate:
\lecture{1}                  %% Lecture number
\title{Introduction}   %% Title of lecture
%\author{Ravikant Dintyala}       %% name of scribe
\lecturer{Dexter Kozen}
\date{25 August 2006}     %% 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})

\begin{document}

\maketitle

\section{Introduction}

What is a program?  Is it just something that tells the
computer what to do?  Yes, but there is much more to it than that.
The basic expressions in a program must be interpreted somehow,
and a program's behavior depends on how they are interpreted.  We must have
a good understanding of this interpretation, otherwise it would be
impossible to write programs that do what is intended.

It may seem like a straightforward task to specify what a program is supposed
to do when it executes.  After all, basic instructions are pretty simple.
But in fact this task is often quite subtle and difficult.  Programming
language features often interact in ways that are unexpected or hard to predict.
Ideally it would seem desirable to be able to determine the meaning of a program
completely by the program text, but that is not always true, as you well
know if you have ever tried to port a C program from one platform to another.
Even for languages that are nominally platform-independent, meaning is not
necessarily determined by program text.  For example, consider the following Java fragment.

\begin{flushleft}
\texttt{class A \{ static int a = B.b + 1; \}}\\
\texttt{class B \{ static int b = A.a + 1; \}}
\end{flushleft}

First of all, is this even legal Java?  Yes, although no sane programmer
would ever write it.  So what happens when the classes are initialized?
A reasonable educated guess might be that the program goes into an
infinite loop trying to initialize \texttt{A.a} and \texttt{B.b} from each other.  But no,
the initialization terminates with initial values for \texttt{A.a} and \texttt{B.b}.
So what are the initial values?  Try it and find out,
you may be surprised.  Can you explain what is going on?

This simple bit of pathology illustrates the difficulties that can arise
in describing the meaning of programs.  Luckily, for the most part, these
are the exception, not the rule.

Programs describe computation, but they are more than just lists of instructions.
They are mathematical objects as well, with properties and behavior that we can
attempt to described formally.  For most mathematical structures we encounter,
familiar mathematical tools like
sets and sequences are adequate to describe the properties of the structure.
In this course we will see some of the formal tools that have been developed
for describing precisely what programs are and what they do.

This course is mostly about the _semantics_ of programs and programming
languages.  ``Semantics'' is a synonym for ``meaning'' or ``interpretation''.
We want to be very precise about this notion, because it is necessary
for understanding the behavior of programs.  It is essential not only for
writing correct programs, but also for building tools like compilers,
optimizers, and interpreters.  Understanding the meaning of programs
allows us to ascertain whether these tools are implemented correctly.

There are three major components to this course.
\begin{itemize}
\item
Dynamic semantics.  We will study methods for describing and reasoning about
what happens when a program runs.
\item
Static semantics.  We will also study methods for reasoning about
programs _before_ they run.  Such methods include type checking, type
inference, and static analysis.  We would like to find errors in
programs as early as possible.  By doing so, we can often detect
errors that would otherwise show up only at runtime, perhaps after
significant damage has already been done.
\item
Language features.  We will apply methods for dynamic and static
semantics to study actual language features of interest, including
some interesting features that many students may have not seen before.
\end{itemize}

At the start, we will mostly be characterizing the semantics of a program as a function
that produces an output value(s) based on some input value(s). More generally, real programs
are reactive and interact with their inputs arriving from the
environment. Describing reactive programs is more challenging,
although we can view the reactive behavior of the program again as a
function of the inputs it receives from the environment as it runs.
Thus, to describe program semantics, we will build up some mathematical
tools for constructing and reasoning about functions.

\subsection{Binary Relations and Functions}

Denote by $A\times B$ the set of all ordered pairs $(a,b)$ with $a\in A$ and $b\in B$.
A _binary relation_ on $A\times B$ is just a subset $R\subseteq A\times B$.
The sets $A$ and $B$ can be the same, but they do not have to be.  The set $A$
is called the _domain_ and $B$ the _codomain_ (or _range_) of $R$.  The smallest binary
relation on $A\times B$ is the null relation $\emptyset$ consisting
of no pairs, and the largest binary relation on $A\times B$ is $A\times B$ itself.
The _identity relation_ on $A$ is $\nm{ID}=\{(a,a)\mid a\in A\}\subseteq A\times A$.

An important operation on binary relations is _relational composition_
\[
R;S = \{(a,c) \mid \exists b\ (a,b)\in R \wedge (b,c)\in S\},
\]
where the codomain of $R$ is the same as the domain of $S$.

A (_total_) _function_ (or _map_) is a binary relation $f\subseteq A\times B$ in which each element of $A$
is associated with exactly one element of $B$.  There can be more than one element of $A$ associated with the
same element of $B$.  If $f$ is such a function, we write:
\[
f : A \rightarrow B
\]
In other words, a function $f:A\rightarrow B$ is a binary relation $f\subseteq A\times B$ such that for each
element $a\in A$, there is exactly one pair $(a,b)\in f$ with first component $a$.

The set $A$ is the _domain_ and $B$ is the
_codomain_ or _range_ of $f$.  The _image_ of $f$ is the set of elements in
$B$ that come from at least one element in $A$ under $f$:
\begin{eqnarray*}
{\mathit{image}}(f) &=& \{ x \in B \mid x = f(a) \mbox{~for some~} a \in A \}\\
&=& \{ f(a) \mid a \in A \}.
\end{eqnarray*}
This is also sometimes denoted $f(A)$, although this is an abuse of notation.

A _partial function_ $f: A \rightharpoonup B$ is a function $f:A'\rightarrow B$ defined on some subset $A'\subseteq A$.  The notation $\dom(f)$ refers to $A'$, the domain of $f$.

A function $f:A\rightarrow B$ is said to be _one-to-one_ (or _injective_) if $a\neq b$ implies $f(a)\neq f(b)$ and _onto_ (or _surjective_) if every $b\in B$ is $f(a)$ for some $a\in A$.

\subsection{Representation of Functions}

Mathematically, a function is equal to its _extension_, which is the set of all its (input, output) pairs.  One way to describe a function is to describe its extension directly, usually by specifying some mathematical relationship between the inputs and outputs.  This is called an _extensional_ representation.  Another way is to give an _intensional_\footnote{Note the spelling: _intensional_ and _intentional_ are not the same!} representation, which is essentially a program or evaluation procedure to compute the output corresponding to a given input.  The main differences are
\begin{enumerate}
\item
there can be more than one intensional representation of the same function, but there is only one extension;
\item
intensional representations typically give a method for computing the output from a given input, whereas extensional representations need not concern themselves with computation (and often do not).
\end{enumerate}

This course is quite a bit about how to get from an intensional representation to a corresponding extensional representation.

\section{The Lambda Calculus}

The lambda calculus (or $\lambda$-calculus\footnote{Why $\lambda$? Church wanted to separate the bound
variables from the unbound (free) variables and he used a caret on top of
the bound variables. $f(x) = x + yx^2$ was represented as
$\hat{x} . x + yx^2$. Apparently, the printers could not handle the caret 
and it moved to the front and became a $\lambda$;
the expression became $\lam{x}{x + yx^2}$}, $\lambda$=Greek ``L'')
was introduced by Alonzo Church and Stephen Cole Kleene in the 1930s to
describe functions in an unambiguous and compact manner.  The lambda
calculus provides _intensional_ representations of functions.

Real programming languages such as Lisp, Scheme, Haskell and ML are
based on the lambda calculus, although there are differences as well.
Lisp was the first of these.

It is common to use lambda notation in conjunction with other operators and
values in some domain, such as $\lam x {x+2}$, but the _pure_ $\lambda$-calculus has
only $\lambda$-terms and only the operators of functional abstraction and functional application,
nothing else.  In the pure $\lambda$-calculus, $\lambda$-terms act as functions that
take other $\lambda$-terms as input and produce $\lambda$-terms as output.
Nevertheless, it is possible to code common data structures such as booleans, integers,
lists, and trees as $\lambda$-terms.  The $\lambda$-calculus is computationally powerful
enough to represent and compute any computable function. It is thus equivalent to
Turing machines in computational power.

\subsection{Syntax}

The following is the syntax of the pure $\lambda$-calculus. A $\lambda$-term is
defined inductively as follows.  There is a countable set of _variables_ \Set{Var}.

\begin{enumerate}
\item
Any variable $x\in\Set{Var}$ is a $\lambda$-term.
\item
If $e$ is a $\lambda$-term, then so is $\lam x e$ (functional abstraction).
\item
If $e_1$ and $e_2$ are $\lambda$-terms, then so is $e_1\cdot e_2$ (functional application).
\end{enumerate}
We often write $e_1\,e_2$ or $e_1(e_2)$ for $e_1\cdot e_2$.  Intuitively, this term represents the result of applying of $e_1$ as a function to $e_2$ as its input.  The term $\lam x e$ represents a function with input parameter $x$ and body $e$.

We can abbreviate the above definition in BNF (Backus--Naur form) as

\medskip

\[
\nm{e}\ \ ::=\ \ x \bnf e_1~e_2 \bnf \lam{x}{e}.
\]

\medskip

In mathematics it is common to define a function $f$ by writing down what
its value on a typical input would be.  For example, we might define the
squaring function on integers by writing $f(x)=x^2$.  This is the same as writing $f=\lam x{x^2}$.
In mathematics, one often writes $x \mapsto x^2$ to denote the same function _anonymously_, that
is, without giving it a separate name; this is the same as writing $\lam x{x^2}$.

Here are some examples of $\lambda$-terms. The identity function is $\nm{ID} = \lam xx$.
A function that ignores its argument and return the identity function is $\lam x {\lam aa}$.
This is the same as $\lam x {\nm{ID}}.$

Parentheses are used to show explicitly how to parse expressions, but we
also assign a precedence to the operators in order to save parentheses.
The application operator $\cdot$ binds tighter than $\lambda$-abstraction.
Another way to view this is that the body of a $\lambda$-abstraction extends as
far to the right as it can.  For example, $\lam{x}{x}~\lam{y}{y}$
should be parsed as $\lam{x}{(x~\lam{y}{y})}$, not
$(\lam{x}{x})~(\lam{y}{y})$.  If you want the latter, you have
to use explicit parentheses.  Application is _left-associative_, which
means that $e_1\,e_2\,e_3$ should be parsed as $(e_1\,e_2)\,e_3$.

It's never a bad idea to include parentheses if you aren't sure.  

\subsection{Scope, Bound and Free Occurrences, Closed Terms}

The _scope_ of the abstraction operator $\lambda x$ shown in the term $\lam xe$ is the body $e$.  An occurrence of a variable $y$ in a term is said to be _bound_ in that term if it occurs in the scope of an abstraction operator $\lambda y$; otherwise, it is _free_.  A bound occurrence of $y$ is _bound to_ the abstraction operator $\lambda y$ with the smallest scope in which it occurs.  Note that a variable can have bound and free occurrences in the same term, and can have bound occurrences that are bound to different abstraction operators.

A term is _closed_ if all variables are bound.

In the term
\[
\lam{x}{(x~(\lam{y}{y~a})~x)~(\lam x x~y)},
\]
all three occurrences of $x$ are bound.  The first two are bound to the first $\lambda x$, and the last is bound to the second $\lambda x$.  The first occurrence of $y$ is
bound, the $a$ is free, and the last $y$ is free, since it is
not in the scope of any $\lambda y$.

\subsection{Higher-Order Functions}

In lambda calculus, we can define functions that can take functions
as arguments and return functions as results.
Thus functions are _first-class values_.  For example, the term
$\lam{f}{f~5}$ represents a function that takes another function $f$ as
an argument and applies it to 5.  The term $\lam{v}{\lam{f}{f~v}}$
represents a function that takes an argument $v$ and returns a function
that calls its argument on $v$.  A function that takes a pair of functions
and returns their composition is represented by $\lam f{\lam g{\lam x{g(fx)}}}$.

In fact, every $\lambda$-term represents a function, since any $\lambda$-term
can appear on the left-hand side of an application operator.  

\subsection{Multi-Argument Functions and Currying}

We would like to allow multiple arguments to a function, as for example in $(\lam {x,y} {x+y}) (5,2)$.  However we can consider this an abbreviation for $(\lam x {\lam y {x+y}}) ~5~2$.  That is, instead of the function taking two arguments and adding them, the function takes only the first argument and returns a function that takes the second argument and then adds the two arguments.  In general, $\lam {x_1\ldots x_n} e$ is considered an abbreviation for $\lam {x_1}\lam {x_2}\lam {x_3}\ldots \lam {x_n}e$.  Thus we consider the multi-argument version of the $\lambda$-calculus as just syntactic sugar.  The ``desugaring'' transformation
\begin{eqnarray*}
\lam{x_1\ldots x_n}e  & \Rightarrow & \lam{x_1}{\lam{x_2}{ \lam{x_n}~{e} }}\\
e_0~(e_1,\ldots,e_n) & \Rightarrow & e_0~e_1~e_2~\cdots~e_n
\end{eqnarray*}
for this particular form of sugar is called _currying_ (after Haskell B.~Curry).

\section{Preview}

Next time we will discuss capture-avoiding (safe) substitution the computational rules of the $\lambda$-calculus, namely $\alpha$-, $\beta$-, and $\eta$-reduction.  This is the _calculus_ part of the $\lambda$-calculus.

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