dhil/phd-dissertation
1
0
Fork 0
mirror of https://github.com/dhil/phd-dissertation synced 2026-03-13 11:08:25 +00:00
Code Issues Releases Wiki Activity

WIP

Browse Source
This commit is contained in:
Daniel Hillerström
2021-05-26 01:02:20 +01:00
parent 559d9c2d37
commit 9679a3cc82
1 changed files with 257 additions and 187 deletions
Download Patch File Download Diff File Expand all files Collapse all files

442
thesis.tex
View File

@@ -14846,24 +14846,25 @@ the captured context and continuation invocation context to coincide.
\def\LLL{{\mathcal L}} \def\LLL{{\mathcal L}}
\def\N{{\mathbb N}} \def\N{{\mathbb N}}
% %
In today's programming languages we find a wealth of powerful
constructs and features --- exceptions, higher-order store, dynamic
method dispatch, coroutines, explicit continuations, concurrency
features, Lisp-style `quote' and so on --- which may be present or
absent in various combinations in any given language. There are of
course many important pragmatic and stylistic differences between
languages, but here we are concerned with whether languages may differ
more essentially in their expressive power, according to the selection
of features they contain.
One can interpret this question in various ways. For instance, % In today's programming languages we find a wealth of powerful
\citet{Felleisen91} considers the question of whether a language % constructs and features --- exceptions, higher-order store, dynamic
$\LLL$ admits a translation into a sublanguage $\LLL'$ in a way which % method dispatch, coroutines, explicit continuations, concurrency
respects not only the behaviour of programs but also aspects of their % features, Lisp-style `quote' and so on --- which may be present or
(global or local) syntactic structure. If the translation of some % absent in various combinations in any given language. There are of
$\LLL$-program into $\LLL'$ requires a complete global restructuring, % course many important pragmatic and stylistic differences between
we may say that $\LLL'$ is in some way less expressive than $\LLL$. % languages, but here we are concerned with whether languages may differ
In the present paper, however, we have in mind even more fundamental % more essentially in their expressive power, according to the selection
% of features they contain.
% One can interpret this question in various ways. For instance,
% \citet{Felleisen91} considers the question of whether a language
% $\LLL$ admits a translation into a sublanguage $\LLL'$ in a way which
% respects not only the behaviour of programs but also aspects of their
% (global or local) syntactic structure. If the translation of some
% $\LLL$-program into $\LLL'$ requires a complete global restructuring,
% we may say that $\LLL'$ is in some way less expressive than $\LLL$.
However, in this chapter we will look at even more fundamental
expressivity differences that would not be bridged even if expressivity differences that would not be bridged even if
whole-program translations were admitted. These fall under two whole-program translations were admitted. These fall under two
headings. headings.
@@ -14876,9 +14877,9 @@ headings.
achieved in $\LLL'$? achieved in $\LLL'$?
\end{enumerate} \end{enumerate}
% %
We may also ask: are there examples of \emph{natural, practically % We may also ask: are there examples of \emph{natural, practically
useful} operations that manifest such differences? If so, this % useful} operations that manifest such differences? If so, this
might be considered as a significant advantage of $\LLL$ over $\LLL'$. % might be considered as a significant advantage of $\LLL$ over $\LLL'$.
If the `operations' we are asking about are ordinary first-order If the `operations' we are asking about are ordinary first-order
functions --- that is, both their inputs and outputs are of ground functions --- that is, both their inputs and outputs are of ground
@@ -14917,8 +14918,8 @@ but not in a typical `sequential' programming
language~\cite{Plotkin77}. It is also well known that the presence of language~\cite{Plotkin77}. It is also well known that the presence of
control features or local state enables observational distinctions control features or local state enables observational distinctions
that cannot be made in a purely functional setting: for instance, that cannot be made in a purely functional setting: for instance,
there are programs involving `call/cc' that detect the order in which there are programs involving call/cc that detect the order in which a
a (call-by-name) `+' operation evaluates its arguments (call-by-name) `+' operation evaluates its arguments
\citep{CartwrightF92}. Such operations are `non-functional' in the \citep{CartwrightF92}. Such operations are `non-functional' in the
sense that their output is not determined solely by the extension of sense that their output is not determined solely by the extension of
their input (seen as a mathematical function their input (seen as a mathematical function
@@ -14936,28 +14937,28 @@ low-order recursion but not by high-order iteration
theory of some of the natural notions of higher-order computability theory of some of the natural notions of higher-order computability
that arise in this way, is mapped out by \citet{LongleyN15}. that arise in this way, is mapped out by \citet{LongleyN15}.
Relatively few results of this character have so far been established % Relatively few results of this character have so far been established
on the complexity side. \citet{Pippenger96} gives an example of an % on the complexity side. \citet{Pippenger96} gives an example of an
`online' operation on infinite sequences of atomic symbols % `online' operation on infinite sequences of atomic symbols
(essentially a function from streams to streams) such that the first % (essentially a function from streams to streams) such that the first
$n$ output symbols can be produced within time $\BigO(n)$ if one is % $n$ output symbols can be produced within time $\BigO(n)$ if one is
working in an `impure' version of Lisp (in which mutation of `cons' % working in an `impure' version of Lisp (in which mutation of `cons'
pairs is admitted), but with a worst-case runtime no better than % pairs is admitted), but with a worst-case runtime no better than
$\Omega(n \log n)$ for any implementation in pure Lisp (without such % $\Omega(n \log n)$ for any implementation in pure Lisp (without such
mutation). This example was reconsidered by \citet{BirdJdM97} who % mutation). This example was reconsidered by \citet{BirdJdM97} who
showed that the same speedup can be achieved in a pure language by % showed that the same speedup can be achieved in a pure language by
using lazy evaluation. Another candidate is the familiar $\log n$ % using lazy evaluation. Another candidate is the familiar $\log n$
overhead involved in implementing maps (supporting lookup and % overhead involved in implementing maps (supporting lookup and
extension) in a pure functional language \cite{Okasaki99}, although to % extension) in a pure functional language \cite{Okasaki99}, although to
our knowledge this situation has not yet been subjected to theoretical % our knowledge this situation has not yet been subjected to theoretical
scrutiny. \citet{Jones01} explores the approach of manifesting % scrutiny. \citet{Jones01} explores the approach of manifesting
expressivity and efficiency differences between certain languages by % expressivity and efficiency differences between certain languages by
artificially restricting attention to `cons-free' programs; in this % artificially restricting attention to `cons-free' programs; in this
setting, the classes of representable first-order functions for the % setting, the classes of representable first-order functions for the
various languages are found to coincide with some well-known % various languages are found to coincide with some well-known
complexity classes. % complexity classes.
The purpose of the present paper is to give a clear example of such an The purpose of this chapter is to give a clear example of such an
inherent complexity difference higher up in the expressivity spectrum. inherent complexity difference higher up in the expressivity spectrum.
Specifically, we consider the following \emph{generic count} problem, Specifically, we consider the following \emph{generic count} problem,
parametric in $n$: given a boolean-valued predicate $P$ on the space parametric in $n$: given a boolean-valued predicate $P$ on the space
@@ -14981,9 +14982,8 @@ $\Omega(n 2^n)$ runtime. Moreover, we shall show that in a typical
call-by-value language without advanced control features, one cannot call-by-value language without advanced control features, one cannot
improve on this: \emph{any} implementation of $\Count_n$ must improve on this: \emph{any} implementation of $\Count_n$ must
necessarily take time $\Omega(n2^n)$ on \emph{any} predicate $P$. On necessarily take time $\Omega(n2^n)$ on \emph{any} predicate $P$. On
the other hand, if we extend our language with a feature such as the other hand, if we extend our language with effect handlers, it
\emph{effect handlers} (see Section~\ref{sec:handlers-primer} below), becomes possible to bring the runtime down to $\BigO(2^n)$: an
it becomes possible to bring the runtime down to $\BigO(2^n)$: an
asymptotic gain of a factor of $n$. asymptotic gain of a factor of $n$.
The \emph{generic search} problem is just like the generic count The \emph{generic search} problem is just like the generic count
@@ -15031,78 +15031,102 @@ precisely to show that our languages differ in an essential way
\emph{as regards their power to manipulate data of type} $(\Nat \to \emph{as regards their power to manipulate data of type} $(\Nat \to
\Bool) \to \Bool$. \Bool) \to \Bool$.
This idea of using first-class control to achieve `backtracking' has This idea of using first-class control to achieve backtracking has
been exploited before and is fairly widely known (see been exploited before and is fairly widely known (see
e.g. \citep{KiselyovSFA05}), and there is a clear programming e.g. \citep{KiselyovSFA05}), and there is a clear programming
intuition that this yields a speedup unattainable in languages without intuition that this yields a speedup unattainable in languages without
such control features. Our main contribution in this paper is to such control features. % Our main contribution in this paper is to
provide, for the first time, a precise mathematical theorem that pins % provide, for the first time, a precise mathematical theorem that pins
down this fundamental efficiency difference, thus giving formal % down this fundamental efficiency difference, thus giving formal
substance to this intuition. Since our goal is to give a realistic % substance to this intuition. Since our goal is to give a realistic
analysis of the efficiency achievable in various settings without % analysis of the efficiency achievable in various settings without
getting bogged down in inessential implementation details, we shall % getting bogged down in inessential implementation details, we shall
work concretely and operationally with the languages in question, % work concretely and operationally with the languages in question,
using a CEK-style abstract machine semantics as our basic model of % using a CEK-style abstract machine semantics as our basic model of
execution time, and with some specific programs in these languages. % execution time, and with some specific programs in these languages.
In the first instance, we formulate our results as a comparison % In the first instance, we formulate our results as a comparison
between a purely functional base language (a version of call-by-value % between a purely functional base language (a version of call-by-value
PCF) and an extension with first-class control; we then indicate how % PCF) and an extension with first-class control; we then indicate how
these results can be extended to base languages with other features % these results can be extended to base languages with other features
such as mutable state. % such as mutable state.
In summary, our purpose is to exhibit an efficiency gap which, in our \paragraph{Relation to prior work} This chapter is based entirely on
view, manifests a fundamental feature of the programming language the following previously published paper.
landscape, challenging a common assumption that all real-world \begin{enumerate}
programming languages are essentially `equivalent' from an asymptotic \item[~] \bibentry{HillerstromLL20}
point of view. We believe that such results are important not only \end{enumerate}
for a rounded understanding of the relative merits of existing The contents of Sections~\ref{sec:calculi},
languages, but also for informing future language design. \ref{sec:abstract-machine-semantics}, \ref{sec:generic-search},
\ref{sec:pure-counting}, \ref{sec:robustness}, and
\ref{sec:experiments} are almost verbatim copies of Sections 3, 4, 5,
6, 7, and 8 of the above paper. I have made a few stylistic
adjustments to make the Sections fit with the rest of this
dissertation.
For their convenience as structured delimited control operators we % In summary, our purpose is to exhibit an efficiency gap which, in our
adopt effect handlers as our universal control abstraction of choice, % view, manifests a fundamental feature of the programming language
but our results adapt mutatis mutandis to other first-class control % landscape, challenging a common assumption that all real-world
abstractions such as `call/cc'~\cite{AbelsonHAKBOBPCRFRHSHW85}, `control' % programming languages are essentially `equivalent' from an asymptotic
($\mathcal{F}$) and 'prompt' ($\textbf{\#}$)~\citep{Felleisen88}, or % point of view. We believe that such results are important not only
`shift' and `reset'~\citep{DanvyF90}. % for a rounded understanding of the relative merits of existing
% languages, but also for informing future language design.
The rest of the paper is structured as follows. % For their convenience as structured delimited control operators we
\begin{itemize} % adopt effect handlers as our universal control abstraction of choice,
\item Section~\ref{sec:handlers-primer} provides an introduction to % but our results adapt mutatis mutandis to other first-class control
effect handlers as a programming abstraction. % abstractions such as `call/cc'~\cite{AbelsonHAKBOBPCRFRHSHW85}, `control'
\item Section~\ref{sec:calculi} presents a PCF-like language % ($\mathcal{F}$) and 'prompt' ($\textbf{\#}$)~\citep{Felleisen88}, or
$\BPCF$ and its extension $\HPCF$ with effect handlers. % `shift' and `reset'~\citep{DanvyF90}.
\item Section~\ref{sec:abstract-machine-semantics} defines abstract
machines for $\BPCF$ and $\HPCF$, yielding a runtime cost model. % The rest of the paper is structured as follows.
\item Section~\ref{sec:generic-search} introduces generic count and % \begin{itemize}
some associated machinery, and presents an implementation in % \item Section~\ref{sec:handlers-primer} provides an introduction to
$\HPCF$ with runtime $\BigO(2^n)$. % effect handlers as a programming abstraction.
\item Section~\ref{sec:pure-counting} establishes that any generic % \item Section~\ref{sec:calculi} presents a PCF-like language
count implementation in $\BCalc$ must have runtime $\Omega(n2^n)$. % $\BPCF$ and its extension $\HPCF$ with effect handlers.
\item Section~\ref{sec:robustness} shows that our results scale to % \item Section~\ref{sec:abstract-machine-semantics} defines abstract
richer settings including support for a wider class of predicates, % machines for $\BPCF$ and $\HPCF$, yielding a runtime cost model.
the adaptation from generic count to generic search, and an % \item Section~\ref{sec:generic-search} introduces generic count and
extension of the base language with state. % some associated machinery, and presents an implementation in
\item Section~\ref{sec:experiments} evaluates implementations of % $\HPCF$ with runtime $\BigO(2^n)$.
generic search based on $\BPCF$ and $\HPCF$ in Standard ML. % \item Section~\ref{sec:pure-counting} establishes that any generic
\item Section \ref{sec:conclusions} concludes. % count implementation in $\BCalc$ must have runtime $\Omega(n2^n)$.
\end{itemize} % \item Section~\ref{sec:robustness} shows that our results scale to
% % richer settings including support for a wider class of predicates,
The languages $\BPCF$ and $\HPCF$ are rather minimal versions of % the adaptation from generic count to generic search, and an
previously studied systems --- we only include the machinery needed % extension of the base language with state.
for illustrating the generic search efficiency phenomenon. % \item Section~\ref{sec:experiments} evaluates implementations of
% % generic search based on $\BPCF$ and $\HPCF$ in Standard ML.
Auxiliary results are included in the appendices of the extended % \item Section \ref{sec:conclusions} concludes.
version of the paper~\citep{HillerstromLL20}. % \end{itemize}
% %
% The languages $\BPCF$ and $\HPCF$ are rather minimal versions of
% previously studied systems --- we only include the machinery needed
% for illustrating the generic search efficiency phenomenon.
% %
% Auxiliary results are included in the appendices of the extended
% version of the paper~\citep{HillerstromLL20}.
%% %%
%% Base calculus %% Base calculus
%% %%
\section{Calculi} \section{Calculi}
\label{sec:calculi} \label{sec:calculi}
In this section, we present our base language $\BPCF$ and its In this section, we present a base language $\BPCF$ and its extension
extension with effect handlers $\HPCF$. with effect handlers $\HPCF$, both of which amounts to simply-typed
variations of $\BCalc$ and $\HCalc$,
respectively. Sections~\ref{sec:base-calculus}--\ref{sec:handler-machine}
essentially recast the developments of
Chapters~\ref{ch:base-language}, \ref{ch:unary-handlers}, and
\ref{ch:abstract-machine} to fit the calculi $\BPCF$ and $\HPCF$. I
reproduce the details here, even though, they are mostly the same as
in the previous chapters save for a few tricks such as a crucial
design decision in Section~\ref{sec:handlers-calculus} which makes it
possible to implement continuation reification as a constant time
operation.
\subsection{Base Calculus} \subsection{Base calculus}
\label{sec:base-calculus}
The base calculus $\BPCF$ is a fine-grain The base calculus $\BPCF$ is a fine-grain
call-by-value~\cite{LevyPT03} variation of PCF~\cite{Plotkin77}. call-by-value~\cite{LevyPT03} variation of PCF~\cite{Plotkin77}.
% %
@@ -15114,7 +15138,7 @@ The syntax of $\BCalc$ is as follows.
{\noindent {\noindent
\begin{syntax} \begin{syntax}
\slab{Types} &A,B,C,D\in\TypeCat &::= & \Nat \mid \One \mid A \to B \mid A \times B \mid A + B \\ \slab{Types} &A,B,C,D\in\TypeCat &::= & \Nat \mid \One \mid A \to B \mid A \times B \mid A + B \\
\slab{Type\textrm{ }Environments} &\Gamma\in\CtxCat &::= & \cdot \mid \Gamma, x:A \\ \slab{Type\textrm{ }environments} &\Gamma\in\TyEnvCat &::= & \cdot \mid \Gamma, x:A \\
\slab{Values} &V,W\in\ValCat &::= & x \mid k \mid c \mid \lambda x^A .\, M \mid \Rec \; f^{A \to B}\, x.M \\ \slab{Values} &V,W\in\ValCat &::= & x \mid k \mid c \mid \lambda x^A .\, M \mid \Rec \; f^{A \to B}\, x.M \\
& &\mid& \Unit \mid \Record{V, W} \mid (\Inl\, V)^B \mid (\Inr\, W)^A\\ & &\mid& \Unit \mid \Record{V, W} \mid (\Inl\, V)^B \mid (\Inr\, W)^A\\
% & & & % & & &
@@ -15281,7 +15305,7 @@ The constants have the following types.
\begin{figure*} \begin{figure*}
\begin{reductions} \begin{reductions}
\semlab{App} & (\lambda x^A . \, M) V &\reducesto& M[V/x] \\ \semlab{App} & (\lambda x^A . \, M) V &\reducesto& M[V/x] \\
\semlab{App\textrm{-}Rec} & (\Rec\; f^A \,x.\, M) V &\reducesto& M[(\Rec\;f^A\,x .\,M)/f,V/x]\\ \semlab{AppRec} & (\Rec\; f^A \,x.\, M) V &\reducesto& M[(\Rec\;f^A\,x .\,M)/f,V/x]\\
\semlab{Const} & c~V &\reducesto& \Return\;(\const{c}\,(V)) \\ \semlab{Const} & c~V &\reducesto& \Return\;(\const{c}\,(V)) \\
\semlab{Split} & \Let \; \Record{x,y} = \Record{V,W} \; \In \; N &\reducesto& N[V/x,W/y] \\ \semlab{Split} & \Let \; \Record{x,y} = \Record{V,W} \; \In \; N &\reducesto& N[V/x,W/y] \\
\semlab{Case\textrm{-}inl} & \semlab{Case\textrm{-}inl} &
@@ -15310,8 +15334,8 @@ on closed values. The reduction relation $\reducesto$ is defined on
computation terms. The statement $M \reducesto N$ reads: term $M$ computation terms. The statement $M \reducesto N$ reads: term $M$
reduces to term $N$ in one step. reduces to term $N$ in one step.
% %
We write $R^+$ for the transitive closure of relation $R$ and $R^*$ % We write $R^+$ for the transitive closure of relation $R$ and $R^*$
for the reflexive, transitive closure of relation $R$. % for the reflexive, transitive closure of relation $R$.
\paragraph{Notation} \paragraph{Notation}
% %
@@ -15372,7 +15396,7 @@ We use the standard encoding of booleans as a sum:
% %
% Handlers extension % Handlers extension
% %
\subsection{Handler Calculus} \subsection{Handler calculus}
\label{sec:handlers-calculus} \label{sec:handlers-calculus}
We now define $\HCalc$ as an extension of $\BCalc$. We now define $\HCalc$ as an extension of $\BCalc$.
@@ -15420,6 +15444,17 @@ forwarding:
\[ \[
\{\OpCase{\ell}{p}{r} \mapsto \Let\; x \revto \Do \; \ell \, p \;\In\; r \, x\}. \{\OpCase{\ell}{p}{r} \mapsto \Let\; x \revto \Do \; \ell \, p \;\In\; r \, x\}.
\] \]
%
\paragraph{Remark}
This convention makes effect forwarding explicit, whereas in
$\HCalc$ effect forwarding was implicit. As we shall see soon, an
important semantic consequence of making effect forwarding explicit
is that the abstract machine model in
Section~\ref{sec:handler-machine} has no rule for effect forwarding
as it instead happens as a sequence of explicit $\Do$ invocations in
the term language. As a result, we become able to reason about
continuation reification as a constant time operation, because a
$\Do$ invocation will just reify the top-most continuation frame.\medskip
\begin{figure*} \begin{figure*}
\raggedright \raggedright
@@ -15437,15 +15472,15 @@ forwarding:
\textbf{Handlers} \textbf{Handlers}
\begin{mathpar} \begin{mathpar}
\inferrule*[Lab=\tylab{Handler}] \inferrule*[Lab=\tylab{Handler}]
{ \hret = \{\Val \; x \mapsto M\} \\ { \hret = \{\Return \; x \mapsto M\} \\
[\hell = \{\ell \, p \; r \mapsto N_\ell\}]_{\ell \in dom(\Sigma)} \\\\ [\hell = \{\OpCase{\ell}{p}{r} \mapsto N_\ell\}]_{\ell \in dom(\Sigma)} \\\\
\typ{\Gamma, x : C}{M : D} \\ \typ{\Gamma, x : C}{M : D} \\
[\typ{\Gamma, p : A_\ell, r : B_\ell \to D}{N_\ell : D}]_{(\ell : A_\ell \to B_\ell) \in \Sigma} [\typ{\Gamma, p : A_\ell, r : B_\ell \to D}{N_\ell : D}]_{(\ell : A_\ell \to B_\ell) \in \Sigma}
} }
{{\Gamma} \vdash {H : C \Rightarrow D}} {{\Gamma} \vdash {H : C \Rightarrow D}}
\end{mathpar} \end{mathpar}
\caption{Additional typing rules for $\HPCF$} \caption{Additional typing rules for $\HPCF$.}
\label{fig:typing-handlers} \label{fig:typing-handlers}
\end{figure*} \end{figure*}
@@ -15489,7 +15524,7 @@ for handling operation invocations.
\text{where } \hret = \{ \Return \; x \mapsto N \} \smallskip\\ \text{where } \hret = \{ \Return \; x \mapsto N \} \smallskip\\
\semlab{Op} & \Handle \; \EC[\Do \; \ell \, V] \; \With \; H &\reducesto& N[V/p,(\lambda y.\Handle \; \EC[\Return \; y] \; \With \; H)/r],\\ \semlab{Op} & \Handle \; \EC[\Do \; \ell \, V] \; \With \; H &\reducesto& N[V/p,(\lambda y.\Handle \; \EC[\Return \; y] \; \With \; H)/r],\\
\multicolumn{4}{@{}r@{}}{ \multicolumn{4}{@{}r@{}}{
\hfill\text{where } \hell = \{ \ell\, p \; r \mapsto N \} \hfill\text{where } \hell = \{ \OpCase{\ell}{p}{r} \mapsto N \}
} }
\end{reductions}}% \end{reductions}}%
% %
@@ -15558,7 +15593,7 @@ Readers familiar with effect handlers may wonder why our handler
calculus does not include an effect type system. calculus does not include an effect type system.
% %
As types frame the comparison of programs between languages, we As types frame the comparison of programs between languages, we
require that types be fixed across languages; hence $\HCalc$ does not require that types be fixed across languages; hence $\HPCF$ does not
include effect types. include effect types.
% %
Future work includes reconciling effect typing with our approach to Future work includes reconciling effect typing with our approach to
@@ -15573,8 +15608,10 @@ For each calculus we have given a \emph{small-step operational
semantics} which uses a substitution model for evaluation. Whilst semantics} which uses a substitution model for evaluation. Whilst
this model is semantically pleasing, it falls short of providing a this model is semantically pleasing, it falls short of providing a
realistic account of practical computation as substitution is an realistic account of practical computation as substitution is an
expensive operation. We now develop a more practical model of expensive operation. Instead we shall use a slightly simpler variation
computation based on an \emph{abstract machine semantics}. of the abstract machine from Chapter~\ref{ch:abstract-machine} as it
provides a more practical model of computation (it is simpler, because
the source language is simpler).
\subsection{Base machine} \subsection{Base machine}
\label{sec:base-abstract-machine} \label{sec:base-abstract-machine}
@@ -15583,16 +15620,12 @@ computation based on an \emph{abstract machine semantics}.
\newcommand{\EConf}{\dec{EConf}} \newcommand{\EConf}{\dec{EConf}}
\newcommand{\MVal}{\dec{MVal}} \newcommand{\MVal}{\dec{MVal}}
We choose a \emph{CEK}-style abstract machine The base machine operates on configurations of the form
semantics~\citep{FelleisenF86} for \BCalc{} based on that of $\cek{M \mid \gamma \mid \sigma}$. The first component contains the
\citet{HillerstromLA20}. computation currently being evaluated. The second component contains
% the environment $\gamma$ which binds free variables. The third
The CEK machine operates on configurations which are triples of the component contains the continuation which instructs the machine how to
form $\cek{M \mid \gamma \mid \sigma}$. The first component contains proceed once evaluation of the current computation is complete.
the computation currently being evaluated. The second component
contains the environment $\gamma$ which binds free variables. The
third component contains the continuation which instructs the machine
how to proceed once evaluation of the current computation is complete.
% %
The syntax of abstract machine states is as follows. The syntax of abstract machine states is as follows.
{ {
@@ -15600,10 +15633,10 @@ The syntax of abstract machine states is as follows.
\slab{Configurations} & \conf \in \Conf &::=& \cek{M \mid \env \mid \sigma} \\ \slab{Configurations} & \conf \in \Conf &::=& \cek{M \mid \env \mid \sigma} \\
% & &\mid& \cekop{M \mid \env \mid \kappa \mid \kappa'} \\ % & &\mid& \cekop{M \mid \env \mid \kappa \mid \kappa'} \\
\slab{Environments} &\env \in \Env &::=& \emptyset \mid \env[x \mapsto v] \\ \slab{Environments} &\env \in \Env &::=& \emptyset \mid \env[x \mapsto v] \\
\slab{Machine values} &v, w \in \MVal &::= & x \mid n \mid c \mid \Unit \mid \Record{v, w} \\ \slab{Machine\textrm{ }values} &v, w \in \MValCat &::= & x \mid n \mid c \mid \Unit \mid \Record{v, w} \\
& &\mid& (\env, \lambda x^A .\, M) \mid (\env, \Rec\, f^{A \to B}\,x . \, M) & &\mid& (\env, \lambda x^A .\, M) \mid (\env, \Rec\, f^{A \to B}\,x . \, M)\\
\mid (\Inl\, v)^B \mid (\Inr\,w)^A \\ & &\mid& (\Inl\, v)^B \mid (\Inr\,w)^A \\
\slab{Pure continuations} &\sigma \in \PureCont &::=& \nil \mid (\env, x, N) \cons \sigma \\ \slab{Pure\textrm{ }continuations} &\sigma \in \MPContCat &::=& \nil \mid (\env, x, N) \cons \sigma \\
\end{syntax}}% \end{syntax}}%
% %
Values consist of function closures, constants, pairs, and left or Values consist of function closures, constants, pairs, and left or
@@ -15622,15 +15655,17 @@ pattern matching to deconstruct pure continuations.
\begin{figure*} \begin{figure*}
\raggedright \raggedright
\textbf{Transition relation} \textbf{Transition relation} $\qquad\qquad~~\,\stepsto\, \subseteq\! \MConfCat \times \MConfCat$
\begin{reductions} \[
\bl
\ba{@{}l@{\quad}r@{~}c@{~}l@{~~}l@{}}
% App % App
\mlab{App} & \cek{ V\;W \mid \env \mid \sigma} \mlab{App} & \cek{ V\;W \mid \env \mid \sigma}
&\stepsto& \cek{ M \mid \env'[x \mapsto \val{W}{\env}] \mid \sigma},\\ &\stepsto& \cek{ M \mid \env'[x \mapsto \val{W}{\env}] \mid \sigma},\\
&&& \quad\text{ if }\val{V}{\env} = (\env', \lambda x^A . \, M)\\ &&& \quad\text{ if }\val{V}{\env} = (\env', \lambda x^A . \, M)\\
% App rec % App rec
\mlab{Rec} & \cek{ V\;W \mid \env \mid \sigma} \mlab{AppRec} & \cek{ V\;W \mid \env \mid \sigma}
&\stepsto& \cek{ M \mid \env'[\bl &\stepsto& \cek{ M \mid \env'[\bl
f \mapsto (\env', \Rec\,f^{A \to B}\,x. M), \\ f \mapsto (\env', \Rec\,f^{A \to B}\,x. M), \\
x \mapsto \val{W}{\env}] \mid \sigma},\\ x \mapsto \val{W}{\env}] \mid \sigma},\\
@@ -15641,6 +15676,8 @@ pattern matching to deconstruct pure continuations.
\mlab{Const} & \cek{ V~W \mid \env \mid \sigma} \mlab{Const} & \cek{ V~W \mid \env \mid \sigma}
&\stepsto& \cek{ \Return\; (\const{c}\,(\val{W}\env)) \mid \env \mid \sigma},\\ &\stepsto& \cek{ \Return\; (\const{c}\,(\val{W}\env)) \mid \env \mid \sigma},\\
&&& \quad\text{ if }\val{V}{\env} = c \\ &&& \quad\text{ if }\val{V}{\env} = c \\
\ea \medskip\\
\ba{@{}l@{\quad}r@{~}c@{~}l@{~~}l@{}}
\mlab{Split} & \cek{ \Let \; \Record{x,y} = V \; \In \; N \mid \env \mid \sigma} \mlab{Split} & \cek{ \Let \; \Record{x,y} = V \; \In \; N \mid \env \mid \sigma}
&\stepsto& \cek{ N \mid \env[x \mapsto v, y \mapsto w] \mid \sigma}, \\ &\stepsto& \cek{ N \mid \env[x \mapsto v, y \mapsto w] \mid \sigma}, \\
&&& \quad\text{ if }\val{V}{\env} = \Record{v; w} \\ &&& \quad\text{ if }\val{V}{\env} = \Record{v; w} \\
@@ -15650,52 +15687,54 @@ pattern matching to deconstruct pure continuations.
\cekl \Case\; V\, \{&\Inl\, x \mapsto M; \\ \cekl \Case\; V\, \{&\Inl\, x \mapsto M; \\
&\Inr\, y \mapsto N\} \mid \env \mid \sigma \cekr \\ &\Inr\, y \mapsto N\} \mid \env \mid \sigma \cekr \\
\ea \ea
&\stepsto& \cek{ M \mid \env[x \mapsto v] \mid \sigma},\\ &\stepsto& \ba[t]{@{~}l}\cek{ M \mid \env[x \mapsto v] \mid \sigma},\\
&&& \quad\text{ if }\val{V}{\env} = \Inl\, v \\ \quad\text{ if }\val{V}{\env} = \Inl\, v\ea \\
% Case right % Case right
\mlab{CaseR} & \ba{@{}l@{}l@{}} \mlab{CaseR} & \ba{@{}l@{}l@{}}
\cekl \Case\; V\, \{&\Inl\, x \mapsto M; \\ \cekl \Case\; V\, \{&\Inl\, x \mapsto M; \\
&\Inr\, y \mapsto N\} \mid \env \mid \sigma \cekr \\ &\Inr\, y \mapsto N\} \mid \env \mid \sigma \cekr \\
\ea \ea
&\stepsto& \cek{ N \mid \env[y \mapsto v] \mid \sigma},\\ &\stepsto& \ba[t]{@{~}l}\cek{ N \mid \env[y \mapsto v] \mid \sigma},\\
&&& \quad\text{ if }\val{V}{\env} = \Inr\, v \\ \quad\text{ if }\val{V}{\env} = \Inr\, v \ea\\
% Let - eval M % Let - eval M
\mlab{Let} & \cek{ \Let \; x \revto M \; \In \; N \mid \env \mid \sigma} \mlab{Let} & \cek{ \Let \; x \revto M \; \In \; N \mid \env \mid \sigma}
&\stepsto& \cek{ M \mid \env \mid (\env,x,N) \cons \sigma} \\ &\stepsto& \cek{ M \mid \env \mid (\env,x,N) \cons \sigma} \\
% Return - let binding % Return - let binding
\mlab{RetCont} &\cek{ \Return \; V \mid \env \mid (\env',x,N) \cons \sigma} \mlab{PureCont} &\cek{ \Return \; V \mid \env \mid (\env',x,N) \cons \sigma}
&\stepsto& \cek{ N \mid \env'[x \mapsto \val{V}{\env}] \mid \sigma} \\ &\stepsto& \cek{ N \mid \env'[x \mapsto \val{V}{\env}] \mid \sigma} \\
\end{reductions} \ea
\el
\]
\textbf{Value interpretation} \textbf{Value interpretation} $\qquad\qquad~~\,\val{-} : \ValCat \times \MEnvCat \to \MValCat$
\[ \[
\bl \bl
\begin{eqs} \begin{eqs}
\val{x}{\env} &=& \env(x) \\ \val{x}{\env} &\defas& \env(x) \\
\val{\Unit{}}{\env} &=& \Unit{} \\ \val{\Unit{}}{\env} &\defas& \Unit{} \\
\end{eqs} \end{eqs}
\qquad\qquad\qquad \qquad\qquad
\begin{eqs} \begin{eqs}
\val{n}{\env} &=& n \\ \val{n}{\env} &\defas& n \\
\val{c}\env &=& c \\ \val{c}\env &\defas& c \\
\end{eqs} \end{eqs}
\qquad\qquad\qquad \qquad\qquad
\begin{eqs} \begin{eqs}
\val{\lambda x^A.M}{\env} &=& (\env, \lambda x^A.M) \\ \val{\lambda x^A.M}{\env} &\defas& (\env, \lambda x^A.M) \\
\val{\Rec\, f^{A \to B}\, x.M}{\env} &=& (\env, \Rec\,f^{A \to B}\, x.M) \\ \val{\Rec\, f^{A \to B}\, x.M}{\env} &\defas& (\env, \Rec\,f^{A \to B}\, x.M) \\
\end{eqs} \end{eqs}
\medskip \\ \medskip \\
\begin{eqs} \begin{eqs}
\val{\Record{V, W}}{\env} &=& \Record{\val{V}{\env}, \val{W}{\env}} \\ \val{\Record{V, W}}{\env} &\defas& \Record{\val{V}{\env}, \val{W}{\env}} \\
\end{eqs} \end{eqs}
\qquad\qquad\qquad \qquad\qquad
\ba{@{}r@{~}c@{~}l@{}} \ba{@{}r@{~}c@{~}l@{}}
\val{(\Inl\, V)^B}{\env} &=& (\Inl\; \val{V}{\env})^B \\ \val{(\Inl\, V)^B}{\env} &\defas& (\Inl\; \val{V}{\env})^B \\
\val{(\Inr\, V)^A}{\env} &=& (\Inr\; \val{V}{\env})^A \\ \val{(\Inr\, V)^A}{\env} &\defas& (\Inr\; \val{V}{\env})^A \\
\ea \ea
\el \el
\] \]
@@ -15714,14 +15753,14 @@ The machine is initialised by placing a term in a configuration
alongside the empty environment ($\emptyset$) and identity alongside the empty environment ($\emptyset$) and identity
pure continuation ($\nil$). pure continuation ($\nil$).
% %
The rules (\mlab{App}), (\mlab{Rec}), (\mlab{Const}), (\mlab{Split}), The rules (\mlab{App}), (\mlab{AppRec}), (\mlab{Const}),
(\mlab{CaseL}), and (\mlab{CaseR}) eliminate values. (\mlab{Split}), (\mlab{CaseL}), and (\mlab{CaseR}) eliminate values.
% %
The (\mlab{Let}) rule extends the current pure continuation with let The (\mlab{Let}) rule extends the current pure continuation with let
bindings. bindings.
% %
The (\mlab{RetCont}) rule extends the environment in the top frame of The (\mlab{PureCont}) rule pops the top frame of the pure continuation
the pure continuation with a returned value. and extends the environment with the returned value.
% %
Given an input of a well-typed closed computation term $\typ{}{M : Given an input of a well-typed closed computation term $\typ{}{M :
A}$, the machine will either diverge or return a value of type $A$. A}$, the machine will either diverge or return a value of type $A$.
@@ -15738,34 +15777,43 @@ $\BCalc$; most transitions correspond directly to $\beta$-reductions,
but $\mlab{Let}$ performs an administrative step to bring the but $\mlab{Let}$ performs an administrative step to bring the
computation $M$ into evaluation position. computation $M$ into evaluation position.
% %
We formally state and prove the correspondence in The proof of correctness is similar to the proof of
Appendix~\ref{sec:base-machine-correctness}, relying on an Theorem~\ref{thm:handler-simulation} and the required proof gadgetry
inverse map $\inv{-}$ from configurations to is the same. The full details are published in Appendix A of
terms~\citep{HillerstromLA20}. \citet{HillerstromLL20a}.
% We formally state and prove the correspondence in
% Appendix~\ref{sec:base-machine-correctness}, relying on an
% inverse map $\inv{-}$ from configurations to
% terms~\citep{HillerstromLA20}.
% %
\newcommand{\contapp}[2]{#1 #2} \newcommand{\contapp}[2]{#1 #2}
\newcommand{\contappp}[2]{#1(#2)} \newcommand{\contappp}[2]{#1(#2)}
\subsection{Handler machine} \subsection{Handler machine}
\label{sec:handler-machine}
\newcommand{\HClosure}{\dec{HClo}} \newcommand{\HClosure}{\dec{HClo}}
We now enrich the $\BPCF$ machine to a $\HPCF$ machine.
% %
We extend the syntax as follows. We now extend the $\BPCF$ machine with functionality to evaluate
$\HPCF$ terms. The resulting machine is almost the same as the machine
in Chapter~\ref{ch:abstract-machine}, though, this machine supports
only deep handlers.
%
The syntax is extended as follows.
% %
{ {
\begin{syntax} \begin{syntax}
\slab{Configurations} &\conf \in \Conf &::=& \cek{M \mid \env \mid \kappa}\\ \slab{Configurations} &\conf \in \Conf &::=& \cek{M \mid \env \mid \kappa}\\
\slab{Resumptions} &\rho \in \dec{Res} &::=& (\sigma, \chi)\\ \slab{Resumptions} &\rho \in \dec{Res} &::=& (\sigma, \chi)\\
\slab{Continuations} &\kappa \in \Cont &::=& \nil \mid \rho \cons \kappa\\ \slab{Continuations} &\kappa \in \MGContCat &::=& \nil \mid \rho \cons \kappa\\
\slab{Handler\textrm{ }closures} &\chi \in \HClosure &::=& (\env, H) \\ \slab{Handler\textrm{ }closures} &\chi \in \MGFrameCat &::=& (\env, H) \\
\slab{Machine\textrm{ }values} &v, w \in \MVal &::=& \cdots \mid \rho \\ \slab{Machine\textrm{ }values} &v, w \in \MValCat &::=& \cdots \mid \rho \\
\end{syntax}}% \end{syntax}}%
% %
The notion of configurations changes slightly in that the continuation The notion of configurations changes slightly in that the continuation
component is replaced by a generalised continuation component is replaced by a generalised continuation
$\kappa \in \Cont$~\cite{HillerstromLA20}; a continuation is now a $\kappa \in \MGContCat$; a continuation is now a list of
list of resumptions. A resumption is a pair of a pure continuation (as resumptions. A resumption is a pair of a pure continuation (as in the
in the base machine) and a handler closure ($\chi$). base machine) and a handler closure ($\chi$).
% %
A handler closure consists of an environment and a handler definition, A handler closure consists of an environment and a handler definition,
where the former binds the free variables that occur in the latter. where the former binds the free variables that occur in the latter.
@@ -15776,7 +15824,7 @@ identity handler closure:
% %
{ {
\[ \[
\kappa_0 \defas [(\nil, (\emptyset, \{\Val\;x \mapsto x\}))] \kappa_0 \defas [(\nil, (\emptyset, \{\Return\;x \mapsto x\}))]
\]}% \]}%
% %
Machine values are augmented to include resumptions as an operation Machine values are augmented to include resumptions as an operation
@@ -15786,7 +15834,7 @@ clause).
% %
The handler machine adds transition rules for handlers, and modifies The handler machine adds transition rules for handlers, and modifies
$(\mlab{Let})$ and $(\mlab{RetCont})$ from the base machine to account $(\mlab{Let})$ and $(\mlab{PureCont})$ from the base machine to account
for the richer continuation for the richer continuation
structure. Figure~\ref{fig:abstract-machine-semantics-handlers} structure. Figure~\ref{fig:abstract-machine-semantics-handlers}
depicts the new and modified rules. depicts the new and modified rules.
@@ -15794,10 +15842,10 @@ depicts the new and modified rules.
The $(\mlab{Handle})$ rule pushes a handler closure along with an The $(\mlab{Handle})$ rule pushes a handler closure along with an
empty pure continuation onto the continuation stack. empty pure continuation onto the continuation stack.
% %
The $(\mlab{RetHandler})$ rule transfers control to the success clause The $(\mlab{GenCont})$ rule transfers control to the success clause
of the current handler once the pure continuation is empty. of the current handler once the pure continuation is empty.
% %
The $(\mlab{Handle-Op})$ rule transfers control to the matching The $(\mlab{Op})$ rule transfers control to the matching
operation clause on the topmost handler, and during the process it operation clause on the topmost handler, and during the process it
reifies the handler closure. Finally, the $(\mlab{Resume})$ rule reifies the handler closure. Finally, the $(\mlab{Resume})$ rule
applies a reified handler closure, by pushing it onto the continuation applies a reified handler closure, by pushing it onto the continuation
@@ -15810,7 +15858,9 @@ value or it gets stuck on an unhandled operation.
\raggedright \raggedright
\textbf{Transition relation} \textbf{Transition relation}
\begin{reductions} \[
\bl
\ba{@{}l@{~}r@{~}c@{~}l@{~~}l@{}}
% Resume resumption % Resume resumption
\mlab{Resume} & \cek{ V\;W \mid \env \mid \kappa} \mlab{Resume} & \cek{ V\;W \mid \env \mid \kappa}
&\stepsto& \cek{ \Return \; W \mid \env \mid (\sigma, \chi) \cons \kappa},\\ &\stepsto& \cek{ \Return \; W \mid \env \mid (\sigma, \chi) \cons \kappa},\\
@@ -15821,7 +15871,7 @@ value or it gets stuck on an unhandled operation.
&\stepsto& \cek{ M \mid \env \mid ((\env,x,N) \cons \sigma, \chi) \cons \kappa} \\ &\stepsto& \cek{ M \mid \env \mid ((\env,x,N) \cons \sigma, \chi) \cons \kappa} \\
% Apply (machine) continuation - let binding % Apply (machine) continuation - let binding
\mlab{RetCont} &\cek{ \Return \; V \mid \env \mid ((\env',x,N) \cons \sigma, \chi) \cons \kappa} \mlab{PureCont} &\cek{ \Return \; V \mid \env \mid ((\env',x,N) \cons \sigma, \chi) \cons \kappa}
&\stepsto& \cek{ N \mid \env'[x \mapsto \val{V}{\env}] \mid (\sigma, \chi) \cons \kappa} \\ &\stepsto& \cek{ N \mid \env'[x \mapsto \val{V}{\env}] \mid (\sigma, \chi) \cons \kappa} \\
% Handle % Handle
@@ -15829,21 +15879,23 @@ value or it gets stuck on an unhandled operation.
&\stepsto& \cek{ M \mid \env \mid (\nil, (\env, H)) \cons \kappa} \\ &\stepsto& \cek{ M \mid \env \mid (\nil, (\env, H)) \cons \kappa} \\
% Return - handler % Return - handler
\mlab{RetHandler} & \cek{ \Return \; V \mid \env \mid (\nil, (\env',H)) \cons \kappa} \mlab{GenCont} & \cek{ \Return \; V \mid \env \mid (\nil, (\env',H)) \cons \kappa}
&\stepsto& \cek{ M \mid \env'[x \mapsto \val{V}{\env}] \mid \kappa},\\ &\stepsto& \cek{ M \mid \env'[x \mapsto \val{V}{\env}] \mid \kappa},\\
&&&\quad\text{ if } \hret = \{\Val\; x \mapsto M\} \\ &&&\quad\text{ if } \hret = \{\Val\; x \mapsto M\} \\
% Handle op % Handle op
\mlab{Handle-Op} & \cek{ \Do \; \ell~V \mid \env \mid (\sigma, (\env', H)) \cons \kappa } \mlab{Op} & \cek{ \Do \; \ell~V \mid \env \mid (\sigma, (\env', H)) \cons \kappa }
&\stepsto& \cek{ M \mid \env'[\bl &\stepsto& \cek{ M \mid \env'[\bl
p \mapsto \val{V}\env, \\ p \mapsto \val{V}\env, \\
r \mapsto (\sigma, (\env', H))] \mid \kappa }, \\ r \mapsto (\sigma, (\env', H))] \mid \kappa }, \\
\el \\ \el \\
&&&\quad\bl &&&\quad\bl
\text{ if } \ell : A \to B \in \Sigma\\ \text{ if } \ell : A \to B \in \Sigma\\
\text{ and } \hell = \{\ell\; p \; r \mapsto M\} \text{ and } \hell = \{\OpCase{\ell}{p}{r} \mapsto M\}
\el\\ \el\\
\end{reductions} \ea
\el
\]
\caption{Abstract machine semantics for $\HPCF$.} \caption{Abstract machine semantics for $\HPCF$.}
\label{fig:abstract-machine-semantics-handlers} \label{fig:abstract-machine-semantics-handlers}
\end{figure*} \end{figure*}
@@ -15853,15 +15905,17 @@ value or it gets stuck on an unhandled operation.
The handler machine faithfully simulates the operational semantics of The handler machine faithfully simulates the operational semantics of
$\HPCF$. $\HPCF$.
% %
Extending the result for the base machine, we formally state and prove The proof of correctness is almost a carbon copy of the proof of
the correspondence in Theorem~\ref{thm:handler-simulation}. The full details are published
Appendix~\ref{sec:handler-machine-correctness}. in Appendix B of \citet{HillerstromLL20a}.% Extending the result for
% the base machine, we formally state and prove the correspondence in
% Appendix~\ref{sec:handler-machine-correctness}.
\subsection{Realisability and Asymptotic Complexity} \subsection{Realisability and asymptotic complexity}
\label{sec:realisability} \label{sec:realisability}
As witnessed by the work of \citet{HillerstromL18} the machine As discussed in Section~\ref{subsec:machine-realisability} the machine
structures are readily realisable using standard persistent functional is readily realisable using standard persistent functional data
data structures. structures.
% %
Pure continuations on the base machine and generalised continuations Pure continuations on the base machine and generalised continuations
on the handler machine can be implemented using linked lists with a on the handler machine can be implemented using linked lists with a
@@ -18027,6 +18081,22 @@ However, the effectful implementation runs between 2 and 14 times as
fast with SML/NJ compared with MLton. fast with SML/NJ compared with MLton.
\section{Related work} \section{Related work}
Relatively few results of character of the result in this chapter have
thus far been established in literature. \citet{Pippenger96} gives an
example of an `online' operation on infinite sequences of atomic
symbols (essentially a function from streams to streams) such that the
first $n$ output symbols can be produced within time $\BigO(n)$ if one
is working in an effectful version of Lisp (one which allows mutation
of cons pairs) but with a worst-case runtime no better than
$\Omega(n \log n)$ for any implementation in pure Lisp (without such
mutation). This example was reconsidered by \citet{BirdJdM97} who
showed that the same speedup can be achieved in a pure language by
using lazy evaluation. \citet{Jones01} explores the approach of
manifesting expressivity and efficiency differences between certain
languages by artificially restricting attention to `cons-free'
programs; in this setting, the classes of representable first-order
functions for the various languages are found to coincide with some
well-known complexity classes.
\part{Conclusions} \part{Conclusions}
\label{p:conclusions} \label{p:conclusions}