%%% 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{11}                  %% Lecture number
\title{Naming}   %% Title of lecture
\author{Yookyung Jo, Lars Backstrom}       %% name of scribe
\date{21 September, 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})

\begin{document}

\maketitle

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

% introduction, last time ...
% overview...
\section{Overview}

This lecture talks about more on naming.
\begin{itemize}
\item scoping semantics
\item non-hierarchical scoping
\end{itemize}

\section{Scoping semantics as translation}
Last time, we looked at how names are interpreted.
Naming is a key issue in programming.
How to name affects how easy or secure it is to program.
We feel that Turing machines or other programming languages that do not
have names seem missing something.
Somehow, programs with naming map closer to how we solve problems. \\

We build semantics for name scoping by translation.
Let's define our target language as below.

\begin{displaymath}
\begin{array}{ll}
\nm{e} & ::= x \bnf \lam{x}{e} \bnf e_0 e_1 \\
        & \bnf \nm{error} \bnf \nm{s} \bnf \nm{n} \\
%       & \bnf \nm{error} 
%         ~~~~~\textit{(for programs that mention variables not bound)} \\
%       & \bnf s ~~~~~\textit{(string)} \\
%       & \bnf n ~~~~~\textit{(integer)}\\
       & \bnf \mbox{let $x$ = $e_1$ in $e_2$} \bnf ...
\end{array}
\end{displaymath}
where $error$ represents programs with variables that are not bound,
$s$ is a string, $n$ is a number.  The language is much like uML.
The allowed expressions are not exhaustively enumerated.
(When we say $\mbox{\it{if $e_1 = e_2$ then $e_3$ else $e_4$}}$, $e_1 = e_2$ 
means string comparison.) \\

What is the meaning of the translated expression, $\SB{e}$? \\
We need to recognize the meaning of an expression by considering
the context (environment).
We can think of our translation as conversion from an 
expression $e$ into a function that expects a mapping from
names to values.
An environment is such a function that maps variable names to values.
\begin{displaymath}
\mbox{environment} ~~\rho : \mbox{variable names} \mapsto \mbox{values}
\end{displaymath}
Then we could think of $\SB{e}$ 
as a function that maps an environment to a value.
\begin{displaymath}
\SB{e} : \mbox{environment} \mapsto \mbox{value}
\end{displaymath}
We could get the target language expression by applying
$\SB{e}$ to some environment.
\begin{displaymath}
\SB{e} \rho : \mbox{target language expression}
\end{displaymath} \\

Here are some examples of environments. \\
The empty environment is,
\begin{displaymath}
\rho_0 = \lam{x}{\nm{error}}
\end{displaymath}
because there are no variables bound in the empty environment. \\
Another example of an environment definition is,
\begin{displaymath}
\{\mbox{``$y$''} \mapsto 2 \} = \lam{x}{\mbox{if $x$ = ``$y$'' then $2$ else $\nm{error}$}}
\end{displaymath}
\\
Let's take a look at the actual translation of expressions.
\begin{eqnarray*}
\SB{n} & = & \lam{\rho}{n} \\
\SB{x} & = & \lam{\rho}{\rho \mbox{``x''}}
\end{eqnarray*}
Or it is more convenient to think of target language expression, which is the translation applied to an environment.
\begin{eqnarray*}
\SB{n}\rho  & = & n \\
\SB{x}\rho & = & \rho \mbox{``x''} \\
\SB{\mbox{let $x$ = $e_1$ in $e_2$}}\rho & = & 
\mbox{let $y$ = $\SB{e_1}\rho$ in $\SB{e_2}\left( \nm{EXTEND} ~~\rho \mbox{``x''} y \right)$}
\end{eqnarray*}
where "EXTEND" is a function that generates a new environment by overriding some of the mappings in the original environment.
It can be defined as,
\begin{displaymath}
% \triangleq is not working. what is wrong?
% this is AMS symbol. how do I use the package?
\nm{EXTEND} = \lam{\rho x v}{\lam{x'}{\mbox{if $x'$ = 
    $x$ then $v$ else $\rho$ ``$x'$''}}}
\end{displaymath}

\subsection{static scoping}
So far, we dealt with the translation of expressions that does not      
depend on whether we use static scoping or dynamic scoping.  However,   
the translation of application and lambda abstraction depends on        
scoping.  In static scoping, an identifier is bound to a value when     
it first occurs in the program.  Thus, the binding of a variable in     
function definition is determined by the scope present in the the       
function definition.                                                    
\begin{eqnarray*}
\SB{e_1~e_2}\rho & = & 
\mbox{let $f$ = $\SB{e_1}\rho$ in let $v$ = $\SB{e_2}\rho$ in $fv$} \\
\SB{\lam{x}{e}}\rho & = & \lam{y}{\SB{e}\left( \nm{EXTEND} ~~\rho 
  \mbox{``x''} y \right)} ~~~~~~~ y \notin \nm{FV}\left( e \right)
\end{eqnarray*}

\subsection{Dynamic scoping}
For dynamic scoping, we need to adjust our notion of variable binding in
function application and abstraction.  In dynamic scoping, an identifier
is bound to a value when the function is called, not when the function
expression is evaluated.  Thus, the scope present in function definition
is ignored.  And when we do the actual function evaluation, we need to
pass the dynamic environment to the function we call.

\begin{eqnarray*}
\SB{e_1~e_2} \rho_{\mathit{dyn}} & = & 
\mbox{let $f$ = $\SB{e_1}\rho_{\mathit{dyn}}$ 
in let $v$ = $\SB{e_2}\rho_{\mathit{dyn}}$ in $f v \rho_{\mathit{dyn}}$} \\
\SB{\lam{x}{e}}\rho_{\mathit{lex}} & = & 
\lam{y \lam{\rho_{\mathit{dyn}}}{\SB{e}\left( \nm{EXTEND} ~~\rho_{\mathit{dyn}} 
\mbox{``x''} y \right)}} ~~~~~~~ \mbox{(throw out lexical environment)}
\end{eqnarray*}

\subsection{Static scope vs. dynamic scope}
Dynamic scoping translates function code into just another code.
While in static scope translation, both function code and
the naming environment $\left( \SB{e}, \rho_{\mathit{lex}} \right)$
is included.  \\
Dynamic scoping has its advantages.
Translation of certain features in the program is easier with
dynamic scope. For example, we do not need to look up the lexical
environment for variable binding for function code, while in static
scope, we have to carry the function closure which is the function 
code and its lexical environment. \\
Also, sometimes, it becomes handy to be able to customize
a function by providing new values for its free variables. \\
However, its advantages also imply its disadvantages.
In dynamic scoping, program optimization is hard,
because the compiler does not know statically 
how to determine the value of a variable.
Simple optimization techniques with string matches
used in static scoping cannot be used in dynamic scoping. \\
Dynamic scoping hurts program modularity because of the free
variables in function that can change their values according
the execution environment.  
As more and more of programming activities are to glue
existing big modules into something, rather than writing
a new piece of code, modularity is a serious concern.
This is why people gradually moved to designing programming
languages with lexical(static) scoping.

\section{Modules}
We'd like to be able to share resources easily across large blocks of
code.  There are a few different ways to do this.  In some languages
(like C), this is done with a global namespace.  Every part of the
program has access to the variables in this global namespace.
Unfortunately, this can cause problems, as different blocks of code
cannot use the same name from the global namespace to refer to two
different variables.  Additionally, it causes a large amount of
clutter in the global namespace for large amounts of code.

An alternative to this is to use modules.  These are similar to
classes in Java and C++.  The modules contain a number of different
variable names, and given a particular module, we can access the
variables in it.  Now, we would like to extend our definition of uML
to include the concept of modules as follows:

\begin{displaymath}
\begin{array}{ll}
e ::= & "module" (x_1 = e_1, x_2 = e_2, \ldots, x_n = e_n) \\
        & \bnf e_m.x \bnf "with"~e_m~e \bnf ...
\end{array}
\end{displaymath}

Simply put, we can now have modules in uML that bindings for a number
of names to variables.  Then, given a module, we can extract a single
variable from it using $e_m.x$ or we can evaluate an expression
$e$ with all of the variables in the module $e_m$ by doing $"with"~e_m~e$,
which brings all variables in $e_m$ into scope and then evaluates
$e$.

Naturally, we would now like to extend our translation from uML to
lambda calculus to include our new modules.  The basic idea is that a
module is very much like our naming environment, $\rho$.  With this
intuition, we define the following translations:

\begin{displaymath}
\begin{array}{rrrl}
\SB{module(x_1 = e_1, x_2 = e_2, ..., x_n = e_n)} \rho & = & \lam{x}if & \mbox{$x$=$x_1$ then $\SB{e_1} \rho$ else if} \\
 & & & \mbox{$x$=$x_2$ then $\SB{e_2} \rho$ else if} \\
 & & & ...  \\
 & & & \mbox{$x$=$x_n$ then $\SB{e_n}\rho$ else error} \\
\SB{e_m.x} \rho & = & \multicolumn{2}{l}{\SB{e_m} \rho~``x''} \\
\SB{\mbox{with $e_m$ $e$}} \rho & = & \multicolumn{2}{l}{\mbox{$\SB{e}$ (MERGE $\rho$ ($\SB{e_m}$ $\rho$))}} \\
\end{array}
\end{displaymath}

Notice that we've made a number of important decisions in our
translation.  In the module definition, we evaluate all of the
expressions in the same naming environment.  Thus, the functions and
variables within the environment cannot refer to each other.  In some
senses this makes sense.  We probably don't want to be able to do:
\begin{verbatim}
    x1 = x2
    x2 = x1
\end{verbatim}

However, we might want to have functions in the module that refer to
values in the same module.  It is possible to modify the definition to
account for this.

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