|
@@ -208,8 +208,7 @@ includes only arithmetic and variables and we add new language
|
|
features in subsequent chapters.
|
|
features in subsequent chapters.
|
|
|
|
|
|
Our choice of language features is designed to elicit fundamental
|
|
Our choice of language features is designed to elicit fundamental
|
|
-concepts and algorithms used in compilers while minimizing incidental
|
|
|
|
-complexity.
|
|
|
|
|
|
+concepts and algorithms used in compilers.
|
|
\begin{itemize}
|
|
\begin{itemize}
|
|
\item We begin with integer arithmetic and local variables in
|
|
\item We begin with integer arithmetic and local variables in
|
|
Chapters~\ref{ch:trees-recur} and \ref{ch:Lvar}, where we introduce
|
|
Chapters~\ref{ch:trees-recur} and \ref{ch:Lvar}, where we introduce
|
|
@@ -226,33 +225,33 @@ complexity.
|
|
analysis} in the register allocator.
|
|
analysis} in the register allocator.
|
|
\item Chapter~\ref{ch:Lvec} adds heap-allocated tuples, motivating
|
|
\item Chapter~\ref{ch:Lvec} adds heap-allocated tuples, motivating
|
|
\emph{garbage collection}.
|
|
\emph{garbage collection}.
|
|
-\item Chapter~\ref{ch:Rfun} adds functions that are first-class values
|
|
|
|
|
|
+\item Chapter~\ref{ch:Lfun} adds functions that are first-class values
|
|
but lack lexical scoping, similar to the C programming
|
|
but lack lexical scoping, similar to the C programming
|
|
language~\citep{Kernighan:1988nx} except that we generate efficient
|
|
language~\citep{Kernighan:1988nx} except that we generate efficient
|
|
tail calls. The reader learns about the procedure call stack,
|
|
tail calls. The reader learns about the procedure call stack,
|
|
\emph{calling conventions}, and their interaction with register
|
|
\emph{calling conventions}, and their interaction with register
|
|
allocation and garbage collection.
|
|
allocation and garbage collection.
|
|
-\item Chapter~\ref{ch:Rlam} adds anonymous functions with lexical
|
|
|
|
|
|
+\item Chapter~\ref{ch:Llambda} adds anonymous functions with lexical
|
|
scoping, i.e., \emph{lambda abstraction}. The reader learns about
|
|
scoping, i.e., \emph{lambda abstraction}. The reader learns about
|
|
\emph{closure conversion}, in which lambdas are translated into a
|
|
\emph{closure conversion}, in which lambdas are translated into a
|
|
combination of functions and tuples.
|
|
combination of functions and tuples.
|
|
% Chapter about classes and objects?
|
|
% Chapter about classes and objects?
|
|
-\item Chapter~\ref{ch:Rdyn} adds \emph{dynamic typing}. Prior to this
|
|
|
|
|
|
+\item Chapter~\ref{ch:Ldyn} adds \emph{dynamic typing}. Prior to this
|
|
point the input languages are statically typed. The reader extends
|
|
point the input languages are statically typed. The reader extends
|
|
the statically typed language with an \code{Any} type which serves
|
|
the statically typed language with an \code{Any} type which serves
|
|
as a target for compiling the dynamically typed language.
|
|
as a target for compiling the dynamically typed language.
|
|
{\if\edition\pythonEd
|
|
{\if\edition\pythonEd
|
|
-\item Chapter~\ref{ch:Robject} adds support for \emph{objects} and
|
|
|
|
|
|
+\item Chapter~\ref{ch:Lobject} adds support for \emph{objects} and
|
|
\emph{classes}.
|
|
\emph{classes}.
|
|
\fi}
|
|
\fi}
|
|
-\item Chapter~\ref{ch:Rgrad} uses the \code{Any} type of
|
|
|
|
- Chapter~\ref{ch:Rdyn} to implement a \emph{gradually typed language}
|
|
|
|
|
|
+\item Chapter~\ref{ch:Lgrad} uses the \code{Any} type of
|
|
|
|
+ Chapter~\ref{ch:Ldyn} to implement a \emph{gradually typed language}
|
|
in which different regions of a program may be static or dynamically
|
|
in which different regions of a program may be static or dynamically
|
|
typed. The reader implements runtime support for \emph{proxies} that
|
|
typed. The reader implements runtime support for \emph{proxies} that
|
|
allow values to safely move between regions.
|
|
allow values to safely move between regions.
|
|
-\item Chapter~\ref{ch:Rpoly} adds \emph{generics} with autoboxing,
|
|
|
|
|
|
+\item Chapter~\ref{ch:Lpoly} adds \emph{generics} with autoboxing,
|
|
leveraging the \code{Any} type and type casts developed in Chapters
|
|
leveraging the \code{Any} type and type casts developed in Chapters
|
|
- \ref{ch:Rdyn} and \ref{ch:Rgrad}.
|
|
|
|
|
|
+ \ref{ch:Ldyn} and \ref{ch:Lgrad}.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
There are many language features that we do not include. Our choices
|
|
There are many language features that we do not include. Our choices
|
|
balance the incidental complexity of a feature versus the fundamental
|
|
balance the incidental complexity of a feature versus the fundamental
|
|
@@ -271,25 +270,33 @@ mathematics.
|
|
%
|
|
%
|
|
At the beginning of the course, students form groups of 2-4 people.
|
|
At the beginning of the course, students form groups of 2-4 people.
|
|
The groups complete one chapter every two weeks, starting with
|
|
The groups complete one chapter every two weeks, starting with
|
|
-Chapter~\ref{ch:Lvar}. Many chapters include a challenge problem that
|
|
|
|
-we assign to the graduate students. The last two weeks of the course
|
|
|
|
-involve a final project in which students design and implement a
|
|
|
|
-compiler extension of their choosing. Chapters~\ref{ch:Rgrad} and
|
|
|
|
-\ref{ch:Rpoly} can be used in support of these projects or they can
|
|
|
|
-replace some of the other chapters. For example, a course with an
|
|
|
|
-emphasis on statically-typed imperative languages could include
|
|
|
|
-Chapter~\ref{ch:Rpoly} but skip Chapter~\ref{ch:Rdyn}. For compiler
|
|
|
|
-courses at universities on the quarter system, with 10 weeks, we
|
|
|
|
-recommend completing up through Chapter~\ref{ch:Rfun}. (If pressed
|
|
|
|
-for time, one can skip Chapter~\ref{ch:Lvec} but still include
|
|
|
|
-Chapter~\ref{ch:Rfun} by limiting the number of parameters allowed in
|
|
|
|
-functions.) Figure~\ref{fig:chapter-dependences} depicts the
|
|
|
|
-dependencies between chapters.
|
|
|
|
-
|
|
|
|
-This book has also been used in compiler courses at California
|
|
|
|
-Polytechnic State University, Portland State University, Rose–Hulman
|
|
|
|
-Institute of Technology, University of Massachusetts Lowell, and the
|
|
|
|
-University of Vermont.
|
|
|
|
|
|
+Chapter~\ref{ch:Lvar} and finishing with
|
|
|
|
+Chapter~\ref{ch:Llambda}. Many chapters include a challenge problem
|
|
|
|
+that we assign to the graduate students. The last two weeks of the
|
|
|
|
+course involve a final project in which students design and implement
|
|
|
|
+a compiler extension of their choosing. The later chapters can be
|
|
|
|
+used in support of these projects. For compiler courses at
|
|
|
|
+universities on the quarter system that are about 10 weeks in length,
|
|
|
|
+we recommend completing up through Chapter~\ref{ch:Lvec} or
|
|
|
|
+Chapter~\ref{ch:Lfun} and providing some scafolding code to the
|
|
|
|
+students for each compiler pass.
|
|
|
|
+%
|
|
|
|
+The course can be adapted to emphasize functional languages by
|
|
|
|
+skipping Chapter~\ref{ch:Lwhile} (loops) and including
|
|
|
|
+Chapter~\ref{ch:Llambda} (lambda). The course can be adapted to
|
|
|
|
+dynamically typed languages by including Chapter~\ref{ch:Ldyn} and
|
|
|
|
+adapted to object-oriented languages by including
|
|
|
|
+Chapter~\ref{ch:Lobject}.
|
|
|
|
+%
|
|
|
|
+Figure~\ref{fig:chapter-dependences} depicts the dependencies between
|
|
|
|
+chapters. Chapter~\ref{ch:Lfun} (functions) depends on
|
|
|
|
+Chapter~\ref{ch:Lvec} (tuples) in the implementation of efficient
|
|
|
|
+tail calls.
|
|
|
|
+
|
|
|
|
+This book has been used in compiler courses at California Polytechnic
|
|
|
|
+State University, Portland State University, Rose–Hulman Institute of
|
|
|
|
+Technology, University of Freiburg, University of Massachusetts
|
|
|
|
+Lowell, and the University of Vermont.
|
|
|
|
|
|
|
|
|
|
\begin{figure}[tp]
|
|
\begin{figure}[tp]
|
|
@@ -300,12 +307,12 @@ University of Vermont.
|
|
\node (C3) at (8,1.5) {\small Ch.~\ref{ch:register-allocation-Lvar} Registers};
|
|
\node (C3) at (8,1.5) {\small Ch.~\ref{ch:register-allocation-Lvar} Registers};
|
|
\node (C4) at (0,0) {\small Ch.~\ref{ch:Lif} Conditionals};
|
|
\node (C4) at (0,0) {\small Ch.~\ref{ch:Lif} Conditionals};
|
|
\node (C5) at (4,0) {\small Ch.~\ref{ch:Lvec} Tuples};
|
|
\node (C5) at (4,0) {\small Ch.~\ref{ch:Lvec} Tuples};
|
|
- \node (C6) at (8,0) {\small Ch.~\ref{ch:Rfun} Functions};
|
|
|
|
|
|
+ \node (C6) at (8,0) {\small Ch.~\ref{ch:Lfun} Functions};
|
|
\node (C9) at (0,-1.5) {\small Ch.~\ref{ch:Lwhile} Loops};
|
|
\node (C9) at (0,-1.5) {\small Ch.~\ref{ch:Lwhile} Loops};
|
|
- \node (C8) at (4,-1.5) {\small Ch.~\ref{ch:Rdyn} Dynamic};
|
|
|
|
- \node (C7) at (8,-1.5) {\small Ch.~\ref{ch:Rlam} Lambda};
|
|
|
|
- \node (C10) at (4,-3) {\small Ch.~\ref{ch:Rgrad} Gradual Typing};
|
|
|
|
- \node (C11) at (8,-3) {\small Ch.~\ref{ch:Rpoly} Generics};
|
|
|
|
|
|
+ \node (C8) at (4,-1.5) {\small Ch.~\ref{ch:Ldyn} Dynamic};
|
|
|
|
+ \node (C7) at (8,-1.5) {\small Ch.~\ref{ch:Llambda} Lambda};
|
|
|
|
+ \node (C10) at (4,-3) {\small Ch.~\ref{ch:Lgrad} Gradual Typing};
|
|
|
|
+ \node (C11) at (8,-3) {\small Ch.~\ref{ch:Lpoly} Generics};
|
|
|
|
|
|
\path[->] (C1) edge [above] node {} (C2);
|
|
\path[->] (C1) edge [above] node {} (C2);
|
|
\path[->] (C2) edge [above] node {} (C3);
|
|
\path[->] (C2) edge [above] node {} (C3);
|
|
@@ -326,19 +333,19 @@ University of Vermont.
|
|
\node (C3) at (8,1.5) {\small Ch.~\ref{ch:register-allocation-Lvar} Registers};
|
|
\node (C3) at (8,1.5) {\small Ch.~\ref{ch:register-allocation-Lvar} Registers};
|
|
\node (C4) at (0,0) {\small Ch.~\ref{ch:Lif} Conditionals};
|
|
\node (C4) at (0,0) {\small Ch.~\ref{ch:Lif} Conditionals};
|
|
\node (C5) at (4,0) {\small Ch.~\ref{ch:Lvec} Tuples};
|
|
\node (C5) at (4,0) {\small Ch.~\ref{ch:Lvec} Tuples};
|
|
- \node (C6) at (8,0) {\small Ch.~\ref{ch:Rfun} Functions};
|
|
|
|
|
|
+ \node (C6) at (8,0) {\small Ch.~\ref{ch:Lfun} Functions};
|
|
\node (C9) at (0,-1.5) {\small Ch.~\ref{ch:Lwhile} Loops};
|
|
\node (C9) at (0,-1.5) {\small Ch.~\ref{ch:Lwhile} Loops};
|
|
- \node (C8) at (4,-1.5) {\small Ch.~\ref{ch:Rdyn} Dynamic};
|
|
|
|
- \node (CO) at (0,-3) {\small Ch.~\ref{ch:Robject} Objects};
|
|
|
|
- \node (C7) at (8,-1.5) {\small Ch.~\ref{ch:Rlam} Lambda};
|
|
|
|
- \node (C10) at (4,-3) {\small Ch.~\ref{ch:Rgrad} Gradual Typing};
|
|
|
|
- \node (C11) at (8,-3) {\small Ch.~\ref{ch:Rpoly} Generics};
|
|
|
|
|
|
+ \node (C8) at (4,-1.5) {\small Ch.~\ref{ch:Ldyn} Dynamic};
|
|
|
|
+ \node (CO) at (0,-3) {\small Ch.~\ref{ch:Lobject} Objects};
|
|
|
|
+ \node (C7) at (8,-1.5) {\small Ch.~\ref{ch:Llambda} Lambda};
|
|
|
|
+ \node (C10) at (4,-3) {\small Ch.~\ref{ch:Lgrad} Gradual Typing};
|
|
|
|
+ \node (C11) at (8,-3) {\small Ch.~\ref{ch:Lpoly} Generics};
|
|
|
|
|
|
\path[->] (C1) edge [above] node {} (C2);
|
|
\path[->] (C1) edge [above] node {} (C2);
|
|
\path[->] (C2) edge [above] node {} (C3);
|
|
\path[->] (C2) edge [above] node {} (C3);
|
|
\path[->] (C3) edge [above] node {} (C4);
|
|
\path[->] (C3) edge [above] node {} (C4);
|
|
\path[->] (C4) edge [above] node {} (C5);
|
|
\path[->] (C4) edge [above] node {} (C5);
|
|
- \path[->] (C5) edge [above] node {} (C6);
|
|
|
|
|
|
+ \path[->,style=dotted] (C5) edge [above] node {} (C6);
|
|
\path[->] (C6) edge [above] node {} (C7);
|
|
\path[->] (C6) edge [above] node {} (C7);
|
|
\path[->] (C4) edge [above] node {} (C8);
|
|
\path[->] (C4) edge [above] node {} (C8);
|
|
\path[->] (C4) edge [above] node {} (C9);
|
|
\path[->] (C4) edge [above] node {} (C9);
|
|
@@ -424,9 +431,9 @@ on.
|
|
We thank the many students who served as teaching assistants for the
|
|
We thank the many students who served as teaching assistants for the
|
|
compiler course at IU and made suggestions for improving the book
|
|
compiler course at IU and made suggestions for improving the book
|
|
including Carl Factora, Ryan Scott, Cameron Swords, and Chris
|
|
including Carl Factora, Ryan Scott, Cameron Swords, and Chris
|
|
-Wailes. We thank Andre Kuhlenschmidt for work on the garbage
|
|
|
|
-collector, Michael Vollmer for work on efficient tail calls, and
|
|
|
|
-Michael Vitousek for help running the first offering of the
|
|
|
|
|
|
+Wailes. We thank Andre Kuhlenschmidt for work on the garbage collector
|
|
|
|
+and x86 interpreter, Michael Vollmer for work on efficient tail calls,
|
|
|
|
+and Michael Vitousek for help running the first offering of the
|
|
incremental compiler course at IU.
|
|
incremental compiler course at IU.
|
|
|
|
|
|
We thank professors Bor-Yuh Chang, John Clements, Jay McCarthy, Joseph
|
|
We thank professors Bor-Yuh Chang, John Clements, Jay McCarthy, Joseph
|
|
@@ -1431,7 +1438,7 @@ do anything. On the other hand, if the error is a
|
|
\code{trapped-error}, then the compiler must produce an executable and
|
|
\code{trapped-error}, then the compiler must produce an executable and
|
|
it is required to report that an error occurred. To signal an error,
|
|
it is required to report that an error occurred. To signal an error,
|
|
exit with a return code of \code{255}. The interpreters in chapters
|
|
exit with a return code of \code{255}. The interpreters in chapters
|
|
-\ref{ch:Rdyn} and \ref{ch:Rgrad} use
|
|
|
|
|
|
+\ref{ch:Ldyn} and \ref{ch:Lgrad} use
|
|
\code{trapped-error}.
|
|
\code{trapped-error}.
|
|
\fi}
|
|
\fi}
|
|
|
|
|
|
@@ -2348,7 +2355,7 @@ specified by the label and $\key{retq}$ returns from a procedure to
|
|
its caller.
|
|
its caller.
|
|
%
|
|
%
|
|
We discuss procedure calls in more detail later in this chapter and in
|
|
We discuss procedure calls in more detail later in this chapter and in
|
|
-Chapter~\ref{ch:Rfun}.
|
|
|
|
|
|
+Chapter~\ref{ch:Lfun}.
|
|
%
|
|
%
|
|
The last letter \key{q} indicates that these instructions operate on
|
|
The last letter \key{q} indicates that these instructions operate on
|
|
quadwords, i.e., 64-bit values.
|
|
quadwords, i.e., 64-bit values.
|
|
@@ -2716,7 +2723,7 @@ use \key{let} in the output of \key{remove\_complex\_opera*}.}
|
|
The \key{select\_instructions} and \key{assign\_homes} passes are
|
|
The \key{select\_instructions} and \key{assign\_homes} passes are
|
|
intertwined.
|
|
intertwined.
|
|
%
|
|
%
|
|
-In Chapter~\ref{ch:Rfun} we learn that, in x86, registers are used for
|
|
|
|
|
|
+In Chapter~\ref{ch:Lfun} we learn that, in x86, registers are used for
|
|
passing arguments to functions and it is preferable to assign
|
|
passing arguments to functions and it is preferable to assign
|
|
parameters to their corresponding registers. This suggests that it
|
|
parameters to their corresponding registers. This suggests that it
|
|
would be better to start with the \key{select\_instructions} pass,
|
|
would be better to start with the \key{select\_instructions} pass,
|
|
@@ -4087,7 +4094,7 @@ rdi rsi rdx rcx r8 r9
|
|
\end{lstlisting}
|
|
\end{lstlisting}
|
|
If there are more than six arguments, then the convention is to use
|
|
If there are more than six arguments, then the convention is to use
|
|
space on the frame of the caller for the rest of the
|
|
space on the frame of the caller for the rest of the
|
|
-arguments. However, in Chapter~\ref{ch:Rfun} we arrange never to
|
|
|
|
|
|
+arguments. However, in Chapter~\ref{ch:Lfun} we arrange never to
|
|
need more than six arguments.
|
|
need more than six arguments.
|
|
%
|
|
%
|
|
\racket{For now, the only function we care about is \code{read\_int}
|
|
\racket{For now, the only function we care about is \code{read\_int}
|
|
@@ -5306,7 +5313,7 @@ We recommend creating an auxiliary function named \code{color\_graph}
|
|
that takes an interference graph and a list of all the variables in
|
|
that takes an interference graph and a list of all the variables in
|
|
the program. This function should return a mapping of variables to
|
|
the program. This function should return a mapping of variables to
|
|
their colors (represented as natural numbers). By creating this helper
|
|
their colors (represented as natural numbers). By creating this helper
|
|
-function, you will be able to reuse it in Chapter~\ref{ch:Rfun}
|
|
|
|
|
|
+function, you will be able to reuse it in Chapter~\ref{ch:Lfun}
|
|
when we add support for functions.
|
|
when we add support for functions.
|
|
|
|
|
|
To prioritize the processing of highly saturated nodes inside the
|
|
To prioritize the processing of highly saturated nodes inside the
|
|
@@ -6426,7 +6433,7 @@ of \racket{\code{(car 1)}}\python{\code{1[0]}}, \racket{Typed
|
|
\python{stating that a ``value of type \code{int} is not indexable''.}
|
|
\python{stating that a ``value of type \code{int} is not indexable''.}
|
|
|
|
|
|
The \LangIf{} language performs type checking during compilation like
|
|
The \LangIf{} language performs type checking during compilation like
|
|
-\racket{Typed Racket}\python{MyPy}. In Chapter~\ref{ch:Rdyn} we study the
|
|
|
|
|
|
+\racket{Typed Racket}\python{MyPy}. In Chapter~\ref{ch:Ldyn} we study the
|
|
alternative choice, that is, a dynamically typed language like
|
|
alternative choice, that is, a dynamically typed language like
|
|
\racket{Racket}\python{Python}.
|
|
\racket{Racket}\python{Python}.
|
|
The \LangIf{} language is a subset of \racket{Typed Racket}\python{MyPy};
|
|
The \LangIf{} language is a subset of \racket{Typed Racket}\python{MyPy};
|
|
@@ -10869,7 +10876,7 @@ that reads from the vector it was bound to.
|
|
For example, the following program returns \code{42} even though the
|
|
For example, the following program returns \code{42} even though the
|
|
variable \code{x} goes out of scope when the function returns, prior
|
|
variable \code{x} goes out of scope when the function returns, prior
|
|
to reading the tuple element at index zero. (We study the compilation
|
|
to reading the tuple element at index zero. (We study the compilation
|
|
-of functions in Chapter~\ref{ch:Rfun}.)
|
|
|
|
|
|
+of functions in Chapter~\ref{ch:Lfun}.)
|
|
%
|
|
%
|
|
\begin{center}
|
|
\begin{center}
|
|
\begin{minipage}{0.96\textwidth}
|
|
\begin{minipage}{0.96\textwidth}
|
|
@@ -12579,7 +12586,7 @@ an array:
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
-Recall that in Chapter~\ref{ch:Rdyn}, we use a $3$-bit tag to
|
|
|
|
|
|
+Recall that in Chapter~\ref{ch:Ldyn}, we use a $3$-bit tag to
|
|
differentiate the kinds of values that have been injected into the
|
|
differentiate the kinds of values that have been injected into the
|
|
\code{Any} type. We use the bit pattern \code{110} (or $6$ in decimal)
|
|
\code{Any} type. We use the bit pattern \code{110} (or $6$ in decimal)
|
|
to indicate that the value is an array.
|
|
to indicate that the value is an array.
|
|
@@ -12592,7 +12599,7 @@ the passes to handle arrays.
|
|
|
|
|
|
The array-access operators \code{vectorof-ref} and
|
|
The array-access operators \code{vectorof-ref} and
|
|
\code{vectorof-set!} are similar to the \code{any-vector-ref} and
|
|
\code{vectorof-set!} are similar to the \code{any-vector-ref} and
|
|
-\code{any-vector-set!} operators of Chapter~\ref{ch:Rdyn} in
|
|
|
|
|
|
+\code{any-vector-set!} operators of Chapter~\ref{ch:Ldyn} in
|
|
that the type checker cannot tell whether the index will be in bounds,
|
|
that the type checker cannot tell whether the index will be in bounds,
|
|
so the bounds check must be performed at run time. Recall that the
|
|
so the bounds check must be performed at run time. Recall that the
|
|
\code{reveal-casts} pass (Section~\ref{sec:reveal-casts-Rany}) wraps
|
|
\code{reveal-casts} pass (Section~\ref{sec:reveal-casts-Rany}) wraps
|
|
@@ -12761,7 +12768,7 @@ from the set.
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\chapter{Functions}
|
|
\chapter{Functions}
|
|
-\label{ch:Rfun}
|
|
|
|
|
|
+\label{ch:Lfun}
|
|
\index{subject}{function}
|
|
\index{subject}{function}
|
|
|
|
|
|
This chapter studies the compilation of functions similar to those
|
|
This chapter studies the compilation of functions similar to those
|
|
@@ -12769,7 +12776,7 @@ found in the C language. This corresponds to a subset of \racket{Typed
|
|
Racket} \python{Python} in which only top-level function definitions
|
|
Racket} \python{Python} in which only top-level function definitions
|
|
are allowed. This kind of function is an important stepping stone to
|
|
are allowed. This kind of function is an important stepping stone to
|
|
implementing lexically-scoped functions in the form of \key{lambda}
|
|
implementing lexically-scoped functions in the form of \key{lambda}
|
|
-abstractions, which is the topic of Chapter~\ref{ch:Rlam}.
|
|
|
|
|
|
+abstractions, which is the topic of Chapter~\ref{ch:Llambda}.
|
|
|
|
|
|
\section{The \LangFun{} Language}
|
|
\section{The \LangFun{} Language}
|
|
|
|
|
|
@@ -14428,7 +14435,7 @@ mainconclusion:
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\chapter{Lexically Scoped Functions}
|
|
\chapter{Lexically Scoped Functions}
|
|
-\label{ch:Rlam}
|
|
|
|
|
|
+\label{ch:Llambda}
|
|
\index{subject}{lambda}
|
|
\index{subject}{lambda}
|
|
\index{subject}{lexical scoping}
|
|
\index{subject}{lexical scoping}
|
|
|
|
|
|
@@ -14524,7 +14531,7 @@ of the free variables together with a function pointer into a tuple,
|
|
an arrangement called a \emph{flat closure} (which we shorten to just
|
|
an arrangement called a \emph{flat closure} (which we shorten to just
|
|
``closure''). \index{subject}{closure}\index{subject}{flat closure}
|
|
``closure''). \index{subject}{closure}\index{subject}{flat closure}
|
|
Fortunately, we have all the ingredients to make closures:
|
|
Fortunately, we have all the ingredients to make closures:
|
|
-Chapter~\ref{ch:Lvec} gave us tuples and Chapter~\ref{ch:Rfun} gave us
|
|
|
|
|
|
+Chapter~\ref{ch:Lvec} gave us tuples and Chapter~\ref{ch:Lfun} gave us
|
|
function pointers. The function pointer resides at index $0$ and the
|
|
function pointers. The function pointer resides at index $0$ and the
|
|
values for the free variables fill in the rest of the tuple.
|
|
values for the free variables fill in the rest of the tuple.
|
|
|
|
|
|
@@ -16020,7 +16027,7 @@ and used in Chez Scheme version 1~\citep{Dybvig:2006aa}.
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\chapter{Dynamic Typing}
|
|
\chapter{Dynamic Typing}
|
|
-\label{ch:Rdyn}
|
|
|
|
|
|
+\label{ch:Ldyn}
|
|
\index{subject}{dynamic typing}
|
|
\index{subject}{dynamic typing}
|
|
|
|
|
|
\if\edition\racketEd
|
|
\if\edition\racketEd
|
|
@@ -17117,7 +17124,7 @@ for the compilation of \LangDyn{}.
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
{\if\edition\pythonEd
|
|
{\if\edition\pythonEd
|
|
\chapter{Objects}
|
|
\chapter{Objects}
|
|
-\label{ch:Robject}
|
|
|
|
|
|
+\label{ch:Lobject}
|
|
\index{subject}{objects}
|
|
\index{subject}{objects}
|
|
\index{subject}{classes}
|
|
\index{subject}{classes}
|
|
|
|
|
|
@@ -17126,7 +17133,7 @@ for the compilation of \LangDyn{}.
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\chapter{Gradual Typing}
|
|
\chapter{Gradual Typing}
|
|
-\label{ch:Rgrad}
|
|
|
|
|
|
+\label{ch:Lgrad}
|
|
\index{subject}{gradual typing}
|
|
\index{subject}{gradual typing}
|
|
|
|
|
|
\if\edition\racketEd
|
|
\if\edition\racketEd
|
|
@@ -17220,7 +17227,7 @@ syntax.
|
|
Both the type checker and the interpreter for \LangGrad{} require some
|
|
Both the type checker and the interpreter for \LangGrad{} require some
|
|
interesting changes to enable gradual typing, which we discuss in the
|
|
interesting changes to enable gradual typing, which we discuss in the
|
|
next two sections in the context of the \code{map} example from
|
|
next two sections in the context of the \code{map} example from
|
|
-Chapter~\ref{ch:Rfun}. In Figure~\ref{fig:gradual-map} we
|
|
|
|
|
|
+Chapter~\ref{ch:Lfun}. In Figure~\ref{fig:gradual-map} we
|
|
revised the \code{map} example, omitting the type annotations from
|
|
revised the \code{map} example, omitting the type annotations from
|
|
the \code{inc} function.
|
|
the \code{inc} function.
|
|
|
|
|
|
@@ -18297,7 +18304,7 @@ recommend the reader to the online gradual typing bibliography:
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\chapter{Parametric Polymorphism}
|
|
\chapter{Parametric Polymorphism}
|
|
-\label{ch:Rpoly}
|
|
|
|
|
|
+\label{ch:Lpoly}
|
|
\index{subject}{parametric polymorphism}
|
|
\index{subject}{parametric polymorphism}
|
|
\index{subject}{generics}
|
|
\index{subject}{generics}
|
|
|
|
|
|
@@ -18345,7 +18352,7 @@ declaration comes before the \code{define}. In the abstract syntax,
|
|
the return type in the \code{Def} is \code{Any}, but that should be
|
|
the return type in the \code{Def} is \code{Any}, but that should be
|
|
ignored in favor of the return type in the type declaration. (The
|
|
ignored in favor of the return type in the type declaration. (The
|
|
\code{Any} comes from using the same parser as in
|
|
\code{Any} comes from using the same parser as in
|
|
-Chapter~\ref{ch:Rdyn}.) The presence of a type declaration
|
|
|
|
|
|
+Chapter~\ref{ch:Ldyn}.) The presence of a type declaration
|
|
enables the use of an \code{All} type for a function, thereby making
|
|
enables the use of an \code{All} type for a function, thereby making
|
|
it polymorphic. The grammar for types is extended to include
|
|
it polymorphic. The grammar for types is extended to include
|
|
polymorphic types and type variables.
|
|
polymorphic types and type variables.
|
|
@@ -18747,7 +18754,7 @@ add just one new pass, \code{erase-types}, to compile \LangInst{} to
|
|
\section{Erase Types}
|
|
\section{Erase Types}
|
|
\label{sec:erase-types}
|
|
\label{sec:erase-types}
|
|
|
|
|
|
-We use the \code{Any} type from Chapter~\ref{ch:Rdyn} to
|
|
|
|
|
|
+We use the \code{Any} type from Chapter~\ref{ch:Ldyn} to
|
|
represent type variables. For example, Figure~\ref{fig:map-erase}
|
|
represent type variables. For example, Figure~\ref{fig:map-erase}
|
|
shows the output of the \code{erase-types} pass on the polymorphic
|
|
shows the output of the \code{erase-types} pass on the polymorphic
|
|
\code{map} (Figure~\ref{fig:map-poly}). The occurrences of
|
|
\code{map} (Figure~\ref{fig:map-poly}). The occurrences of
|