My PhD dissertation at the University of Edinburgh, Scotland
https://www.dhil.net/research/
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
10631 lines
434 KiB
10631 lines
434 KiB
%% 12pt font size, PhD thesis, LFCS, print twosided, new chapters on right page
|
|
\documentclass[12pt,phd,lfcs,twoside,openright,logo,leftchapter,normalheadings]{infthesis}
|
|
\shieldtype{0}
|
|
|
|
%% Packages
|
|
\usepackage[utf8]{inputenc} % Enable UTF-8 typing
|
|
\usepackage[british]{babel} % British English
|
|
\usepackage[pdfusetitle,breaklinks]{hyperref} % Interactive PDF
|
|
\usepackage{url}
|
|
\usepackage[sort&compress,square,numbers]{natbib} % Bibliography
|
|
\usepackage{bibentry} % Print bibliography entries inline.
|
|
\nobibliography* % use the bibliographic data from the standard BibTeX setup.
|
|
\usepackage{breakurl}
|
|
\usepackage{amsmath} % Mathematics library
|
|
\usepackage{amssymb} % Provides math fonts
|
|
\usepackage{amsthm} % Provides \newtheorem, \theoremstyle, etc.
|
|
\usepackage{mathtools}
|
|
\usepackage{bm}
|
|
\usepackage{pkgs/mathpartir} % Inference rules
|
|
\usepackage{pkgs/mathwidth}
|
|
\usepackage{stmaryrd} % semantic brackets
|
|
\usepackage{array}
|
|
\usepackage{float} % Float control
|
|
\usepackage{caption,subcaption} % Sub figures support
|
|
\DeclareCaptionFormat{underlinedfigure}{#1#2#3\hrulefill}
|
|
\captionsetup[figure]{format=underlinedfigure}
|
|
\usepackage[T1]{fontenc} % Fixes issues with accented characters
|
|
%\usepackage{libertine}
|
|
%\usepackage{lmodern}
|
|
%\usepackage{palatino}
|
|
% \usepackage{newpxtext,newpxmath}
|
|
\usepackage[scaled=0.80]{beramono}
|
|
\usepackage[activate=true,
|
|
final,
|
|
tracking=true,
|
|
kerning=true,
|
|
spacing=true,
|
|
factor=1100,
|
|
stretch=10,
|
|
shrink=10]{microtype}
|
|
|
|
\SetProtrusion{encoding={*},family={bch},series={*},size={6,7}}
|
|
{1={ ,750},2={ ,500},3={ ,500},4={ ,500},5={ ,500},
|
|
6={ ,500},7={ ,600},8={ ,500},9={ ,500},0={ ,500}}
|
|
|
|
\SetExtraKerning[unit=space]
|
|
{encoding={*}, family={bch}, series={*}, size={footnotesize,small,normalsize}}
|
|
{\textendash={400,400}, % en-dash, add more space around it
|
|
"28={ ,150}, % left bracket, add space from right
|
|
"29={150, }, % right bracket, add space from left
|
|
\textquotedblleft={ ,150}, % left quotation mark, space from right
|
|
\textquotedblright={150, }} % right quotation mark, space from left
|
|
|
|
\usepackage{enumerate} % Customise enumerate-environments
|
|
\usepackage{xcolor} % Colours
|
|
\usepackage{xspace} % Smart spacing in commands.
|
|
\usepackage{tikz}
|
|
\usetikzlibrary{fit,calc,trees,positioning,arrows,chains,shapes.geometric,%
|
|
decorations.pathreplacing,decorations.pathmorphing,shapes,%
|
|
matrix,shapes.symbols,intersections,tikzmark}
|
|
|
|
\usepackage[customcolors,shade]{hf-tikz} % Shaded backgrounds.
|
|
\hfsetfillcolor{gray!40}
|
|
\hfsetbordercolor{gray!40}
|
|
|
|
% Multi-row configuration
|
|
\usepackage{makecell,multirow}
|
|
\newcommand{\tablistcommand}{ % eliminates vertical space before and after itemize
|
|
\leavevmode\par\vspace{-\baselineskip}}
|
|
\newcolumntype{P}[1]{p{#1-2\tabcolsep-\arrayrulewidth}}
|
|
|
|
% Cancelling
|
|
\newif\ifCancelX
|
|
\tikzset{X/.code={\CancelXtrue}}
|
|
\newcommand{\Cancel}[2][]{\relax
|
|
\ifmmode%
|
|
\tikz[baseline=(X.base),inner sep=0pt] {\node (X) {$#2$};
|
|
\tikzset{#1}
|
|
\draw[#1,overlay,shorten >=-2pt,shorten <=-2pt] (X.south west) -- (X.north east);
|
|
\ifCancelX
|
|
\draw[#1,overlay,shorten >=-2pt,shorten <=-2pt] (X.north west) -- (X.south east);
|
|
\fi}
|
|
\else
|
|
\tikz[baseline=(X.base),inner sep=0pt] {\node (X) {#2};
|
|
\tikzset{#1}
|
|
\draw[#1,overlay,shorten >=-2pt,shorten <=-2pt] (X.south west) -- (X.north east);
|
|
\ifCancelX
|
|
\draw[#1,overlay,shorten >=-2pt,shorten <=-2pt] (X.north west) -- (X.south east);
|
|
\fi}%
|
|
\fi}
|
|
|
|
\newcommand{\XCancel}[1]{\Cancel[red,X,line width=1pt]{#1}}
|
|
|
|
% Structures
|
|
\tikzset{
|
|
port/.style = {treenode, font=\Huge, draw=white, minimum width=0.5em, minimum height=0.5em},
|
|
blackbox/.style = {rectangle, fill=black, draw=black, minimum width=2cm, minimum height=2cm},
|
|
treenode/.style = {align=center, inner sep=3pt, text centered},
|
|
opnode/.style = {treenode, rectangle, draw=black},
|
|
leaf/.style = {treenode, draw=black, ellipse, thin},
|
|
comptree/.style = {treenode, draw=black, regular polygon, regular polygon sides=3},
|
|
highlight/.style = {draw=red,very thick},
|
|
pencildraw/.style={
|
|
black!75,
|
|
decorate,
|
|
decoration={random steps,segment length=0.8pt,amplitude=0.1pt}
|
|
},
|
|
hbox/.style = {rectangle,draw=none, minimum width=6cm, minimum height=1cm},
|
|
gbox/.style = {rectangle,draw=none,minimum width=2cm,minimum height=1cm}
|
|
}
|
|
|
|
%%
|
|
%% Theorem environments
|
|
%%
|
|
\theoremstyle{plain}
|
|
\newtheorem{theorem}{Theorem}[chapter]
|
|
\newtheorem{lemma}[theorem]{Lemma}
|
|
\newtheorem{proposition}[theorem]{Proposition}
|
|
\newtheorem{corollary}[theorem]{Corollary}
|
|
\theoremstyle{definition}
|
|
\newtheorem{definition}[theorem]{Definition}
|
|
% Example environment.
|
|
\makeatletter
|
|
\def\@endtheorem{\hfill$\blacksquare$\endtrivlist\@endpefalse} % inserts a black square at the end.
|
|
\makeatother
|
|
\newtheorem{example}{Example}[chapter]
|
|
|
|
%%
|
|
%% Load macros.
|
|
%%
|
|
\input{macros}
|
|
|
|
%% Information about the title, etc.
|
|
% \title{Higher-Order Theories of Handlers for Algebraic Effects}
|
|
% \title{Handlers for Algebraic Effects: Applications, Compilation, and Expressiveness}
|
|
% \title{Applications, Compilation, and Expressiveness for Effect Handlers}
|
|
% \title{Handling Computational Effects}
|
|
% \title{Programming Computable Effectful Functions}
|
|
% \title{Handling Effectful Computations}
|
|
\title{Foundations for Programming and Implementing Effect Handlers}
|
|
%\title{Foundations for Programming with Control via Effect Handlers}
|
|
\author{Daniel Hillerström}
|
|
|
|
%% If the year of submission is not the current year, uncomment this line and
|
|
%% specify it here:
|
|
\submityear{2021}
|
|
|
|
%% Specify the abstract here.
|
|
\abstract{%
|
|
% Virtually every programming language is equipped with multiple
|
|
% different control operators which enable the programmer to manipulate
|
|
% the flow of control.
|
|
% %
|
|
% For example, the operator \emph{if-then-else} lets the programmer
|
|
% conditionally select between two distinct \emph{continuations}. The
|
|
% operator \emph{async-await} lets the programmer run multiple
|
|
% distinct continuations asynchronously and await their results.
|
|
%
|
|
First-class control operators provide programmers with an expressive
|
|
and efficient means for manipulating control through reification of
|
|
the current control state as a first-class object, enabling
|
|
programmers to implement their own control idioms as shareable
|
|
libraries.
|
|
%
|
|
Effect handlers provide a particularly structured approach to
|
|
programming with first-class control by separating control reifying
|
|
operations from their handling.
|
|
|
|
In this thesis I develop operational foundations for programming and
|
|
implementing effect handlers.
|
|
|
|
The first strand develops the core calculus of a programming
|
|
language with a \emph{structural} notion of effects, as opposed to
|
|
the dominant \emph{nominal} notion of effects.
|
|
|
|
By making crucial use of \emph{row polymorphism} to build and track
|
|
effect signatures.
|
|
|
|
The second strand studies \emph{continuation passing style} and
|
|
\emph{abstract machine semantics}, which are foundational techniques
|
|
that admit a unified basis for implementing deep, shallow, and
|
|
parameterised effect handlers in the same environment.
|
|
%
|
|
Starting from a CPS translation basic Eventually leading to the
|
|
notion of \emph{generalised continuation}.
|
|
|
|
The third strand investigates the expressive power of effect
|
|
handlers.
|
|
%
|
|
}
|
|
|
|
%% Now we start with the actual document.
|
|
\begin{document}
|
|
\raggedbottom
|
|
%% First, the preliminary pages
|
|
\begin{preliminary}
|
|
|
|
%% This creates the title page
|
|
\maketitle
|
|
|
|
%% Acknowledgements
|
|
\begin{acknowledgements}
|
|
Firstly, I want to thank Sam Lindley for his guidance, advice, and
|
|
encouragement throughout my studies. He has been enthusiastic
|
|
supervisor, and he has always been generous with his time. I am
|
|
fortunate to have been supervised by him.
|
|
|
|
Throughout my studies I have received funding from the
|
|
\href{https://www.ed.ac.uk/informatics}{School of Informatics} at
|
|
The University of Edinburgh, as well as an
|
|
\href{https://www.epsrc.ac.uk/}{EPSRC} grant
|
|
\href{http://pervasiveparallelism.inf.ed.ac.uk}{EP/L01503X/1} (EPSRC
|
|
Centre for Doctoral Training in Pervasive Parallelism), and by ERC
|
|
Consolidator Grant Skye (grant number 682315).
|
|
|
|
List of people to thank
|
|
\begin{itemize}
|
|
\item Sam Lindley
|
|
\item John Longley
|
|
\item Christophe Dubach
|
|
\item KC Sivaramakrishnan
|
|
\item Stephen Dolan
|
|
\item Anil Madhavapeddy
|
|
\item Gemma Gordon
|
|
\item Leo White
|
|
\item Andreas Rossberg
|
|
\item Robert Atkey
|
|
\item Jeremy Yallop
|
|
\item Simon Fowler
|
|
\item Craig McLaughlin
|
|
\item Garrett Morris
|
|
\item James McKinna
|
|
\item Brian Campbell
|
|
\item Paul Piho
|
|
\item Amna Shahab
|
|
\item Gordon Plotkin
|
|
\item Ohad Kammar
|
|
\item School of Informatics (funding)
|
|
\item Google (Kevin Millikin, Dmitry Stefantsov)
|
|
\item Microsoft Research (Daan Leijen)
|
|
\end{itemize}
|
|
\end{acknowledgements}
|
|
|
|
%% Next we need to have the declaration.
|
|
% \standarddeclaration
|
|
\begin{declaration}
|
|
I declare that this thesis was composed by myself, that the work
|
|
contained herein is my own except where explicitly stated otherwise
|
|
in the text, and that this work has not been submitted for any other
|
|
degree or professional qualification except as specified.
|
|
|
|
The following previously published work of mine features prominently
|
|
within this dissertation. Each chapter details the relevant
|
|
relations to my previous work.
|
|
%
|
|
\begin{itemize}
|
|
\item \bibentry{HillerstromL16}
|
|
\item \bibentry{HillerstromLAS17}
|
|
\item \bibentry{HillerstromL18}
|
|
\item \bibentry{HillerstromLA20}
|
|
\item \bibentry{HillerstromLL20}
|
|
\end{itemize}
|
|
%
|
|
\end{declaration}
|
|
|
|
%% Finally, a dedication (this is optional -- uncomment the following line if
|
|
%% you want one).
|
|
% \dedication{To my mummy.}
|
|
% \dedication{\emph{To be or to do}}
|
|
\dedication{\emph{Bara du sätter gränserna}}
|
|
|
|
% \begin{preface}
|
|
% A preface will possibly appear here\dots
|
|
% \end{preface}
|
|
|
|
%% Create the table of contents
|
|
\setcounter{secnumdepth}{2} % Numbering on sections and subsections
|
|
\setcounter{tocdepth}{1} % Show chapters, sections and subsections in TOC
|
|
%\singlespace
|
|
\tableofcontents
|
|
%\doublespace
|
|
|
|
%% If you want a list of figures or tables, uncomment the appropriate line(s)
|
|
% \listoffigures
|
|
% \listoftables
|
|
\end{preliminary}
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%% Main content %%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
%%
|
|
%% Introduction
|
|
%%
|
|
\chapter{Introduction}
|
|
\label{ch:introduction}
|
|
An enthralling introduction\dots
|
|
%
|
|
Motivation: 1) compiler perspective: unifying control abstraction,
|
|
lean runtime, desugaring of async/await, generators/iterators, 2)
|
|
giving control to programmers, safer microkernels, everything as a
|
|
library.
|
|
|
|
\section{Why first-class control matters}
|
|
|
|
\subsection{Flavours of control}
|
|
\paragraph{Undelimited control}
|
|
\paragraph{Delimited control}
|
|
\paragraph{Composable control}
|
|
|
|
\subsection{Why effect handlers}
|
|
|
|
\section{Thesis outline}
|
|
Thesis outline\dots
|
|
|
|
\section{Typographical conventions}
|
|
Explain conventions\dots
|
|
|
|
\part{Background}
|
|
\label{p:background}
|
|
|
|
\chapter{Mathematical preliminaries}
|
|
\label{ch:maths-prep}
|
|
|
|
Only a modest amount of mathematical proficiency should be necessary
|
|
to be able to wholly digest this dissertation.
|
|
%
|
|
This chapter introduces some key mathematical concepts that will
|
|
either be used directly or indirectly throughout this dissertation.
|
|
%
|
|
|
|
I assume familiarity with basic programming language theory including
|
|
structural operational semantics~\cite{Plotkin04a} and System F type
|
|
theory~\cite{Girard72}. For a practical introduction to programming
|
|
language theory I recommend consulting \citeauthor{Pierce02}'s
|
|
excellent book \emph{Types and Programming
|
|
Languages}~\cite{Pierce02}. For the more theoretical inclined I
|
|
recommend \citeauthor{Harper16}'s book \emph{Practical Foundations for
|
|
Programming Languages}~\cite{Harper16} (do not let the ``practical''
|
|
qualifier deceive you) --- the two books complement each other nicely.
|
|
|
|
\section{Relations and functions}
|
|
\label{sec:functions}
|
|
|
|
Relations and functions feature prominently in the design and
|
|
understanding of the static and dynamic properties of programming
|
|
languages. The interested reader is likely to already be familiar with
|
|
the basic concepts of relations and functions, although this section
|
|
briefly introduces the concepts, its purpose is to introduce the
|
|
notation that I am using pervasively throughout this dissertation.
|
|
%
|
|
|
|
I assume familiarity with basic set theory.
|
|
|
|
\begin{definition}
|
|
The Cartesian product of two sets $A$ and $B$, written $A \times B$,
|
|
is the set of all ordered pairs $(a, b)$, where $a$ is drawn from
|
|
$A$ and $b$ is drawn from $B$, i.e.
|
|
%
|
|
\[
|
|
A \times B \defas \{ (a, b) \mid a \in A, b \in B \}
|
|
\]
|
|
%
|
|
\end{definition}
|
|
%
|
|
Since the Cartesian product is itself a set, we can take the Cartesian
|
|
product of it with another set, e.g. $A \times B \times C$. However,
|
|
this raises the question in which order the product operator
|
|
($\times$) is applied. In this dissertation the product operator is
|
|
taken to be right associative, meaning
|
|
$A \times B \times C = A \times (B \times C)$.
|
|
%
|
|
\dhil{Define tuples (and ordered pairs)?}
|
|
%
|
|
% To make the notation more compact for the special case of $n$-fold
|
|
% product of some set $A$ with itself we write
|
|
% $A^n \defas A \underbrace{\times \cdots \times}_{n \text{ times}} A$.
|
|
%
|
|
|
|
|
|
\begin{definition}
|
|
A relation $R$ is a subset of the Cartesian product of two sets $A$
|
|
and $B$, i.e. $R \subseteq A \times B$.
|
|
%
|
|
An element $a \in A$ is related to an element $b \in B$ if
|
|
$(a, b) \in R$, sometimes written using infix notation $a\,R\,b$.
|
|
%
|
|
If $A = B$ then $R$ is said to be a homogeneous relation.
|
|
\end{definition}
|
|
%
|
|
|
|
\begin{definition}
|
|
For any two relations $R \subseteq A \times B$ and
|
|
$S \subseteq B \times C$ their composition is defined as follows.
|
|
%
|
|
\[
|
|
S \circ R \defas \{ (a,c) \mid (a,b) \in R, (b, c) \in S \}
|
|
\]
|
|
\end{definition}
|
|
|
|
The composition operator ($\circ$) is associative, meaning
|
|
$(T \circ S) \circ R = T \circ (S \circ R)$.
|
|
%
|
|
For $n \in \N$ the $n$th relational power of a relation $R$, written
|
|
$R^n$, is defined inductively.
|
|
\[
|
|
R^0 \defas \emptyset, \quad\qquad R^1 \defas R, \quad\qquad R^{1 + n} \defas R \circ R^n.
|
|
\]
|
|
%
|
|
Homogeneous relations play a prominent role in the operational
|
|
understanding of programming languages as they are used to give
|
|
meaning to program reductions. There are two particular properties and
|
|
associated closure operations of homogeneous relations that reoccur
|
|
throughout this dissertation.
|
|
%
|
|
\begin{definition}
|
|
A homogeneous relation $R \subseteq A \times A$ is said to be
|
|
reflexive and transitive if its satisfies the following criteria,
|
|
respectively.
|
|
\begin{itemize}
|
|
\item Reflexive: $\forall a \in A$ it holds that $a\,R\,a$.
|
|
\item Transitive: $\forall a,b,c \in A$ if $a\,R\,b$ and $b\,R\,c$
|
|
then $a\,R\,c$.
|
|
\end{itemize}
|
|
\end{definition}
|
|
|
|
\begin{definition}[Closure operations]
|
|
Let $R \subseteq A \times A$ denote a homogeneous relation. The
|
|
reflexive closure $R^{=}$ of $R$ is the smallest reflexive relation
|
|
over $A$ containing $R$
|
|
%
|
|
\[
|
|
R^{=} \defas \{ (a, a) \mid a \in A \} \cup R.
|
|
\]
|
|
%
|
|
The transitive closure $R^+$ of $R$ is the smallest transitive
|
|
relation over $A$ containing $R$
|
|
%
|
|
\[
|
|
R^+ \defas \displaystyle\bigcup_{n \in \N} R^n.
|
|
\]
|
|
%
|
|
The reflexive and transitive closure $R^\ast$ of $R$ is the smallest
|
|
reflexive and transitive relation over $A$ containing $R$
|
|
%
|
|
\[
|
|
R^\ast \defas (R^+)^{=}.
|
|
\]
|
|
\end{definition}
|
|
%
|
|
|
|
\begin{definition}
|
|
A relation $R \subseteq A \times B$ is functional and serial if it
|
|
satisfies the following criteria, respectively.
|
|
%
|
|
\begin{itemize}
|
|
\item Functional: $\forall a \in A, b,b' \in B$ if $a\,R\,b$ and $a\,R\,b'$ then $b = b'$.
|
|
\item Serial: $\forall a \in A,\exists b \in B$ such that
|
|
$a\,R\,b$.
|
|
\end{itemize}
|
|
\end{definition}
|
|
%
|
|
The functional property guarantees that every $a \in A$ is at most
|
|
related to one $b \in B$. Note this does not mean that every $a$
|
|
\emph{is} related to some $b$. The serial property guarantees that
|
|
every $a \in A$ is related to one or more elements in $B$.
|
|
%
|
|
We use these properties to define partial and total functions.
|
|
%
|
|
\begin{definition}
|
|
A partial function $f : A \pto B$ is a functional relation
|
|
$f \subseteq A \times B$.
|
|
%
|
|
A total function $f : A \to B$ is a functional and serial relation
|
|
$f \subseteq A \times B$.
|
|
\end{definition}
|
|
%
|
|
A total function is also simply called a `function'. Throughout this
|
|
dissertation the terms (partial) mapping and (partial) function are
|
|
synonymous.
|
|
%
|
|
|
|
For a function $f : A \to B$ (or partial function $f : A \pto B$) we
|
|
write $f(a) = b$ to mean $(a, b) \in f$, and say that $f$ applied to
|
|
$a$ returns $b$. The notation $f(a)$ means the application of $f$ to
|
|
$a$, and we say that $f(a)$ is defined whenever $f(a) = b$ for some
|
|
$b$.
|
|
%
|
|
The domain of a function is a set, $\dom(-)$, consisting of all the
|
|
elements for which it is defined. Thus the domain of a total function
|
|
is its domain of definition, e.g. $\dom(f : A \to B) = A$.
|
|
%
|
|
For a partial function $f$ its domain is a proper subset of the domain
|
|
of definition.
|
|
%
|
|
\[
|
|
\dom(f : A \pto B) \defas \{ a \mid a \in A,\, f(a) \text{ is defined} \} \subset A.
|
|
\]
|
|
%
|
|
The codomain of a total function $f : A \to B$ (or partial function
|
|
$f : A \pto B$) is $B$, written $\dec{cod}(f) = B$. A related notion
|
|
is that of \emph{image}. The image of a total or partial function $f$,
|
|
written $\dec{Im}(f)$, is the set of values that it can return, i.e.
|
|
%
|
|
\[
|
|
\dec{Im}(f) \defas \{\, f(a) \mid a \in \dom(f) \}.
|
|
\]
|
|
|
|
|
|
\begin{definition}
|
|
A function $f : A \to B$ is injective and surjective if it satisfies
|
|
the following criteria, respectively.
|
|
\begin{itemize}
|
|
\item Injective: $\forall a,a' \in A$ if $f(a) = f(a')$ then $a = a'$.
|
|
\item Surjective: $\forall b \in B,\exists a \in A$ such that $f(a) = b$.
|
|
\end{itemize}
|
|
If a function is both injective and surjective, then it is said to
|
|
be a bijective.
|
|
\end{definition}
|
|
%
|
|
An injective function guarantees that each element in its image is
|
|
uniquely determined by some element of its domain.
|
|
%
|
|
A surjective function guarantees that its domain covers the codomain,
|
|
meaning that the codomain and image coincide.
|
|
%
|
|
A partial function $f$ is injective, surjective, and bijective
|
|
whenever the function $f' : \dom(f) \to \dec{cod}(f)$, obtained by
|
|
restricting $f$ to its domain, is injective, surjective, and bijective
|
|
respectively.
|
|
|
|
\section{Universal algebra}
|
|
\label{sec:universal-algebra}
|
|
|
|
Universal algebra studies \emph{algebraic theories}.
|
|
|
|
\begin{definition}[Operations]
|
|
|
|
\end{definition}
|
|
|
|
\begin{definition}[Algebraic theory]\label{def:algebra}
|
|
|
|
\end{definition}
|
|
|
|
\section{Algebraic effects and their handlers}
|
|
\label{sec:algebraic-effects}
|
|
|
|
See \citeauthor{Bauer18}'s tutorial~\cite{Bauer18} for an excellent
|
|
thorough account of the mathematics underpinning algebraic effects and
|
|
handlers.
|
|
|
|
\section{Typed programming languages}
|
|
\label{sec:pls}
|
|
%
|
|
\dhil{Definition of (typed) programming language, conservative extension, macro-expressiveness~\cite{Felleisen90,Felleisen91}}
|
|
|
|
\chapter{State of effectful programming}
|
|
\label{ch:related-work}
|
|
|
|
% \section{Type and effect systems}
|
|
% \section{Monadic programming}
|
|
\section{Golden age of impurity}
|
|
\section{Monadic enlightenment}
|
|
\dhil{Moggi's seminal work applies the notion of monads to effectful
|
|
programming by modelling effects as monads. More importantly,
|
|
Moggi's work gives a precise characterisation of what's \emph{not}
|
|
an effect}
|
|
\section{Direct-style revolution}
|
|
|
|
\subsection{Monadic reflection: best of both worlds}
|
|
|
|
\chapter{Continuations}
|
|
\label{ch:continuations}
|
|
|
|
A continuation represents the control state of computation at a given
|
|
point during evaluation. The control state contains the necessary
|
|
operational information for evaluation to continue. As such,
|
|
continuations drive computation. % Continuations are a ubiquitous
|
|
% phenomenon as they exist both semantically and programmatically.
|
|
%
|
|
Continuations are one of those canonical ideas, that have been
|
|
discovered multiple times and whose definition predates their
|
|
use~\cite{Reynolds93}. The term `continuation' first appeared in the
|
|
literature in 1974, when \citet{StracheyW74} used continuations to
|
|
give a denotational semantics to programming languages with
|
|
unrestricted jumps~\cite{StracheyW00}.
|
|
|
|
The inaugural use of continuations came well before
|
|
\citeauthor{StracheyW00}'s definition. About a decade earlier
|
|
continuation passing style had already been conceived, if not in name
|
|
then in spirit, as a compiler transformation for eliminating labels
|
|
and goto statements~\cite{Reynolds93}. In the mid 1960s
|
|
\citet{Landin98} introduced the J operator as a programmatic mechanism
|
|
for manipulating continuations.
|
|
|
|
\citeauthor{Landin98}'s J operator is an instance of a first-class
|
|
control operator, which is a mechanism that lets programmers reify
|
|
continuations as first-class objects, that can be invoked, discarded,
|
|
or stored for later use. There exists a wide variety of control
|
|
operators, which expose continuations of varying extent and behaviour.
|
|
|
|
The purpose of this chapter is to examine control operators and their
|
|
continuations in
|
|
programming. Section~\ref{sec:classifying-continuations} examines
|
|
different notions of continuations by characterising their extent and
|
|
behaviour operationally. Section~\ref{sec:controlling-continuations}
|
|
contains a detailed overview of various control operators that appear
|
|
in programming languages and in the
|
|
literature. Section~\ref{sec:programming-continuations} summarises
|
|
some applications of continuations, whilst
|
|
Section~\ref{sec:constraining-continuations} contains a brief summary
|
|
of ideas for constraining the power of continuations. Lastly,
|
|
Section~\ref{sec:implementing-continuations} outlines some
|
|
implementation strategies for continuations.
|
|
|
|
% A lot of literature has been devoted to study continuations. Whilst
|
|
% the literature recognises the importance and significance of
|
|
% continuations
|
|
|
|
% continuations are widely recognised as important in the programming
|
|
% language literature,
|
|
|
|
% The concrete structure and behaviour of continuations differs
|
|
|
|
% Continuations, when exposed programmatically, imbue programmers with
|
|
% the power to take control of programs. This power enables programmers
|
|
% to implement their own control idioms as user-definable libraries.
|
|
|
|
% The significance of continuations in the programming languages
|
|
% literature is inescapable as continuations have found widespread use .
|
|
%
|
|
|
|
% A continuation is an abstract data structure that captures the
|
|
% remainder of the computation from some given point in the computation.
|
|
% %
|
|
% The exact nature of the data structure and the precise point at which
|
|
% the remainder of the computation is captured depends largely on the
|
|
% exact notion of continuation under consideration.
|
|
% %
|
|
% It can be difficult to navigate the existing literature on
|
|
% continuations as sometimes the terminologies for different notions of
|
|
% continuations are overloaded or even conflated.
|
|
% %
|
|
% As there exist several notions of continuations, there exist several
|
|
% mechanisms for programmatic manipulation of continuations. These
|
|
% mechanisms are known as control operators.
|
|
% %
|
|
% A substantial amount of existing literature has been devoted to
|
|
% understand how to program with individual control operators, and to a
|
|
% lesser extent how the various operators compare.
|
|
|
|
% The purpose of this chapter is to provide a contemporary and
|
|
% unambiguous characterisation of the notions of continuations in
|
|
% literature. This characterisation is used to classify and discuss a
|
|
% wide range of control operators from the literature.
|
|
|
|
% % Undelimited control: Landin's J~\cite{Landin98}, Reynolds'
|
|
% % escape~\cite{Reynolds98a}, Scheme75's catch~\cite{SussmanS75} ---
|
|
% % which was based the less expressive MacLisp catch~\cite{Moon74},
|
|
% % callcc is a procedural variation of catch. It was invented in
|
|
% % 1982~\cite{AbelsonHAKBOBPCRFRHSHW85}.
|
|
|
|
% A full formal comparison of the control operators is out of scope of
|
|
% this chapter. The literature contains comparisons of various control
|
|
% operators along various dimensions, e.g.
|
|
% %
|
|
% \citet{Thielecke02} studies a handful of operators via double
|
|
% barrelled continuation passing style. \citet{ForsterKLP19} compare the
|
|
% relative expressiveness of untyped and simply-typed variations of
|
|
% effect handlers, shift/reset, and monadic reflection by means of
|
|
% whether they are macro-expressible. Their work demonstrates that in an
|
|
% untyped setting each operator is macro-expressible, but in most cases
|
|
% the macro-translations do not preserve typeability, for instance the
|
|
% simple type structure is insufficient to type the image of
|
|
% macro-translation between effect handlers and shift/reset.
|
|
% %
|
|
% However, \citet{PirogPS19} show that with a polymorphic type system
|
|
% the translation preserve typeability.
|
|
% %
|
|
% \citet{Shan04} shows that dynamic delimited control and static
|
|
% delimited control is macro-expressible in an untyped setting.
|
|
|
|
\section{Classifying continuations}
|
|
\label{sec:classifying-continuations}
|
|
|
|
The term `continuation' is really an umbrella term that covers several
|
|
distinct notions of continuations. It is common in the literature to
|
|
find the word `continuation' accompanied by a qualifier such as full,
|
|
partial, abortive, escape, undelimited, delimited, composable, or
|
|
functional (in Chapter~\ref{ch:cps} I will extend this list by three
|
|
new ones). Some of these notions of continuations synonyms, whereas
|
|
others have distinct meaning. Common to all notions of continuations
|
|
is that in essence they represent the control state. However, the
|
|
extent and behaviour of continuations differ widely from notion to
|
|
notion. The essential notions of continuations are
|
|
undelimited/delimited and abortive/composable. To tell them apart, we
|
|
will classify them by their operational behaviour.
|
|
|
|
The extent and behaviour of a continuation in programming are
|
|
determined by its introduction and elimination forms,
|
|
respectively. Programmatically, a continuation is introduced via a
|
|
control operator, which reifies the control state as a first-class
|
|
object, e.g. a function, that can be eliminated via some form of
|
|
application.
|
|
|
|
\subsection{Introduction of continuations}
|
|
%
|
|
The extent of a continuation determines how much of the control state
|
|
is contained with the continuation.
|
|
%
|
|
The extent can be either undelimited or delimited, and it is
|
|
determined at the point of capture by the control operator.
|
|
%
|
|
|
|
We need some notation for control operators in order to examine the
|
|
introduction of continuations operationally. We will use the syntax
|
|
$\CC~k.M$ to denote a control operator, or control reifier, which that
|
|
reifies the control state and binds it to $k$ in the computation
|
|
$M$. Here the control state will simply be an evaluation context. We
|
|
will denote continuations by a special value $\cont_{\EC}$, which is
|
|
indexed by the reified evaluation context $\EC$ to make notionally
|
|
convenient to reflect the context again. To characterise delimited
|
|
continuations we also need a control delimiter. We will write
|
|
$\Delim{M}$ to denote a syntactic marker that delimits some
|
|
computation $M$.
|
|
|
|
\paragraph{Undelimited continuation} The extent of an undelimited
|
|
continuation is indefinite as it ranges over the entire remainder of
|
|
computation.
|
|
%
|
|
In functional programming languages undelimted control operators most
|
|
commonly expose the \emph{current} continuation, which is the
|
|
precisely continuation following the control operator. The following
|
|
is the characteristic reduction for the introduction of the current
|
|
continuation.
|
|
% The indefinite extents means that undelimited continuation capture can
|
|
% only be understood in context. The characteristic reduction is as
|
|
% follows.
|
|
%
|
|
\[
|
|
\EC[\CC~k.M] \reducesto \EC[M[\cont_{\EC}/k]]
|
|
\]
|
|
%
|
|
The evaluation context $\EC$ is the continuation of $\CC$. The
|
|
evaluation context on the left hand side gets reified as a
|
|
continuation object, which is accessible inside of $M$ via $k$. On the
|
|
right hand side the entire context remains in place after
|
|
reification. Thus, the current continuation is evaluated regardless of
|
|
whether the continuation object is invoked. This is an instance of
|
|
non-abortive undelimited control. Alternatively, the control operator
|
|
can abort the current continuation before proceeding as $M$, i.e.
|
|
%
|
|
\[
|
|
\EC[\CC~k.M] \reducesto M[\cont_{\EC}/k]
|
|
\]
|
|
%
|
|
This is the characteristic reduction rule for abortive undelimited
|
|
control. The rule is nearly the same as the previous, except that on
|
|
the right hand side the evaluation context $\EC$ is discarded after
|
|
reification. Now, the programmer has control over the whole
|
|
continuation, since it is entirely up to the programmer whether $\EC$
|
|
gets evaluated.
|
|
|
|
Imperative statement-oriented programming languages commonly expose
|
|
the \emph{caller} continuation, typically via a return statement. The
|
|
caller continuation is the continuation of the invocation context of
|
|
the control operator. Characterising undelimited caller continuations
|
|
is slightly more involved as we have to remember the continuation of
|
|
the invocation context. We will use a bold lambda $\llambda$ as a
|
|
syntactic runtime marker to remember the continuation of an
|
|
application. In addition we need three reduction rules, where the
|
|
first is purely administrative, the second is an extension of regular
|
|
application, and the third is the characteristic reduction rule for
|
|
undelimited control with caller continuations.
|
|
%
|
|
\begin{reductions}
|
|
& \llambda.V &\reducesto& V\\
|
|
& (\lambda x.N)\,V &\reducesto& \llambda.N[V/x]\\
|
|
& \EC[\llambda.\EC'[\CC~k.M]] &\reducesto& \EC[\llambda.\EC'[M[\cont_{\EC}/k]]], \quad \text{where $\EC'$ contains no $\llambda$}
|
|
\end{reductions}
|
|
%
|
|
The first rule accounts for the case where $\llambda$ marks a value,
|
|
in which case the marker is eliminated. The second rule marks inserts
|
|
a marker after an application such that this position can be recalled
|
|
later. The third rule is the interesting rule. Here an occurrence of
|
|
$\CC$ reifies $\EC$, the continuation of some application, rather than
|
|
its current continuation $\EC'$. The side condition ensures that $\CC$
|
|
reifies the continuation of the inner most application. This rule
|
|
characterises a non-abortive control operator as both contexts, $\EC$
|
|
and $\EC'$, are left in place after reification. It is straightforward
|
|
to adapt this rule to an abortive operator. Although, there is no
|
|
abortive undelimited control operator that captures the caller
|
|
continuation in the literature.
|
|
|
|
It is worth noting that the two first rules can be understood locally,
|
|
that is without mentioning the enclosing context, whereas the third
|
|
rule must be understood globally.
|
|
|
|
In the literature an undelimited continuation is also known as a
|
|
`full' continuation.
|
|
|
|
\paragraph{Delimited continuation} A delimited continuation is in some
|
|
sense a refinement of a undelimited continuation as its extent is
|
|
definite. A delimited continuation ranges over some designated part of
|
|
computation. A delimited continuation is introduced by a pair
|
|
operators: a control delimiter and a control reifier. The control
|
|
delimiter acts as a barrier, which prevents the reifier from reaching
|
|
beyond it, e.g.
|
|
%
|
|
\begin{reductions}
|
|
& \Delim{V} &\reducesto& V\\
|
|
& \Delim{\EC[\CC~k.M]} &\reducesto& \Delim{\EC[M[\cont_{\EC}/k]]}
|
|
\end{reductions}
|
|
%
|
|
The first rule applies whenever the control delimiter delimits a
|
|
value, in which case the delimiter is eliminated. The second rule is
|
|
the characteristic reduction rule for a non-abortive delimited control
|
|
reifier. It reifies the context $\EC$ up to the control delimiter, and
|
|
then continues as $M$ under the control delimiter. Note that the
|
|
continuation of $\keyw{del}$ is invisible to $\CC$, and thus, the
|
|
behaviour of $\CC$ can be understood locally.
|
|
|
|
The design space of delimited control is somewhat richer than that of
|
|
undelimited control, as the control delimiter may remain in place
|
|
after reification, as above, or be discarded. Similarly, the control
|
|
reifier may reify the continuation up to and including the delimiter
|
|
or, as above, without the delimiter.
|
|
%
|
|
The most common variation of delimited control in the literature is
|
|
abortive and reifies the current continuation up to, but not including
|
|
the delimiter, i.e.
|
|
\begin{reductions}
|
|
& \Delim{\EC[\CC~k.M]} &\reducesto& M[\cont_{\EC}/k]
|
|
\end{reductions}
|
|
%
|
|
In the literature a delimited continuation is also known as a
|
|
`partial' continuation.
|
|
|
|
\subsection{Elimination of continuations}
|
|
|
|
The purpose of continuation application is to reinstall the captured
|
|
context.
|
|
%
|
|
However, a continuation application may affect the control state in
|
|
various ways. The literature features two distinct behaviours of
|
|
continuation application: abortive and composable. We need some
|
|
notation for application of continuations in order to characterise
|
|
abortive and composable behaviours. We will write
|
|
$\Continue~\cont_{\EC}~V$ to denote the application of some
|
|
continuation object $\cont$ to some value $V$.
|
|
|
|
\paragraph{Abortive continuation} Upon invocation an abortive
|
|
continuation discards the entire evaluation context before
|
|
reinstalling the captured context. In other words, an abortive
|
|
continuation replaces the current context with its captured context,
|
|
i.e.
|
|
%
|
|
\[
|
|
\EC[\Continue~\cont_{\EC'}~V] \reducesto \EC'[V]
|
|
\]
|
|
%
|
|
The current context $\EC$ is discarded in favour of the captured
|
|
context $\EC'$ (whether the two contexts coincide depends on the
|
|
control operator). Abortive continuations are a global phenomenon due
|
|
to their effect on the current context. However, in conjunction with a
|
|
control delimiter the behaviour of an abortive continuation can be
|
|
localised, i.e.
|
|
%
|
|
\[
|
|
\Delim{\EC[\Continue~\cont_{\EC'}~V]} \reducesto \EC'[V]
|
|
\]
|
|
%
|
|
Here, the behaviour of continuation does not interfere with the
|
|
context of $\keyw{del}$, and thus, the behaviour can be understood and
|
|
reasoned about locally with respect to $\keyw{del}$.
|
|
|
|
A key characteristic of an abortive continuation is that composition
|
|
is meaningless. For example, composing an abortive continuation with
|
|
itself have no effect.
|
|
%
|
|
\[
|
|
\EC[\Continue~\cont_{\EC'}~(\Continue~\cont_{\EC'}~V)] \reducesto \EC'[V]
|
|
\]
|
|
%
|
|
The innermost application erases the outermost application term,
|
|
consequently only the first application of $\cont$ occurs during
|
|
runtime. It is as if the first application occurred in tail position.
|
|
|
|
The continuations introduced by the early control operators were all
|
|
abortive, since they were motivated by modelling unrestricted jumps
|
|
akin to $\keyw{goto}$ in statement-oriented programming languages.
|
|
|
|
An abortive continuation is also known as an `escape' continuation in
|
|
the literature.
|
|
|
|
\paragraph{Composable continuation} A composable continuation splices
|
|
its captured context with the its invocation context, i.e.
|
|
%
|
|
\[
|
|
\Continue~\cont_{\EC}~V \reducesto \EC[V]
|
|
\]
|
|
%
|
|
The application of a composable continuation can be understood
|
|
locally, because it has no effect on its invocation context. A
|
|
composable continuation behaves like a function in the sense that it
|
|
returns to its caller, and thus composition is well-defined, e.g.
|
|
%
|
|
\[
|
|
\Continue~\cont_{\EC}~(\Continue~\cont_{\EC}~V) \reducesto \Continue~\cont_{\EC}~\EC[V]
|
|
\]
|
|
%
|
|
The innermost application composes the captured context with the
|
|
outermost application. Thus, the outermost application occurs when
|
|
$\EC[V]$ has been reduced to a value.
|
|
|
|
In the literature, virtually every delimited control operator provides
|
|
composable continuations. However, the notion of composable
|
|
continuation is not intimately connected to delimited control. It is
|
|
perfect possible to conceive of a undelimited composable continuation,
|
|
just as a delimited abortive continuation is conceivable.
|
|
|
|
A composable continuation is also known as a `functional' continuation
|
|
in the literature.
|
|
|
|
\section{Controlling continuations}
|
|
\label{sec:controlling-continuations}
|
|
As suggested in the previous section, the design space for
|
|
continuation is rich. This richness is to an extent reflected by the
|
|
large amount of control operators that appear in the literature
|
|
and in practice.
|
|
%
|
|
The purpose of this section is to survey a considerable subset of the
|
|
first-class \emph{sequential} control operators that occur in the
|
|
literature and in practice. Control operators for parallel programming
|
|
will not be considered here.
|
|
%
|
|
Table~\ref{tbl:classify-ctrl} provides a classification of a
|
|
non-exhaustive list of first-class control operators.
|
|
|
|
Note that a \emph{first-class} control operator is typically not
|
|
itself a first-class citizen, rather, the label `first-class' means
|
|
that the reified continuation is a first-class object. Control
|
|
operators that reify the current continuation can be made first-class
|
|
by enclosing them in a $\lambda$-abstraction. Obviously, this trick
|
|
does not work for operators that reify the caller continuation.
|
|
|
|
To study the control operators we will make use of a small base
|
|
language.
|
|
%
|
|
\begin{table}
|
|
\centering
|
|
\begin{tabular}{| l | l | l | l |}
|
|
\hline
|
|
\multicolumn{1}{| l |}{\textbf{Name}} & \multicolumn{1}{l |}{\textbf{Extent}} & \multicolumn{1}{l |}{\textbf{Continuation behaviour}} & \multicolumn{1}{l |}{\textbf{Canonical reference}}\\
|
|
\hline
|
|
C & Undelimited & Abortive & \citet{FelleisenF86} \\
|
|
\hline
|
|
callcc & Undelimited & Abortive & \citet{AbelsonHAKBOBPCRFRHSHW85} \\
|
|
\hline
|
|
\textCallcomc{} & Undelimited & Composable & \citet{Flatt20} \\
|
|
\hline
|
|
catch & Undelimited & Abortive & \citet{SussmanS75} \\
|
|
\hline
|
|
catchcont & Delimited & Composable & \citet{Longley09}\\
|
|
\hline
|
|
cupto & Delimited & Composable & \citet{GunterRR95}\\
|
|
\hline
|
|
control/prompt & Delimited & Composable & \citet{Felleisen88}\\
|
|
\hline
|
|
effect handlers & Delimited & Composable & \citet{PlotkinP13} \\
|
|
\hline
|
|
escape & Undelimited & Abortive & \citet{Reynolds98a}\\
|
|
\hline
|
|
F & Undelimited & Composable & \citet{FelleisenFDM87}\\
|
|
\hline
|
|
fcontrol & Delimited & Composable & \citet{Sitaram93} \\
|
|
\hline
|
|
J & Undelimited & Abortive & \citet{Landin98}\\
|
|
\hline
|
|
shift/reset & Delimited & Composable & \citet{DanvyF90}\\
|
|
\hline
|
|
spawn & Delimited & Composable & \citet{HiebD90}\\
|
|
\hline
|
|
splitter & Delimited & Abortive, composable & \citet{QueinnecS91}\\
|
|
\hline
|
|
\end{tabular}
|
|
\caption{Classification of first-class sequential control operators.}\label{tbl:classify-ctrl}
|
|
\dhil{TODO: Possibly split into two tables: undelimited and delimited. Change the table to display the behaviour of control reifiers.}
|
|
\end{table}
|
|
%
|
|
|
|
\paragraph{A small calculus for control}
|
|
%
|
|
To look at control we will use a simply typed fine-grain call-by-value
|
|
calculus. Although, we will sometimes have to discard the types, as
|
|
many of the control operators were invented and studied in a untyped
|
|
setting. The calculus is essentially the same as the one used in
|
|
Chapter~\ref{ch:handlers-efficiency}, except that here we will have an
|
|
explicit invocation form for continuations. Although, in practice most
|
|
systems disguise continuations as first-class functions, but for a
|
|
theoretical examination it is convenient to treat them specially such
|
|
that continuation invocation is a separate reduction rule from
|
|
ordinary function application. Figure~\ref{fig:pcf-lang-control}
|
|
depicts the syntax of types and terms in the calculus.
|
|
%
|
|
\begin{figure}
|
|
\centering
|
|
\begin{syntax}
|
|
\slab{Types} & A,B &::=& \UnitType \mid A \to B \mid A \times B \mid \Cont\,\Record{A;B} \mid A + B \smallskip\\
|
|
\slab{Values} & V,W &::=& \Unit \mid \lambda x^A.M \mid \Record{V;W} \mid \cont_\EC \mid \Inl~V \mid \Inr~W \mid x\\
|
|
\slab{Computations} & M,N &::=& \Return\;V \mid \Let\;x \revto M \;\In\;N \mid \Let\;\Record{x;y} = V \;\In\; N \\
|
|
& &\mid& V\,W \mid \Continue~V~W \smallskip\\
|
|
\slab{Evaluation\textrm{ }contexts} & \EC &::=& [\,] \mid \Let\;x \revto \EC \;\In\;N
|
|
\end{syntax}
|
|
\caption{Types and term syntax}\label{fig:pcf-lang-control}
|
|
\end{figure}
|
|
%
|
|
The types are the standard simple types with the addition of the
|
|
continuation object type $\Cont\,\Record{A;B}$, which is parameterised
|
|
by an argument type and a result type, respectively. The static
|
|
semantics is standard as well, except for the continuation invocation
|
|
primitive $\Continue$.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{\typ{\Gamma}{V : A} \\ \typ{\Gamma}{W : \Cont\,\Record{A;B}}}
|
|
{\typ{\Gamma}{\Continue~W~V : B}}
|
|
\end{mathpar}
|
|
%
|
|
Although, it is convenient to treat continuation application specially
|
|
for operational inspection, it is rather cumbersome to do so when
|
|
studying encodings of control operators. Therefore, to obtain the best
|
|
of both worlds, the control operators will reify their continuations
|
|
as first-class functions, whose body is $\Continue$-expression. To
|
|
save some ink, we will use the following notation.
|
|
%
|
|
\[
|
|
\qq{\cont_{\EC}} \defas \lambda x. \Continue~\cont_{\EC}~x
|
|
\]
|
|
|
|
\subsection{Undelimited control operators}
|
|
%
|
|
The early inventions of undelimited control operators were driven by
|
|
the desire to provide a `functional' equivalent of jumps as provided
|
|
by the infamous goto in imperative programming.
|
|
%
|
|
|
|
In 1965 Peter \citeauthor{Landin65} unveiled \emph{first} first-class
|
|
control operator: the J
|
|
operator~\cite{Landin65,Landin65a,Landin98}. Later in 1972 influenced
|
|
by \citeauthor{Landin65}'s J operator John \citeauthor{Reynolds98a}
|
|
designed the escape operator~\cite{Reynolds98a}. Influenced by escape,
|
|
\citeauthor{SussmanS75} designed, implemented, and standardised the
|
|
catch operator in Scheme in 1975. A while thereafter the perhaps most
|
|
famous undelimited control operator appeared: callcc. It initially
|
|
designed in 1982 and was standardised in 1985 as a core feature of
|
|
Scheme. Later another batch of control operators based on callcc
|
|
appeared. A common characteristic of the early control operators is
|
|
that their capture mechanisms were abortive and their captured
|
|
continuations were abortive, save for one, namely,
|
|
\citeauthor{Felleisen88}'s F operator. Later a non-abortive and
|
|
composable variant of callcc appeared. Moreover, every operator,
|
|
except for \citeauthor{Landin98}'s J operator, capture the current
|
|
continuation.
|
|
|
|
\paragraph{\citeauthor{Reynolds98a}' escape} The escape operator was introduced by
|
|
\citeauthor{Reynolds98a} in 1972~\cite{Reynolds98a} to make
|
|
statement-oriented control mechanisms such as jumps and labels
|
|
programmable in an expression-oriented language.
|
|
%
|
|
The operator introduces a new computation form.
|
|
%
|
|
\[
|
|
M, N \in \CompCat ::= \cdots \mid \Escape\;k\;\In\;M
|
|
\]
|
|
%
|
|
The variable $k$ is called the \emph{escape variable} and it is bound
|
|
in $M$. The escape variable exposes the current continuation of the
|
|
$\Escape$-expression to the programmer. The captured continuation is
|
|
abortive, thus an invocation of the escape variable in the body $M$
|
|
has the effect of performing a non-local exit.
|
|
%
|
|
|
|
In terms of jumps and labels the $\Escape$-expression can be
|
|
understood as corresponding to a kind of label and an application of
|
|
the escape variable $k$ can be understood as corresponding to a jump
|
|
to the label.
|
|
|
|
\citeauthor{Reynolds98a}' original treatise of escape was untyped, and
|
|
as such, the escape variable could escape its captor, e.g.
|
|
%
|
|
\[
|
|
\Let\;k \revto (\Escape\;k\;\In\;k)\;\In\; N
|
|
\]
|
|
%
|
|
Here the current continuation, $N$, gets bound to $k$ in the
|
|
$\Escape$-expression, which returns $k$ as-is, and thus becomes
|
|
available for use within $N$. \citeauthor{Reynolds98a} recognised the
|
|
power of this idiom and noted that it could be used to implement
|
|
coroutines and backtracking~\cite{Reynolds98a}.
|
|
%
|
|
\citeauthor{Reynolds98a} did not develop the static semantics for
|
|
$\Escape$, however, it is worth noting that this idiom require
|
|
recursive types to type check. Even in a language without recursive
|
|
types, the continuation may propagate outside its binding
|
|
$\Escape$-expression if the language provides an escape hatch such as
|
|
mutable references.
|
|
% In our simply-typed setting it is not possible for the continuation to
|
|
% propagate outside its binding $\Escape$-expression as it would require
|
|
% the addition of either recursive types or some other escape hatch like
|
|
% mutable reference cells.
|
|
% %
|
|
|
|
% The typing of $\Escape$ and $\Continue$ reflects that the captured
|
|
% continuation is abortive.
|
|
% %
|
|
% \begin{mathpar}
|
|
% \inferrule*
|
|
% {\typ{\Gamma,k : \Cont\,\Record{A;\Zero}}{M : A}}
|
|
% {\typ{\Gamma}{\Escape\;k\;\In\;M : A}}
|
|
|
|
% % \inferrule*
|
|
% % {\typ{\Gamma}{V : A} \\ \typ{\Gamma}{W : \Cont\,\Record{A;\Zero}}}
|
|
% % {\typ{\Gamma}{\Continue~W~V : \Zero}}
|
|
% \end{mathpar}
|
|
% %
|
|
% The return type of the continuation object can be taken as a telltale
|
|
% sign that an invocation of this object never returns, since there are
|
|
% no inhabitants of the empty type.
|
|
%
|
|
An invocation of the continuation discards the invocation context and
|
|
plugs the argument into the captured context.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Capture} & \EC[\Escape\;k\;\In\;M] &\reducesto& \EC[M[\qq{\cont_{\EC}}/k]]\\
|
|
\slab{Resume} & \EC[\Continue~\cont_{\EC'}~V] &\reducesto& \EC'[V]
|
|
\end{reductions}
|
|
%
|
|
The \slab{Capture} rule leaves the context intact such that if the
|
|
body $M$ does not invoke $k$ then whatever value $M$ reduces is
|
|
plugged into the context. The \slab{Resume} discards the current
|
|
context $\EC$ and installs the captured context $\EC'$ with the
|
|
argument $V$ plugged in.
|
|
|
|
\paragraph{\citeauthor{SussmanS75}'s catch}
|
|
%
|
|
In 1975 \citet{SussmanS75} designed and implemented the catch operator
|
|
in Scheme. It is a more powerful variant of the catch operator in
|
|
MacLisp~\cite{Moon74}. The MacLisp catch operator had a companion
|
|
throw operation, which would unwind the evaluation stack until it was
|
|
caught by an instance of catch. \citeauthor{SussmanS75}'s catch
|
|
operator dispenses with the throw operation and instead provides the
|
|
programmer with access to the current continuation. Their operator is
|
|
identical to \citeauthor{Reynolds98a}' escape operator, save for the
|
|
syntax.
|
|
%
|
|
\[
|
|
M,N ::= \cdots \mid \Catch~k.M
|
|
\]
|
|
%
|
|
Although, their syntax differ, their dynamic semantics are the same.
|
|
%
|
|
% \begin{mathpar}
|
|
% \inferrule*
|
|
% {\typ{\Gamma,k : \Cont\,\Record{A;\Zero}}{M : A}}
|
|
% {\typ{\Gamma}{\Catch~k.M : A}}
|
|
|
|
% % \inferrule*
|
|
% % {\typ{\Gamma}{V : A} \\ \typ{\Gamma}{W : \Cont\,\Record{A;B}}}
|
|
% % {\typ{\Gamma}{\Continue~W~V : B}}
|
|
% \end{mathpar}
|
|
%
|
|
\begin{reductions}
|
|
\slab{Capture} & \EC[\Catch~k.M] &\reducesto& \EC[M[\qq{\cont_{\EC}}/k]]\\
|
|
\slab{Resume} & \EC[\Continue~\cont_{\EC'}~V] &\reducesto& \EC'[V]
|
|
\end{reductions}
|
|
%
|
|
As an aside it is worth to mention that \citet{CartwrightF92} used a
|
|
variation of $\Catch$ to show that control operators enable programs
|
|
to observe the order of evaluation.
|
|
|
|
\paragraph{Call-with-current-continuation} In 1982 the Scheme
|
|
implementors observed that they could dispense of the special syntax
|
|
for $\Catch$ in favour of a higher-order function that would apply its
|
|
argument to the current continuation, and thus callcc was born (callcc
|
|
is short for
|
|
call-with-current-continuation)~\cite{AbelsonHAKBOBPCRFRHSHW85}.
|
|
%
|
|
|
|
Unlike the previous operators, callcc augments the syntactic
|
|
categories of values.
|
|
%
|
|
\[
|
|
V,W \in \ValCat ::= \cdots \mid \Callcc
|
|
\]
|
|
%
|
|
The value $\Callcc$ is essentially a hard-wired function name. Being a
|
|
value means that the operator itself is a first-class entity which
|
|
entails it can be passed to functions, returned from functions, and
|
|
stored in data structures. Operationally, $\Callcc$ captures the
|
|
current continuation and aborts it before applying it on its argument.
|
|
%
|
|
% The typing rule for $\Callcc$ testifies to the fact that it is a
|
|
% particular higher-order function.
|
|
%
|
|
% \begin{mathpar}
|
|
% \inferrule*
|
|
% {~}
|
|
% {\typ{\Gamma}{\Callcc : (\Cont\,\Record{A;\Zero} \to A) \to A}}
|
|
|
|
% % \inferrule*
|
|
% % {\typ{\Gamma}{V : A} \\ \typ{\Gamma}{W : \Cont\,\Record{A;B}}}
|
|
% % {\typ{\Gamma}{\Continue~W~V : B}}
|
|
% \end{mathpar}
|
|
% %
|
|
% An invocation of $\Callcc$ returns a value of type $A$. This value can
|
|
% be produced in one of two ways, either the function argument returns
|
|
% normally or it applies the provided continuation object to a value
|
|
% that then becomes the result of $\Callcc$-application.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Capture} & \EC[\Callcc~V] &\reducesto& \EC[V~\qq{\cont_{\EC}}]\\
|
|
\slab{Resume} & \EC[\Continue~\cont_{\EC'}~V] &\reducesto& \EC'[V]
|
|
\end{reductions}
|
|
%
|
|
From the dynamic semantics it is evident that $\Callcc$ is a
|
|
syntax-free alternative to $\Catch$ (although, it is treated as a
|
|
special value form here; in actual implementation it suffices to
|
|
recognise the object name of $\Callcc$). They are trivially
|
|
macro-expressible.
|
|
%
|
|
\begin{equations}
|
|
\sembr{\Catch~k.M} &\defas& \Callcc\,(\lambda k.\sembr{M})\\
|
|
\sembr{\Callcc} &\defas& \lambda f. \Catch~k.f\,k
|
|
\end{equations}
|
|
|
|
\paragraph{Call-with-composable-continuation} A variation of callcc is
|
|
call-with-composable-continuation, abbreviated \textCallcomc{}.
|
|
%
|
|
As the name suggests the captured continuation is composable rather
|
|
than abortive. It was introduced by \citet{FlattYFF07} in 2007, and
|
|
and implemented in November 2006 according to the history log of
|
|
Racket (Racket was then known as MzScheme, version
|
|
360)~\cite{Flatt20}. The history log classifies it as a delimited
|
|
control operator.
|
|
%
|
|
Truth to be told nowadays in Racket virtually all control operators
|
|
are delimited, even callcc, because they are parameterised by an
|
|
optional prompt tag. If the programmer does not supply a prompt tag at
|
|
invocation time then the optional parameter assume the actual value of
|
|
the top-level prompt, effectively making the extent of the captured
|
|
continuation undelimited.
|
|
%
|
|
In other words its default mode of operation is undelimited, hence the
|
|
justification for categorising it as such.
|
|
%
|
|
|
|
Like $\Callcc$ this operator is a value.
|
|
%
|
|
\[
|
|
V,W \in \ValCat ::= \cdots \mid \Callcomc
|
|
\]
|
|
%
|
|
% Unlike $\Callcc$, the continuation returns, which the typing rule for
|
|
% $\Callcomc$ reflects.
|
|
% %
|
|
% \begin{mathpar}
|
|
% \inferrule*
|
|
% {~}
|
|
% {\typ{\Gamma}{\Callcomc : (\Cont\,\Record{A;A} \to A) \to A}}
|
|
|
|
% \inferrule*
|
|
% {\typ{\Gamma}{V : A} \\ \typ{\Gamma}{W : \Cont\,\Record{A;B}}}
|
|
% {\typ{\Gamma}{\Continue~W~V : B}}
|
|
% \end{mathpar}
|
|
% %
|
|
% Both the domain and codomain of the continuation are the same as the
|
|
% body type of function argument.
|
|
Unlike $\Callcc$, captured continuations behave as functions.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Capture} & \EC[\Callcomc~V] &\reducesto& \EC[V~\qq{\cont_{\EC}}]\\
|
|
\slab{Resume} & \Continue~\cont_{\EC}~V &\reducesto& \EC[V]
|
|
\end{reductions}
|
|
%
|
|
The capture rule for $\Callcomc$ is identical to the rule for
|
|
$\Callcomc$, but the resume rule is different.
|
|
%
|
|
The effect of continuation invocation can be understood locally as it
|
|
does not erase the global evaluation context, but rather composes with
|
|
it.
|
|
%
|
|
To make this more tangible consider the following example reduction
|
|
sequence.
|
|
%
|
|
\begin{derivation}
|
|
&1 + \Callcomc\,(\lambda k. \Continue~k~(\Continue~k~0))\\
|
|
\reducesto^+ & \reason{\slab{Capture} $\EC = 1 + [~]$}\\
|
|
% &1 + ((\lambda k. \Continue~k~(\Continue~k~0))\,\cont_\EC)\\
|
|
% \reducesto & \reason{$\beta$-reduction}\\
|
|
&1 + (\Continue~\cont_\EC~(\Continue~\cont_\EC~0))\\
|
|
\reducesto^+ & \reason{\slab{Resume} with $\EC[0]$}\\
|
|
&1 + (\Continue~\cont_\EC~1)\\
|
|
\reducesto^+ & \reason{\slab{Resume} with $\EC[1]$}\\
|
|
&1 + 2 \reducesto 3
|
|
\end{derivation}
|
|
%
|
|
The operator reifies the current evaluation context as a continuation
|
|
object and passes it to the function argument. The evaluation context
|
|
is left in place. As a result an invocation of the continuation object
|
|
has the effect of duplicating the context. In this particular example
|
|
the context has been duplicated twice to produce the result $3$.
|
|
%
|
|
Contrast this result with the result obtained by using $\Callcc$.
|
|
%
|
|
\begin{derivation}
|
|
&1 + \Callcc\,(\lambda k. \Absurd\;\Continue~k~(\Absurd\;\Continue~k~0))\\
|
|
\reducesto^+ & \reason{\slab{Capture} $\EC = 1 + [~]$}\\
|
|
% &1 + ((\lambda k. \Continue~k~(\Continue~k~0))\,\cont_\EC)\\
|
|
% \reducesto & \reason{$\beta$-reduction}\\
|
|
&1 + (\Absurd\;\Continue~\cont_\EC~(\Absurd\;\Continue~\cont_\EC~0))\\
|
|
\reducesto & \reason{\slab{Resume} with $\EC[0]$}\\
|
|
&1\\
|
|
\end{derivation}
|
|
%
|
|
The second invocation of $\cont_\EC$ never enters evaluation position,
|
|
because the first invocation discards the entire evaluation context.
|
|
%
|
|
Our particular choice of syntax and static semantics already makes it
|
|
immediately obvious that $\Callcc$ cannot be directly substituted for
|
|
$\Callcomc$, and vice versa, in a way that preserves operational
|
|
behaviour. % The continuations captured by the two operators behave
|
|
% differently.
|
|
|
|
An interesting question is whether $\Callcc$ and $\Callcomc$ are
|
|
interdefinable. Presently, the literature does not seem to answer to
|
|
this question. I conjecture that the operators exhibit essential
|
|
differences, meaning they cannot encode each other.
|
|
%
|
|
The intuition behind this conjecture is that for any encoding of
|
|
$\Callcomc$ in terms of $\Callcc$ must be able to preserve the current
|
|
evaluation context, e.g. using a state cell akin to how
|
|
\citet{Filinski94} encodes composable continuations using abortive
|
|
continuations and state.
|
|
%
|
|
The other way around also appears to be impossible, because neither
|
|
the base calculus nor $\Callcomc$ has the ability to discard an
|
|
evaluation context.
|
|
%
|
|
\dhil{Remark that $\Callcomc$ was originally obtained by decomposing
|
|
$\fcontrol$ a continuation composing primitive and an abortive
|
|
primitive. Source: Matthew Flatt, comp.lang.scheme, May 2007}
|
|
|
|
\paragraph{\FelleisenC{} and \FelleisenF{}}
|
|
%
|
|
The C operator is a variation of callcc that provides control over the
|
|
whole continuation as it aborts the current continuation after
|
|
capture, whereas callcc implicitly invokes the current continuation on
|
|
the value of its argument. The C operator was introduced by
|
|
\citeauthor{FelleisenFKD86} in two papers during
|
|
1986~\cite{FelleisenF86,FelleisenFKD86}. The following year,
|
|
\citet{FelleisenFDM87} introduced the F operator which is a variation
|
|
of C, whose captured continuation is composable.
|
|
|
|
In our framework both operators are value forms.
|
|
%
|
|
\[
|
|
V,W \in \ValCat ::= \cdots \mid \FelleisenC \mid \FelleisenF
|
|
\]
|
|
%
|
|
% The static semantics of $\FelleisenC$ are the same as $\Callcc$,
|
|
% whilst the static semantics of $\FelleisenF$ are the same as
|
|
% $\Callcomc$.
|
|
% \begin{mathpar}
|
|
% \inferrule*
|
|
% {~}
|
|
% {\typ{\Gamma}{\FelleisenC : (\Cont\,\Record{A;\Zero} \to A) \to A}}
|
|
|
|
% \inferrule*
|
|
% {~}
|
|
% {\typ{\Gamma}{\FelleisenF : (\Cont\,\Record{A;A} \to A) \to A}}
|
|
% \end{mathpar}
|
|
%
|
|
The dynamic semantics of $\FelleisenC$ and $\FelleisenF$ are as
|
|
follows.
|
|
%
|
|
\begin{reductions}
|
|
\slab{C\textrm{-}Capture} & \EC[\FelleisenC\,V] &\reducesto& V~\qq{\cont_{\EC}}\\
|
|
\slab{C\textrm{-}Resume} & \EC[\Continue~\cont_{\EC'}~V] &\reducesto& \EC'[V] \medskip\\
|
|
\slab{F\textrm{-}Capture} & \EC[\FelleisenF\,V] &\reducesto& V~\qq{\cont_{\EC}}\\
|
|
\slab{F\textrm{-}Resume} & \Continue~\cont_{\EC}~V &\reducesto& \EC[V]
|
|
\end{reductions}
|
|
%
|
|
Their capture rules are identical. Both operators abort the current
|
|
continuation upon capture. This is what set $\FelleisenF$ apart from
|
|
the other composable control operator $\Callcomc$.
|
|
%
|
|
The resume rules of $\FelleisenC$ and $\FelleisenF$ show the
|
|
difference between the two operators. The $\FelleisenC$ operator
|
|
aborts the current continuation and reinstall the then-current
|
|
continuation just like $\Callcc$, whereas the resumption of a
|
|
continuation captured by $\FelleisenF$ composes the current
|
|
continuation with the then-current continuation.
|
|
|
|
\citet{FelleisenFDM87} show that $\FelleisenF$ can simulate
|
|
$\FelleisenC$.
|
|
%
|
|
\[
|
|
\sembr{\FelleisenC} \defas \lambda m.\FelleisenF\,(\lambda k. m\,(\lambda v.\FelleisenF\,(\lambda\_.k~v)))
|
|
\]
|
|
%
|
|
The first application of $\FelleisenF$ has the effect of aborting the
|
|
current continuation, whilst the second application of $\FelleisenF$
|
|
aborts the invocation context.
|
|
|
|
\citet{FelleisenFDM87} also postulate that $\FelleisenC$ cannot express $\FelleisenF$.
|
|
|
|
\paragraph{\citeauthor{Landin98}'s J operator}
|
|
%
|
|
The J operator was introduced by Peter Landin in 1965 (making it the
|
|
world's \emph{first} first-class control operator) as a means for
|
|
translating jumps and labels in the statement-oriented language
|
|
\Algol{} into an expression-oriented
|
|
language~\cite{Landin65,Landin65a,Landin98}. Landin used the J
|
|
operator to account for the meaning of \Algol{} labels.
|
|
%
|
|
The following example due to \citet{DanvyM08} provides a flavour of
|
|
the correspondence between labels and J.
|
|
%
|
|
\[
|
|
\ba{@{}l@{~}l}
|
|
&\mathcal{S}\sembr{\keyw{begin}\;s_1;\;\keyw{goto}\;L;\;L:\,s_2\;\keyw{end}}\\
|
|
=& \lambda\Unit.\Let\;L \revto \J\,\mathcal{S}\sembr{s_2}\;\In\;\Let\;\Unit \revto \mathcal{S}\sembr{s_1}\,\Unit\;\In\;\Continue~L\,\Unit
|
|
\ea
|
|
\]
|
|
%
|
|
Here $\mathcal{S}\sembr{-}$ denotes the translation of statements. In the image,
|
|
the label $L$ manifests as an application of $\J$ and the
|
|
$\keyw{goto}$ manifests as an application of continuation captured by
|
|
$\J$.
|
|
%
|
|
The operator extends the syntactic category of values with a new
|
|
form.
|
|
%
|
|
\[
|
|
V,W \in \ValCat ::= \cdots \mid \J
|
|
\]
|
|
%
|
|
The previous example hints at the fact that the J operator is quite
|
|
different to the previously considered undelimited control operators
|
|
in that the captured continuation is \emph{not} the current
|
|
continuation, but rather, the continuation of statically enclosing
|
|
$\lambda$-abstraction. In other words, $\J$ provides access to the
|
|
continuation of its the caller.
|
|
%
|
|
To this effect, the continuation object produced by an application of
|
|
$\J$ may be thought of as a first-class variation of the return
|
|
statement commonly found in statement-oriented languages. Since it is
|
|
a first-class object it can be passed to another function, meaning
|
|
that any function can endow other functions with the ability to return
|
|
from it, e.g.
|
|
%
|
|
\[
|
|
\dec{f} \defas \lambda g. \Let\;return \revto \J\,(\lambda x.x) \;\In\; g~return;~\True
|
|
\]
|
|
%
|
|
If the function $g$ does not invoke its argument, then $\dec{f}$
|
|
returns $\True$, e.g.
|
|
\[
|
|
\dec{f}~(\lambda return.\False) \reducesto^+ \True
|
|
\]
|
|
%
|
|
However, if $g$ does apply its argument, then the value provided to
|
|
the application becomes the return value of $\dec{f}$, e.g.
|
|
%
|
|
\[
|
|
\dec{f}~(\lambda return.\Continue~return~\False) \reducesto^+ \False
|
|
\]
|
|
%
|
|
The function argument gets post-composed with the continuation of the
|
|
calling context.
|
|
%
|
|
The particular application $\J\,(\lambda x.x)$ is so idiomatic that it
|
|
has its own name: $\JI$, where $\keyw{I}$ is the identity function.
|
|
|
|
% Clearly, the return type of a continuation object produced by an $\J$
|
|
% application must be the same as the caller of $\J$. Thus to type $\J$
|
|
% we must track the type of calling context. Formally, we track the type
|
|
% of the context by extending the typing judgement relation with an
|
|
% additional singleton context $\Delta$. This context is modified by the
|
|
% typing rule for $\lambda$-abstraction and used by the typing rule for
|
|
% $\J$-applications. This is similar to type checking of return
|
|
% statements in statement-oriented programming languages.
|
|
% %
|
|
% \begin{mathpar}
|
|
% \inferrule*
|
|
% {\typ{\Gamma,x:A;B}{M : B}}
|
|
% {\typ{\Gamma;\Delta}{\lambda x.M : A \to B}}
|
|
|
|
% \inferrule*
|
|
% {~}
|
|
% {\typ{\Gamma;B}{\J : (A \to B) \to \Cont\,\Record{A;B}}}
|
|
|
|
% % \inferrule*
|
|
% % {\typ{\Gamma;\Delta}{V : A} \\ \typ{\Gamma;\Delta}{W : \Cont\,\Record{A;B}}}
|
|
% % {\typ{\Gamma;\Delta}{\Continue~W~V : B}}
|
|
% \end{mathpar}
|
|
%
|
|
Any meaningful applications of $\J$ must appear under a
|
|
$\lambda$-abstraction, because the application captures its caller's
|
|
continuation. In order to capture the caller's continuation we
|
|
annotate the evaluation contexts for ordinary applications.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Annotate} & \EC[(\lambda x.M)\,V] &\reducesto& \EC_\lambda[M[V/x]]\\
|
|
\slab{Capture} & \EC_{\lambda}[\mathcal{D}[\J\,W]] &\reducesto& \EC_{\lambda}[\mathcal{D}[\qq{\cont_{\Record{\EC_{\lambda};W}}}]]\\
|
|
\slab{Resume} & \EC[\Continue~\cont_{\Record{\EC';W}}\,V] &\reducesto& \EC'[W\,V]
|
|
\end{reductions}
|
|
%
|
|
% \dhil{The continuation object should have time $\Cont\,\Record{A;\Zero}$}
|
|
%
|
|
The $\slab{Capture}$ rule only applies if the application of $\J$
|
|
takes place inside an annotated evaluation context. The continuation
|
|
object produced by a $\J$ application encompasses the caller's
|
|
continuation $\EC_\lambda$ and the value argument $W$.
|
|
%
|
|
This continuation object may be invoked in \emph{any} context. An
|
|
invocation discards the current continuation $\EC$ and installs $\EC'$
|
|
instead with the $\J$-argument $W$ applied to the value $V$.
|
|
|
|
\citeauthor{Landin98} and \citeauthor{Thielecke02} noticed that $\J$
|
|
can be recovered from the special form
|
|
$\JI$~\cite{Thielecke02}. Taking $\JI$ to be a primitive, we can
|
|
translate $\J$ to a language with $\JI$ as follows.
|
|
%
|
|
\[
|
|
\sembr{\J} \defas (\lambda k.\lambda f.\lambda x.\Continue\;k\,(f\,x))\,(\JI)
|
|
\]
|
|
%
|
|
The term $\JI$ captures the caller continuation, which gets bound to
|
|
$k$. The shape of the residual term is as expected: when $\sembr{\J}$
|
|
is applied to a function, it returns another function, which when
|
|
applied ultimately invokes the captured continuation.
|
|
%
|
|
% Strictly speaking in our setting this encoding is not faithful,
|
|
% because we do not treat continuations as first-class functions,
|
|
% meaning the types are not going to match up. An application of the
|
|
% left hand side returns a continuation object, whereas an application
|
|
% of the right hand side returns a continuation function.
|
|
|
|
Let us end by remarking that the J operator is expressive enough to
|
|
encode a familiar control operator like $\Callcc$~\cite{Thielecke98}.
|
|
%
|
|
\[
|
|
\sembr{\Callcc} \defas \lambda f. f\,\JI
|
|
\]
|
|
%
|
|
\citet{Felleisen87b} has shown that the J operator can be
|
|
syntactically embedded using callcc.
|
|
%
|
|
\[
|
|
\sembr{\lambda x.M} \defas \lambda x.\Callcc\,(\lambda k.\sembr{M}[\J \mapsto \lambda f.\lambda y. k~(f\,y)])
|
|
\]
|
|
%
|
|
The key point here is that $\lambda$-abstractions are not translated
|
|
homomorphically. The occurrence of $\Callcc$ immediately under the
|
|
binder reifies the current continuation of the function, which is the
|
|
precisely the caller continuation in the body $M$. In $M$ the symbol
|
|
$\J$ is substituted with a function that simulates $\J$ by
|
|
post-composing the captured continuation with the function argument
|
|
provided to $\J$.
|
|
|
|
\subsection{Delimited control operators}
|
|
%
|
|
The main problem with undelimited control is that it is the
|
|
programmatic embodiment of the proverb \emph{all or nothing} in the
|
|
sense that an undelimited continuation always represent the entire
|
|
residual program from its point of capture. In its basic form
|
|
undelimited control does not offer the flexibility to reify only some
|
|
segments of the evaluation context.
|
|
%
|
|
Delimited control rectifies this problem by associating each control
|
|
operator with a control delimiter such that designated segments of the
|
|
evaluation context can be captured individually without interfering
|
|
with the context beyond the delimiter. This provides a powerful and
|
|
modular programmatic tool that enables programmers to isolate the
|
|
control flow of specific parts of their programs, and thus enables
|
|
local reasoning about the behaviour of control infused program
|
|
segments.
|
|
%
|
|
One may argue that delimited control to an extent is more first-class
|
|
than undelimited control, because, in contrast to undelimited control,
|
|
it provides more fine-grain control over the evaluation context.
|
|
%
|
|
% Essentially, delimited control adds the excluded middle: \emph{all,
|
|
% some, or nothing}.
|
|
|
|
In 1988 \citeauthor{Felleisen88} introduced the first control
|
|
delimiter known as `prompt', as a companion to the composable control
|
|
operator F (alias control)~\cite{Felleisen88}.
|
|
%
|
|
\citeauthor{Felleisen88}'s line of work was driven by a dynamic
|
|
interpretation of composable continuations in terms of algebraic
|
|
manipulation of control component of abstract machines. In the
|
|
context of abstract machines, a continuation is defined as a sequence
|
|
of frames, whose end is denoted by a prompt, and continuation
|
|
composition is concatenation of their
|
|
sequences~\cite{Felleisen87,FelleisenF86,FelleisenWFD88}.
|
|
%
|
|
The natural outcome of this interpretation is the control phenomenon
|
|
known as \emph{dynamic delimited control}, where the control operator
|
|
is dynamically bound by its delimiter. An application of a control
|
|
operator causes the machine to scour through control component to
|
|
locate the corresponding delimiter.
|
|
|
|
The following year, \citet{DanvyF89} introduced an alternative pair of
|
|
operators known as `shift' and `reset', where `shift' is the control
|
|
operator and `reset' is the control delimiter. Their line of work were
|
|
driven by a static interpretation of composable continuations in terms
|
|
of continuation passing style (CPS). In ordinary CPS a continuation is
|
|
represented as a function, however, there is no notion of composition,
|
|
because every function call must appear in tail position. The `shift'
|
|
operator enables composition of continuation functions as it provides
|
|
a means for abstracting over control contexts. Technically, this works
|
|
by iterating the CPS transform twice on the source program, where
|
|
`shift' provides access to continuations that arise from the second
|
|
transformation. The `reset' operator acts as the identity for
|
|
continuation functions, which effectively delimits the extent of
|
|
`shift' as in terms of CPS the identity function denotes the top-level
|
|
continuation.
|
|
%
|
|
This interpretation of composable continuations as functions naturally
|
|
leads to the control phenomenon known as \emph{static delimited
|
|
control}, where the control operator is statically bound by its
|
|
delimiter.
|
|
|
|
The machine interpretation and continuation passing style
|
|
interpretation of composable continuations were eventually connected
|
|
through defunctionalisation and refunctionalisation in a line of work
|
|
by \citeauthor{Danvy04a} and
|
|
collaborators~\cite{DanvyN01,AgerBDM03,Danvy04,AgerDM04,Danvy04a,AgerDM05,DanvyM09}.
|
|
|
|
|
|
% The following year, \citet{DanvyF89} introduced an alternative pair of
|
|
% operators known as `shift' and `reset', where `shift' is the control
|
|
% operator and `reset' is the control delimiter. Their line of work were
|
|
% driven by a static interpretation of composable continuations in terms
|
|
% of algebraic manipulation of continuations arising from hierarchical
|
|
% continuation passing style (CPS) transformations. In ordinary CPS a
|
|
% continuation is represented as a function, which is abortive rather
|
|
% than composable, because every function application appear in tail
|
|
% position.
|
|
% %
|
|
% The operators `shift' and `reset' were introduced as a programmatic
|
|
% way to manipulate and compose continuations. Algebraically `shift'
|
|
% corresponds to the composition operation for continuation functions,
|
|
% whereas `reset' corresponds to the identity
|
|
% element~\cite{DanvyF89,DanvyF90,DanvyF92}.
|
|
% %
|
|
% Technically, the operators operate on a meta layer, which is obtained
|
|
% by CPS transforming the image again. An indefinite amount of meta
|
|
% layers can be obtained by iterating the CPS transformation on its
|
|
% image, leading to a whole hierarchy of CPS.
|
|
% %
|
|
% %
|
|
% \dhil{Consider dropping the blurb about hierarchy/meta layers.}
|
|
|
|
Since control/prompt and shift/reset a whole variety of alternative
|
|
delimited control operators has appeared.
|
|
|
|
% Delimited control: Control delimiters form the basis for delimited
|
|
% control. \citeauthor{Felleisen88} introduced control delimiters in
|
|
% 1988, although allusions to control delimiters were made a year
|
|
% earlier by \citet{FelleisenFDM87} and in \citeauthor{Felleisen87}'s
|
|
% PhD dissertation~\cite{Felleisen87}. The basic idea was teased even
|
|
% earlier in \citeauthor{Talcott85}'s teased the idea of control
|
|
% delimiters in her PhD dissertation~\cite{Talcott85}.
|
|
% %
|
|
% Common Lisp resumable exceptions (condition system)~\cite{Steele90},
|
|
% F~\cite{FelleisenFDM87,Felleisen88}, control/prompt~\cite{SitaramF90},
|
|
% shift/reset~\cite{DanvyF89,DanvyF90}, splitter~\cite{QueinnecS91},
|
|
% fcontrol~\cite{Sitaram93}, catchcont~\cite{LongleyW08}, effect
|
|
% handlers~\cite{PlotkinP09}.
|
|
|
|
% Comparison of various delimited control
|
|
% operators~\cite{Shan04}. Simulation of delimited control using
|
|
% undelimited control~\cite{Filinski94}
|
|
|
|
\paragraph{\citeauthor{Felleisen88}'s control and prompt}
|
|
%
|
|
Control and prompt were introduced by \citeauthor{Felleisen88} in
|
|
1988~\cite{Felleisen88}. The control operator `control' is a
|
|
rebranding of the F operator. Although, the name `control' was first
|
|
introduced a little later by \citet{SitaramF90}. A prompt acts as a
|
|
control-flow barrier that delimits different parts of a program,
|
|
enabling programmers to manipulate and reason about control locally in
|
|
different parts of a program. The name `prompt' is intended to draw
|
|
connections to shell prompts, and how they act as barriers between the
|
|
user and operating system.
|
|
%
|
|
|
|
In this presentation both control and prompt appear as computation
|
|
forms.
|
|
%
|
|
\begin{syntax}
|
|
&M,W \in \CompCat &::=& \cdots \mid \Control~k.M \mid \Prompt~M
|
|
\end{syntax}
|
|
%
|
|
The $\Control~k.M$ expression reifies the context up to the nearest,
|
|
dynamically determined, enclosing prompt and binds it to $k$ inside of
|
|
$M$. A prompt is written using the sharp ($\Prompt$) symbol.
|
|
%
|
|
The prompt remains in place after the reification, and thus any
|
|
subsequent application of $\Control$ will be delimited by the same
|
|
prompt.
|
|
%
|
|
Presenting $\Control$ as a binding form may conceal the fact that it
|
|
is same as $\FelleisenF$. However, the presentation here is close to
|
|
\citeauthor{SitaramF90}'s presentation, which in turn is close to
|
|
actual implementations of $\Control$.
|
|
|
|
The static semantics of control and prompt were absent in
|
|
\citeauthor{Felleisen88}'s original treatment.
|
|
%
|
|
\dhil{Mention Yonezawa and Kameyama's type system.}
|
|
%
|
|
\citet{DybvigJS07} gave a typed embedding of multi-prompts in
|
|
Haskell. In the multi-prompt setting the prompts are named and an
|
|
instance of $\Control$ is indexed by the prompt name of its designated
|
|
delimiter.
|
|
|
|
% Typing them, particularly using a simple type system,
|
|
% affect their expressivity, because the type of the continuation object
|
|
% produced by $\Control$ must be compatible with the type of its nearest
|
|
% enclosing prompt -- this type is often called the \emph{answer} type
|
|
% (this terminology is adopted from typed continuation passing style
|
|
% transforms, where the codomain of every function is transformed to
|
|
% yield the type of whatever answer the entire program
|
|
% yields~\cite{MeyerW85}).
|
|
% %
|
|
% \dhil{Give intuition for why soundness requires the answer type to be fixed.}
|
|
% %
|
|
|
|
% In the static semantics we extend the typing judgement relation to
|
|
% contain an up front fixed answer type $A$.
|
|
% %
|
|
% \begin{mathpar}
|
|
% \inferrule*
|
|
% {\typ{\Gamma;A}{M : A}}
|
|
% {\typ{\Gamma;A}{\Prompt~M : A}}
|
|
|
|
% \inferrule*
|
|
% {~}
|
|
% {\typ{\Gamma;A}{\Control : (\Cont\,\Record{A;A} \to A) \to A}}
|
|
% \end{mathpar}
|
|
% %
|
|
% A prompt has the same type as its computation constituent, which in
|
|
% turn must have the same type as fixed answer type.
|
|
% %
|
|
% Similarly, the type of $\Control$ is governed by the fixed answer
|
|
% type. Discarding the answer type reveals that $\Control$ has the same
|
|
% typing judgement as $\FelleisenF$.
|
|
% %
|
|
|
|
The dynamic semantics for control and prompt consist of three rules:
|
|
1) handle return through a prompt, 2) continuation capture, and 3)
|
|
continuation invocation.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Value} &
|
|
\Prompt~V &\reducesto& V\\
|
|
\slab{Capture} &
|
|
\Prompt~\EC[\Control~k.M] &\reducesto& \Prompt~M[\qq{\cont_{\EC}}/k], \text{ where $\EC$ contains no \Prompt}\\
|
|
\slab{Resume} & \Continue~\cont_{\EC}~V &\reducesto& \EC[V]
|
|
\end{reductions}
|
|
%
|
|
The \slab{Value} rule accounts for the case when the computation
|
|
constituent of $\Prompt$ has been reduced to a value, in which case
|
|
the prompt is removed and the value is returned.
|
|
%
|
|
The \slab{Capture} rule states that an application of $\Control$
|
|
captures the current continuation up to the nearest enclosing
|
|
prompt. The current continuation (up to the nearest prompt) is also
|
|
aborted. If we erase $\Prompt$ from the rule, then it is clear that
|
|
$\Control$ has the same dynamic behaviour as $\FelleisenF$.
|
|
%
|
|
It is evident from the \slab{Resume} rule that control and prompt are
|
|
an instance of a dynamic control operator, because resuming the
|
|
continuation object produced by $\Control$ does not install a new
|
|
prompt.
|
|
|
|
To illustrate $\Prompt$ and $\Control$ in action, let us consider a
|
|
few simple examples.
|
|
%
|
|
\begin{derivation}
|
|
& 1 + \Prompt~2 + (\Control~k.3 + k~0) + (\Control~k'.k'~4)\\
|
|
\reducesto^+& \reason{Capture $\EC = 2 + [\,] + (\Control~k'.k'~4)$}\\
|
|
& 1 + \Prompt~3+\Continue~\cont_{\EC}~0\\
|
|
\reducesto & \reason{Resume with 0}\\
|
|
& 1 + \Prompt~3 + (2 + 0) + (\Control~k'.k'~4)\\
|
|
\reducesto^+ & \reason{Capture $\EC' = 5 + [\,]$}\\
|
|
& 1 + \Prompt~\Continue~\cont_{\EC'}~4\\
|
|
\reducesto^+ & \reason{Resume with 4}\\
|
|
& 1 + \Prompt~5 + 4\\
|
|
\reducesto^+ & \reason{\slab{Value} rule}\\
|
|
& 1 + 9 \reducesto 10
|
|
\end{derivation}
|
|
%
|
|
The continuation captured by the either application of $\Control$ is
|
|
oblivious to the continuation $1 + [\,]$ of $\Prompt$. Since the
|
|
captured continuation is composable it returns to its call site. The
|
|
invocation of the captured continuation $k$ returns the value 0, but
|
|
splices the captured context into the context $3 + [\,]$. The second
|
|
application of $\Control$ captures the new context up to the
|
|
delimiter. The continuation is immediately applied to the value 4,
|
|
which causes the captured context to be reinstated with the value 4
|
|
plugged in. Ultimately the delimited context reduces to the value $9$,
|
|
after which the prompt $\Prompt$ gets eliminated, and the continuation
|
|
of the $\Prompt$ is applied to the value $9$, resulting in the final
|
|
result $10$.
|
|
|
|
Let us consider a slight variation of the previous example.
|
|
%
|
|
\begin{derivation}
|
|
& 1 + \Prompt~2 + (\Control~k.3 + k~0) + (\Control~k'.4)\\
|
|
\reducesto^+& \reason{Capture $\EC = 2 + [\,] + (\Control~k'.4)$}\\
|
|
& 1 + \Prompt~3+\Continue~\cont_{\EC}~0\\
|
|
\reducesto & \reason{Resume with 0}\\
|
|
& 1 + \Prompt~3 + (2 + 0) + (\Control~k'.4)\\
|
|
\reducesto^+ & \reason{Capture $\EC' = 5 + [\,]$}\\
|
|
& 1 + \Prompt~4\\
|
|
\reducesto^+ & \reason{\slab{Value} rule}\\
|
|
& 1 + 4 \reducesto 5
|
|
\end{derivation}
|
|
%
|
|
Here the computation constituent of the second application of
|
|
$\Control$ drops the captured continuation, which has the effect of
|
|
erasing the previous computation, ultimately resulting in the value
|
|
$5$ rather than $10$.
|
|
% \begin{derivation}
|
|
% & 1 + \Prompt~2 + (\Control~k.\Continue~k~0) + (\Control~k'. 0)\\
|
|
% \reducesto^+& \reason{Capture $\EC = 2 + [\,] + (\Control~k'.0)$}\\
|
|
% & 1 + \Prompt~\Continue~\cont_{\EC}~0\\
|
|
% \reducesto & \reason{Resume with 0}\\
|
|
% & 1 + \Prompt~2 + 0 + (\Control~k'. 0)\\
|
|
% \reducesto^+ & \reason{Capture $\EC' = 2 + [\,]$}\\
|
|
% & 1 + \Prompt~0 \\
|
|
% \reducesto & \reason{\slab{Value} rule}\\
|
|
% & 1 + 0 \reducesto 1
|
|
% \end{derivation}
|
|
%
|
|
The continuation captured by the first application of $\Control$
|
|
contains another application of $\Control$. The application of the
|
|
continuation immediate reinstates the captured context filling the
|
|
hole left by the first instance of $\Control$ with the value $0$. The
|
|
second application of $\Control$ captures the remainder of the
|
|
computation of to $\Prompt$. However, the captured context gets
|
|
discarded, because the continuation $k'$ is never invoked.
|
|
%
|
|
\dhil{Mention control0/prompt0 and the control hierarchy}
|
|
|
|
\paragraph{\citeauthor{DanvyF90}'s shift and reset} Shift and reset
|
|
first appeared in a technical report by \citeauthor{DanvyF89} in
|
|
1989. Although, perhaps the most widely known account of shift and
|
|
reset appeared in \citeauthor{DanvyF90}'s treatise on abstracting
|
|
control the following year~\cite{DanvyF90}.
|
|
%
|
|
Shift and reset differ from control and prompt in that the contexts
|
|
abstracted by shift are statically scoped by reset.
|
|
|
|
% As with control and prompt, in our setting, shift appears as a value,
|
|
% whilst reset appear as a computation.
|
|
In our setting both shift and reset appear as computation forms.
|
|
%
|
|
\begin{syntax}
|
|
% & V, W &::=& \cdots \mid \shift\\
|
|
& M, N &::=& \cdots \mid \shift\; k.M \mid \reset{M}
|
|
\end{syntax}
|
|
%
|
|
The $\shift$ construct captures the continuation delimited by an
|
|
enclosing $\reset{-}$ and binds it to $k$ in the computation $M$.
|
|
|
|
\citeauthor{DanvyF89}'s original development of shift and reset stands
|
|
out from the previous developments of control operators, as they
|
|
presented a type system for shift and reset, whereas previous control
|
|
operators were originally studied in untyped settings.
|
|
%
|
|
The standard inference-based approach to type
|
|
checking~\cite{Plotkin81,Plotkin04a} is inadequate for type checking
|
|
shift and reset, because shift may alter the \emph{answer type} of the
|
|
expression (the terminology `answer type' is adopted from typed
|
|
continuation passing style transforms, where the codomain of every
|
|
function is transformed to yield the type of whatever answer the
|
|
entire program yields~\cite{MeyerW85}).
|
|
%
|
|
To capture the potent power of shift in the type system they
|
|
introduced the notion of \emph{answer type
|
|
modification}~\cite{DanvyF89}.
|
|
%
|
|
The addition of answer type modification changes type judgement to be
|
|
a five place relation.
|
|
%
|
|
\[
|
|
\typ{\Gamma;B}{M : A; B'}
|
|
\]
|
|
%
|
|
This would be read as: in a context $\Gamma$ where the original result
|
|
type was $B$, the type of $M$ is $A$, and modifies the result type to
|
|
$B'$. In this system the typing rule for $\shift$ is as follows.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{\typ{\Gamma,k : A / C \to B / C;D}{M : D;B'}}
|
|
{\typ{\Gamma;B}{\shift\;k.M : A;B'}}
|
|
\end{mathpar}
|
|
%
|
|
Here the function type constructor $-/- \to -/-$ has been endowed with
|
|
the domain and codomain of the continuation. The left hand side of
|
|
$\to$ contains the domain type of the function and the codomain of the
|
|
continuation, respectively. The right hand side contains the domain of
|
|
the continuation and the codomain of the function, respectively.
|
|
|
|
Answer type modification is a powerful feature that can be used to
|
|
type embedded languages, an illustrious application of this is
|
|
\citeauthor{Danvy98}'s typed $\dec{printf}$~\cite{Danvy98}. A
|
|
polymorphic extension of answer type modification has been
|
|
investigated by \citet{AsaiK07}, \citet{KiselyovS07} developed a
|
|
substructural type system with answer type modification, whilst
|
|
\citet{KoboriKK16} demonstrated how to translate from a source
|
|
language with answer type modification into a system without using
|
|
typed multi-prompts.
|
|
|
|
Differences between shift/reset and control/prompt manifests in the
|
|
dynamic semantics as well.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Value} & \reset{V} &\reducesto& V\\
|
|
\slab{Capture} & \reset{\EC[\shift\;k.M]} &\reducesto& \reset{M[\qq{\cont_{\EC}}/k]}, \text { where $\EC$ contains no $\reset{-}$}\\
|
|
% \slab{Resume} & \reset{\EC[\Continue~\cont_{\reset{\EC'}}~V]} &\reducesto& \reset{\EC[\reset{\EC'[V]}]}\\
|
|
\slab{Resume} & \Continue~\cont_{\EC}~V &\reducesto& \reset{\EC[V]}\\
|
|
\end{reductions}
|
|
%
|
|
The $\slab{Value}$ and $\slab{Capture}$ rules are the same as for
|
|
control/prompt (modulo the syntactic differences). The static nature
|
|
of shift/reset manifests operationally in the $\slab{Resume}$ rule,
|
|
where the reinstalled context $\EC$ gets enclosed in a new reset. The
|
|
extra reset has ramifications for the operational behaviour of
|
|
subsequent occurrences of $\shift$ in $\EC$. To put this into
|
|
perspective, let us revisit the second control/prompt example with
|
|
shift/reset instead.
|
|
%
|
|
\begin{derivation}
|
|
& 1 + \reset{2 + (\shift\;k.3 + k\,0) + (\shift\;k'.4)}\\
|
|
\reducesto^+& \reason{Capture $\EC = 2 + [\,] + (\shift\;k.4)$}\\
|
|
& 1 + \reset{\Continue~\cont_{\EC}~0}\\
|
|
\reducesto & \reason{Resume with 0}\\
|
|
& 1 + \reset{3 + \reset{2 + 0 + (\shift\;k'. 4)}}\\
|
|
\reducesto^+ & \reason{Capture $\EC' = 2 + [\,]$}\\
|
|
& 1 + \reset{3 + \reset{4}} \\
|
|
\reducesto^+ & \reason{\slab{Value} rule}\\
|
|
& 1 + \reset{7} \reducesto^+ 8 \\
|
|
\end{derivation}
|
|
%
|
|
Contrast this result with the result $5$ obtained when using
|
|
control/prompt. In essence the insertion of a new reset after
|
|
resumption has the effect of remembering the local context of the
|
|
previous continuation invocation.
|
|
|
|
This difference naturally raises the question whether shift/reset and
|
|
control/prompt are interdefinable or exhibit essential expressivity
|
|
differences. This question was answered by \citet{Shan04}, who
|
|
demonstrated that shift/reset and control/prompt are
|
|
macro-expressible. The translations are too intricate to be reproduced
|
|
here, however, it is worth noting that \citeauthor{Shan04} were
|
|
working in the untyped setting of Scheme and the translation of
|
|
control/prompt made use of recursive
|
|
continuations. \citet{BiernackiDS05} typed and reimplemented this
|
|
translation in Standard ML New Jersey~\cite{AppelM91}, using
|
|
\citeauthor{Filinski94}'s encoding of shift/reset in terms of callcc
|
|
and state~\cite{Filinski94}.
|
|
%
|
|
%
|
|
\dhil{Maybe mention the implication is that control/prompt has CPS semantics.}
|
|
\dhil{Mention shift0/reset0, dollar0\dots}
|
|
% \begin{reductions}
|
|
% % \slab{Value} & \reset{V} &\reducesto& V\\
|
|
% \slab{Capture} & \reset{\EC[\shift\,k.M]} &\reducesto& M[\cont_{\reset{\EC}}/k]\\
|
|
% % \slab{Resume} & \Continue~\cont_{\reset{\EC}}~V &\reducesto& \reset{\EC[V]}\\
|
|
% \end{reductions}
|
|
%
|
|
|
|
\paragraph{\citeauthor{QueinnecS91}'s splitter} The `splitter' control
|
|
operator reconciles abortive undelimited control and composable
|
|
delimited control. It was introduced by \citet{QueinnecS91} in
|
|
1991. The name `splitter' is derived from it operational behaviour, as
|
|
an application of `splitter' marks evaluation context in order for it
|
|
to be split into two parts, where the context outside the mark
|
|
represents the rest of computation, and the context inside the mark
|
|
may be reified into a delimited continuation. The operator supports
|
|
two operations `abort' and `calldc' to control the splitting of
|
|
evaluation contexts. The former has the effect of escaping to the
|
|
outer context, whilst the latter reifies the inner context as a
|
|
delimited continuation (the operation name is short for ``call with
|
|
delimited continuation'').
|
|
|
|
Splitter and the two operations abort and calldc are value forms.
|
|
%
|
|
\[
|
|
V,W ::= \cdots \mid \splitter \mid \abort \mid \calldc
|
|
\]
|
|
%
|
|
In their treatise of splitter, \citeauthor{QueinnecS91} gave three
|
|
different presentations of splitter. The presentation that I have
|
|
opted for here is close to their second presentation, which is in
|
|
terms of multi-prompt continuations. This variation of splitter admits
|
|
a pleasant static semantics too. Thus, we further extend the syntactic
|
|
categories with the machinery for first-class prompts.
|
|
%
|
|
\begin{syntax}
|
|
& A,B &::=& \cdots \mid \prompttype~A \smallskip\\
|
|
& V,W &::=& \cdots \mid p\\
|
|
& M,N &::=& \cdots \mid \Prompt_V~M
|
|
\end{syntax}
|
|
%
|
|
The type $\prompttype~A$ classifies prompts whose answer type is
|
|
$A$. Prompt names are first-class values and denoted by $p$. The
|
|
computation $\Prompt_V~M$ denotes a computation $M$ delimited by a
|
|
parameterised prompt, whose value parameter $V$ is supposed to be a
|
|
prompt name.
|
|
%
|
|
The static semantics of $\splitter$, $\abort$, and $\calldc$ are as
|
|
follows.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{~}
|
|
{\typ{\Gamma}{\splitter : (\prompttype~A \to A) \to A}}
|
|
|
|
\inferrule*
|
|
{~}
|
|
{\typ{\Gamma}{\abort : \prompttype~A \times (\UnitType \to A) \to B}}
|
|
|
|
\inferrule*
|
|
{~}
|
|
{\typ{\Gamma}{\calldc : \prompttype~A \times ((B \to A) \to B) \to B}}
|
|
\end{mathpar}
|
|
%
|
|
In this presentation, the operator and the two operations all amount
|
|
to special higher-order function symbols. The argument to $\splitter$
|
|
is parameterised by a prompt name. This name is injected by
|
|
$\splitter$ upon application. The operations $\abort$ and $\calldc$
|
|
both accept as their first argument the name of the delimiting
|
|
prompt. The second argument of $\abort$ is a thunk, whilst the second
|
|
argument of $\calldc$ is a higher-order function, which accepts a
|
|
continuation as its argument.
|
|
|
|
For the sake of completeness the prompt primitives are typed as
|
|
follows.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{~}
|
|
{\typ{\Gamma,p:\prompttype~A}{p : \prompttype~A}}
|
|
|
|
\inferrule*
|
|
{\typ{\Gamma}{V : \prompttype~A} \\ \typ{\Gamma}{M : A}}
|
|
{\typ{\Gamma}{\Prompt_V~M : A}}
|
|
\end{mathpar}
|
|
%
|
|
The dynamic semantics of this presentation require a bit of
|
|
generativity in order to generate fresh prompt names. Therefore the
|
|
reduction relation is extended with an additional component to keep
|
|
track of which prompt names have already been allocated.
|
|
%
|
|
\begin{reductions}
|
|
\slab{AppSplitter} & \splitter~V,\rho &\reducesto& \Prompt_p~V\,p,\rho \uplus \{p\}\\
|
|
\slab{Value} & \Prompt_p~V,\rho &\reducesto& V,\rho\\
|
|
\slab{Abort} & \Prompt_p~\EC[\abort~\Record{p;V}],\rho &\reducesto& V\,\Unit,\rho,\quad \text{where $\EC$ contains no $\Prompt_p$}\\
|
|
\slab{Capture} & \Prompt_p~\EC[\calldc~V] &\reducesto& V~\qq{\cont_{\EC}},\rho\\
|
|
\slab{Resume} & \Continue~\cont_{\EC}~V,\rho &\reducesto& \EC[V],\rho
|
|
\end{reductions}
|
|
%
|
|
We see by the $\slab{AppSplitter}$ rule that an application of
|
|
$\splitter$ generates a fresh named prompt, whose name is applied on
|
|
the function argument.
|
|
%
|
|
The $\slab{Value}$ rule is completely standard.
|
|
%
|
|
The $\slab{Abort}$ rule show that an invocation of $\abort$ causes the
|
|
current evaluation context $\EC$ up to and including the nearest
|
|
enclosing prompt.
|
|
%
|
|
The next rule $\slab{Capture}$ show that $\calldc$ captures and aborts
|
|
the context up to the nearest enclosing prompt. The captured context
|
|
is applied on the function argument of $\calldc$. As part of the
|
|
operation the prompt is removed. % Thus, $\calldc$ behaves as a
|
|
% delimited variation of $\Callcc$.
|
|
%
|
|
|
|
It is clear by the prompt semantics that invocation of either $\abort$
|
|
and $\calldc$ is only well-defined within the dynamic extent of
|
|
$\splitter$. Since the prompt is eliminated after use of either
|
|
operation subsequent operation invocations must be guarded by a new
|
|
instance of $\splitter$.
|
|
%
|
|
\dhil{Show an example}
|
|
% \begin{reductions}
|
|
% \slab{Value} & \splitter~abort~calldc.V &\reducesto& V\\
|
|
% \slab{Throw} & \splitter~abort~calldc.\EC[\,abort~V] &\reducesto& V~\Unit\\
|
|
% \slab{Capture} &
|
|
% \splitter~abort~calldc.\EC[calldc~V] &\reducesto& V~\qq{\cont_{\EC}} \\
|
|
% \slab{Resume} & \Continue~\cont_{\EC}~V &\reducesto& \EC[V]
|
|
% \end{reductions}
|
|
|
|
|
|
\paragraph{Spawn}
|
|
\dhil{TODO: Canonical reference \citet{HiebDA94}}
|
|
|
|
\paragraph{\citeauthor{Sitaram93}'s fcontrol} The control operator
|
|
`fcontrol' was introduced by \citet{Sitaram93} in 1993. It is a
|
|
refinement of control0/prompt0, and thus, it is a dynamic delimited
|
|
control operator. The main novelty of fcontrol is that it shifts the
|
|
handling of continuations from control capture operator to the control
|
|
delimiter. The prompt interface for fcontrol lets the programmer
|
|
attach a handler to it. This handler is activated whenever a
|
|
continuation captured.
|
|
%
|
|
\citeauthor{Sitaram93}'s observation was that with previous control
|
|
operators the handling of control happens at continuation capture
|
|
point, meaning that the control handling logic gets intertwined with
|
|
application logic. The inspiration for the interface of fcontrol and
|
|
its associated prompt came from exception handlers, where the handling
|
|
of exceptions is separate from the invocation site of
|
|
exceptions~\cite{Sitaram93}.
|
|
|
|
The operator fcontrol is a value and prompt with handler is a
|
|
computation.
|
|
%
|
|
\begin{syntax}
|
|
& V, W &::=& \cdots \mid \fcontrol\\
|
|
& M, N &::=& \cdots \mid \fprompt~V.M
|
|
\end{syntax}
|
|
%
|
|
As with $\Callcc$, the value $\fcontrol$ may be regarded as a special
|
|
unary function symbol. The syntax $\fprompt$ denotes a prompt (in
|
|
\citeauthor{Sitaram93}'s terminology it is called run). The value
|
|
constituent of $\fprompt$ is the control handler. It is a binary
|
|
function, that gets applied to the argument of $\fcontrol$ and the
|
|
continuation up to the prompt.
|
|
%
|
|
The dynamic semantics elucidate this behaviour formally.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Value} &
|
|
\fprompt~V.W &\reducesto& W\\
|
|
\slab{Capture} &
|
|
\fprompt~V.\EC[\fcontrol~W] &\reducesto& V~W~\qq{\cont_{\EC}}, \text{ where $\EC$ contains no \fprompt}\\
|
|
\slab{Resume} & \Continue~\cont_{\EC}~V &\reducesto& \EC[V]
|
|
\end{reductions}
|
|
%
|
|
The $\slab{Value}$ is similar to the previous $\slab{Value}$
|
|
rules. The interesting rule is the $\slab{Capture}$. When $\fcontrol$
|
|
is applied to some value $W$ the enclosing context $\EC$ gets reified
|
|
and aborted up to the nearest enclosing prompt, which invokes the
|
|
handler $V$ with the argument $W$ and the continuation.
|
|
%
|
|
\dhil{Show an example\dots}
|
|
|
|
\paragraph{Cupto} The control operator cupto is a variation of
|
|
control0/prompt0 designed to fit into the typed ML-family of
|
|
languages. It was introduced by \citet{GunterRR95} in 1995. The name
|
|
cupto is an abbreviation for ``control up to''~\cite{GunterRR95}.
|
|
%
|
|
The control operator comes with a set of companion constructs, and
|
|
thus, augments the syntactic categories of types, values, and
|
|
computations.
|
|
%
|
|
\begin{syntax}
|
|
& A,B &::=& \cdots \mid \prompttype~A \smallskip\\
|
|
& V,W &::=& \cdots \mid p \mid \newPrompt\\
|
|
& M,N &::=& \cdots \mid \Set\;V\;\In\;N \mid \Cupto~V~k.M
|
|
\end{syntax}
|
|
%
|
|
The type $\prompttype~A$ is the type of prompts. It is parameterised
|
|
by an answer type $A$ for the prompt context. Prompts are first-class
|
|
values, which we denote by $p$. The construct $\newPrompt$ is a
|
|
special function symbol, which returns a fresh prompt. The computation
|
|
form $\Set\;V\;\In\;N$ activates the prompt $V$ to delimit the dynamic
|
|
extent of continuations captured inside $N$. The $\Cupto~V~k.M$
|
|
computation binds $k$ to the continuation up to (the first instance
|
|
of) the active prompt $V$ in the computation $M$.
|
|
|
|
\citet{GunterRR95} gave a Hindley-Milner type
|
|
system~\cite{Hindley69,Milner78} for $\Cupto$, since they were working
|
|
in the context of ML languages. I do not reproduce the full system
|
|
here, only the essential rules for the $\Cupto$ constructs.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{~}
|
|
{\typ{\Gamma,p:\prompttype~A}{p : \prompttype~A}}
|
|
|
|
\inferrule*
|
|
{~}
|
|
{\typ{\Gamma}{\newPrompt} : \UnitType \to \prompttype~A}
|
|
|
|
\inferrule*
|
|
{\typ{\Gamma}{V : \prompttype~A} \\ \typ{\Gamma}{N : A}}
|
|
{\typ{\Gamma}{\Set\;V\;\In\;N : A}}
|
|
|
|
\inferrule*
|
|
{\typ{\Gamma}{V : \prompttype~B} \\ \typ{\Gamma,k : A \to B}{M : B}}
|
|
{\typ{\Gamma}{\Cupto\;V\;k.M : A}}
|
|
\end{mathpar}
|
|
%
|
|
%val cupto : 'b prompt -> (('a -> 'b) -> 'b) -> 'a
|
|
%
|
|
The typing rule for $\Set$ uses the type embedded in the prompt to fix
|
|
the type of the whole computation $N$. Similarly, the typing rule for
|
|
$\Cupto$ uses the prompt type of its value argument to fix the answer
|
|
type for the continuation $k$. The type of the $\Cupto$ expression is
|
|
the same as the domain of the continuation, which at first glance may
|
|
seem strange. The intuition is that $\Cupto$ behaves as a let binding
|
|
for the continuation in the context of a $\Set$ expression, i.e.
|
|
%
|
|
\[
|
|
\bl
|
|
\Set\;p^{\prompttype~B}\;\In\;\EC[\Cupto\;p\;k^{A \to B}.M^B]^B\\
|
|
\reducesto \Let\;k \revto \lambda x^{A}.\EC[x]^B \;\In\;M^B
|
|
\el
|
|
\]
|
|
%
|
|
|
|
The dynamic semantics is generative to accommodate generation of fresh
|
|
prompts. Formally, the reduction relation is augmented with a store
|
|
$\rho$ that tracks which prompt names have already been allocated.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Value} &
|
|
\Set\; p \;\In\; V, \rho &\reducesto& V, \rho\\
|
|
\slab{NewPrompt} &
|
|
\newPrompt~\Unit, \rho &\reducesto& p, \rho \uplus \{p\}\\
|
|
\slab{Capture} &
|
|
\Set\; p \;\In\; \EC[\Cupto~p~k.M], \rho &\reducesto& M[\qq{\cont_{\EC}}/k], \rho,\\
|
|
\multicolumn{4}{l}{\hfill\text{where $p$ is not active in $\EC$}}\\
|
|
\slab{Resume} & \Continue~\cont_{\EC}~V, \rho &\reducesto& \EC[V], \rho
|
|
\end{reductions}
|
|
%
|
|
The $\slab{Value}$ rule is akin to value rules of shift/reset and
|
|
control/prompt. The rule $\slab{NewPrompt}$ allocates a fresh prompt
|
|
name $p$ and adds it to the store $\rho$. The $\slab{Capture}$ rule
|
|
reifies and aborts the evaluation context up to the nearest enclosing
|
|
active prompt $p$. After reification the prompt is removed and
|
|
evaluation continues as $M$. The $\slab{Resume}$ rule reinstalls the
|
|
captured context $\EC$ with the argument $V$ plugged in.
|
|
%
|
|
\dhil{Show some example of use\dots}
|
|
|
|
\paragraph{\citeauthor{PlotkinP09}'s effect handlers} In 2009,
|
|
\citet{PlotkinP09} introduced handlers for \citeauthor{PlotkinP01}'s
|
|
algebraic effects~\cite{PlotkinP01,PlotkinP03,PlotkinP13}. In contrast
|
|
to the previous control operators, the mathematical foundations of
|
|
handlers were not an afterthought, rather, their origin is deeply
|
|
rooted in mathematics. Nevertheless, they turn out to provide a
|
|
pragmatic interface for programming with control. Operationally,
|
|
effect handlers can be viewed as a small extension to exception
|
|
handlers, where exceptions are resumable. Effect handlers are similar
|
|
to fcontrol in that handling of control happens at the delimiter and
|
|
not at the point of control capture. Unlike fcontrol, the interface of
|
|
effect handlers provide a mechanism for handling the return value of a
|
|
computation similar to \citeauthor{BentonK01}'s exception handlers
|
|
with success continuations~\cite{BentonK01}.
|
|
|
|
Effect handler definitions occupy their own syntactic category.
|
|
%
|
|
\begin{syntax}
|
|
&A,B \in \ValTypeCat &::=& \cdots \mid A \Harrow B \smallskip\\
|
|
&H \in \HandlerCat &::=& \{ \Return \; x \mapsto M \}
|
|
\mid \{ \OpCase{\ell}{p}{k} \mapsto N \} \uplus H\\
|
|
\end{syntax}
|
|
%
|
|
An effect handler consists of a $\Return$-clause and zero or more
|
|
operation clauses. Each operation clause binds the payload of the
|
|
matching operation $\ell$ to $p$ and the continuation of the operation
|
|
invocation to $k$ in $N$.
|
|
|
|
Effect handlers introduces a new syntactic category of signatures, and
|
|
extends the value types with operation types. Operation and handler
|
|
application both appear as computation forms.
|
|
%
|
|
\begin{syntax}
|
|
&\Sigma \in \mathsf{Sig} &::=& \emptyset \mid \{ \ell : A \opto B \} \uplus \Sigma\\
|
|
&A,B,C,D \in \ValTypeCat &::=& \cdots \mid A \opto B \smallskip\\
|
|
&M,N \in \CompCat &::=& \cdots \mid \Do\;\ell\,V \mid \Handle \; M \; \With \; H\\[1ex]
|
|
\end{syntax}
|
|
%
|
|
A signature is a collection of labels with operation types. An
|
|
operation type $A \opto B$ is similar to the function type in that $A$
|
|
denotes the domain (type of the argument) of the operation, and $B$
|
|
denotes the codomain (return type). For simplicity, we will just
|
|
assume a global fixed signature. The form $\Do\;\ell\,V$ is the
|
|
application form for operations. It applies an operation $\ell$ with
|
|
payload $V$. The construct $\Handle\;M\;\With\;H$ handles a
|
|
computation $M$ with handler $H$.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{{\bl
|
|
% C = A \eff \{(\ell_i : A_i \opto B_i)_i; R\} \\
|
|
% D = B \eff \{(\ell_i : P_i)_i; R\}\\
|
|
\{\ell_i : A_i \opto B_i\}_i \in \Sigma \\
|
|
H = \{\Return\;x \mapsto M\} \uplus \{ \OpCase{\ell_i}{p_i}{k_i} \mapsto N_i \}_i \\
|
|
\el}\\\\
|
|
\typ{\Gamma, x : A;\Sigma}{M : D}\\\\
|
|
[\typ{\Gamma,p_i : A_i, k_i : B_i \to D;\Sigma}{N_i : D}]_i
|
|
}
|
|
{\typ{\Gamma;\Sigma}{H : C \Harrow D}}
|
|
\end{mathpar}
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{\{ \ell : A \opto B \} \in \Sigma \\ \typ{\Gamma;\Sigma}{V : A}}
|
|
{\typ{\Gamma;\Sigma}{\Do\;\ell\,V : B}}
|
|
|
|
\inferrule*
|
|
{
|
|
\typ{\Gamma}{M : C} \\
|
|
\typ{\Gamma}{H : C \Harrow D}
|
|
}
|
|
{\typ{\Gamma;\Sigma}{\Handle \; M \; \With\; H : D}}
|
|
\end{mathpar}
|
|
%
|
|
The first typing rule checks that the operation label of each
|
|
operation clause is declared in the signature $\Sigma$. The signature
|
|
provides the necessary information to construct the type of the
|
|
payload parameters $p_i$ and the continuations $k_i$. Note that the
|
|
domain of each continuation $k_i$ is compatible with the codomain of
|
|
$\ell_i$, and the codomain of $k_i$ is compatible with the codomain of
|
|
the handler.
|
|
%
|
|
The second and third typing rules are application of operations and
|
|
handlers, respectively. The rule for operation application simply
|
|
inspects the signature to check that the operation is declared, and
|
|
that the type of the payload is compatible with the declared type.
|
|
|
|
This particular presentation is nominal, because operations are
|
|
declared up front. Nominal typing is the only sound option in the
|
|
absence of an effect system (unless we restrict operations to work
|
|
over a fixed type, say, an integer). In
|
|
Chapter~\ref{ch:unary-handlers} we see a different presentation based
|
|
on structural typing.
|
|
|
|
The dynamic semantics of effect handlers are similar to that of
|
|
$\fcontrol$, though, the $\slab{Value}$ rule is more interesting.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Value} & \Handle\; V \;\With\;H &\reducesto& M[V/x], \text{ where } \{\Return\;x \mapsto M\} \in H\\
|
|
\slab{Capture} & \Handle\;\EC[\Do\;\ell~V] \;\With\; H &\reducesto& M[V/p,\qq{\cont_{\Record{\EC;H}}}/k],\\
|
|
\multicolumn{4}{l}{\hfill\bl\text{where $\ell$ is not handled in $\EC$}\\\text{and }\{\OpCase{\ell}{p}{k} \mapsto M\} \in H\el}\\
|
|
\slab{Resume} & \Continue~\cont_{\Record{\EC;H}}~V &\reducesto& \Handle\;\EC[V]\;\With\;H\\
|
|
\end{reductions}
|
|
%
|
|
The \slab{Value} rule differs from previous operators as it is not
|
|
just the identity. Instead the $\Return$-clause of the handler
|
|
definition is applied to the return value of the computation.
|
|
%
|
|
The \slab{Capture} rule handles operation invocation by checking
|
|
whether the handler $H$ handles the operation $\ell$, otherwise the
|
|
operation implicitly passes through the term to the context outside
|
|
the handler. This behaviour is similar to how exceptions pass through
|
|
the context until a suitable handler has been found.
|
|
%
|
|
If $H$ handles $\ell$, then the context $\EC$ from the operation
|
|
invocation up to and including the handler $H$ are reified as a
|
|
continuation object, which gets bound in the corresponding clause for
|
|
$\ell$ in $H$ along with the payload of $\ell$.
|
|
%
|
|
This form of effect handlers is known as \emph{deep} handlers. They
|
|
are deep in the sense that they embody a structural recursion scheme
|
|
akin to fold over computation trees induced by effectful
|
|
operations. The recursion is evident from $\slab{Resume}$ rule, as
|
|
continuation invocation causes the same handler to be reinstalled
|
|
along with the captured context.
|
|
|
|
A classic example of handlers in action is handling of
|
|
nondeterminism. Let us fix a signature with two operations.
|
|
%
|
|
\[
|
|
\Sigma \defas \{\Fail : \UnitType \opto \ZeroType; \Choose : \UnitType \opto \Bool\}
|
|
\]
|
|
%
|
|
The $\Fail$ operation is essentially an exception as its codomain is
|
|
the empty type, meaning that its continuation can never be
|
|
invoked. The $\Choose$ operation returns a boolean.
|
|
|
|
We will define a handler for each operation.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
H^{A}_{f} : A \Harrow \Option~A\\
|
|
H_{f} \defas \{ \Return\; x \mapsto \Some~x; &\OpCase{\Fail}{\Unit}{k} \mapsto \None \}\\
|
|
H^B_{c} : B \Harrow \List~B\\
|
|
H_{c} \defas \{ \Return\; x \mapsto [x]; &\OpCase{\Choose}{\Unit}{k} \mapsto k~\True \concat k~\False \}
|
|
\ea
|
|
\]
|
|
%
|
|
The handler $H_f$ handles an invocation of $\Fail$ by dropping the
|
|
continuation and simply returning $\None$ (due to the lack
|
|
polymorphism, the definitions are parameterised by types $A$ and $B$
|
|
respectively. We may consider them as universal type variables). The
|
|
$\Return$-case of $H_f$ tags its argument with $\Some$.
|
|
%
|
|
The $H_c$ definition handles an invocation of $\Choose$ by first
|
|
invoking the continuation $k$ with $\True$ and subsequently with
|
|
$\False$. The two results are ultimately concatenated. The
|
|
$\Return$-case lifts its argument into a singleton list.
|
|
%
|
|
Now, let us define a simple nondeterministic coin tossing computation
|
|
with failure (by convention let us interpret $\True$ as heads and
|
|
$\False$ as tails).
|
|
%
|
|
\[
|
|
\bl
|
|
\toss : \UnitType \to \Bool\\
|
|
\toss~\Unit \defas
|
|
\ba[t]{@{~}l}
|
|
\If\;\Do\;\Choose~\Unit\\
|
|
\Then\;\Do\;\Choose~\Unit\\
|
|
\Else\;\Absurd\;\Do\;\Fail~\Unit
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The computation $\toss$ first performs $\Choose$ in order to
|
|
branch. If it returns $\True$ then a second instance of $\Choose$ is
|
|
performed. Otherwise, it raises the $\Fail$ exception.
|
|
%
|
|
If we apply $\toss$ outside of $H_c$ and $H_f$ then the computation
|
|
gets stuck as either $\Choose$ or $\Fail$, or both, would be
|
|
unhandled. Thus, we have to run the computation in the context of both
|
|
handlers. However, we have a choice to make as we can compose the
|
|
handlers in either order. Let us first explore the composition, where
|
|
$H_c$ is the outermost handler. Thus instantiate $H_c$ at type
|
|
$\Option~\Bool$ and $H_f$ at type $\Bool$.
|
|
%
|
|
\begin{derivation}
|
|
& \Handle\;(\Handle\;\toss~\Unit\;\With\; H_f)\;\With\;H_c\\
|
|
\reducesto & \reason{$\beta$-reduction, $\EC = \If\;[\,]\;\Then \cdots$}\\
|
|
& \Handle\;(\Handle\; \EC[\Do\;\Choose~\Unit] \;\With\; H_f)\;\With\;H_c\\
|
|
\reducesto & \reason{\slab{Capture}, $\{\OpCase{\Choose}{\Unit}{k} \mapsto \cdots\} \in H_c$, $\EC' = (\Handle\;\EC\;\cdots)$}\\
|
|
& k~\True \concat k~\False, \qquad \text{where $k = \qq{\cont_{\Record{\EC';H_c}}}$}\\
|
|
\reducesto^+ & \reason{\slab{Resume} with $\True$}\\
|
|
& (\Handle\;(\Handle\;\EC[\True] \;\With\;H_f)\;\With\;H_c) \concat k~\False\\
|
|
\reducesto & \reason{$\beta$-reduction}\\
|
|
& (\Handle\;(\Handle\; \Do\;\Choose~\Unit \;\With\; H_f)\;\With\;H_c) \concat k~\False\\
|
|
\reducesto & \reason{\slab{Capture}, $\{\OpCase{\Choose}{\Unit}{k'} \mapsto \cdots\} \in H_c$, $\EC'' = (\Handle\;[\,]\;\cdots)$}\\
|
|
& (k'~\True \concat k'~\False) \concat k~\False, \qquad \text{where $k' = \qq{\cont_{\Record{\EC'';H_c}}}$}\\
|
|
\reducesto& \reason{\slab{Resume} with $\True$}\\
|
|
&((\Handle\;(\Handle\; \True \;\With\; H_f)\;\With\;H_c) \concat k'~\False) \concat k~\False\\
|
|
\reducesto& \reason{\slab{Value}, $\{\Return\;x \mapsto \cdots\} \in H_f$}\\
|
|
&((\Handle\;\Some~\True\;\With\;H_c) \concat k'~\False) \concat k~\False\\
|
|
\reducesto& \reason{\slab{Value}, $\{\Return\;x \mapsto \cdots\} \in H_c$}\\
|
|
& ([\Some~\True] \concat k'~\False) \concat k~\False\\
|
|
\reducesto^+& \reason{\slab{Resume} with $\False$, \slab{Value}, \slab{Value}}\\
|
|
& [\Some~\True] \concat [\Some~\False] \concat k~\False\\
|
|
\reducesto^+& \reason{\slab{Resume} with $\False$}\\
|
|
& [\Some~\True, \Some~\False] \concat (\Handle\;(\Handle\; \Absurd\;\Do\;\Fail\,\Unit \;\With\; H_f)\;\With\;H_c)\\
|
|
\reducesto& \reason{\slab{Capture}, $\{\OpCase{\Fail}{\Unit}{k} \mapsto \cdots\} \in H_f$}\\
|
|
& [\Some~\True, \Some~\False] \concat (\Handle\; \None\; \With\; H_c)\\
|
|
\reducesto& \reason{\slab{Value}, $\{\Return\;x \mapsto \cdots\} \in H_c$}\\
|
|
& [\Some~\True, \Some~\False] \concat [\None] \reducesto [\Some~\True,\Some~\False,\None]
|
|
\end{derivation}
|
|
%
|
|
Note how the invocation of $\Choose$ passes through $H_f$, because
|
|
$H_f$ does not handle the operation. This is a key characteristic of
|
|
handlers, and it is called \emph{effect forwarding}. Any handler will
|
|
implicitly forward every operation that it does not handle.
|
|
|
|
Suppose we were to swap the order of $H_c$ and $H_f$, then the
|
|
computation would yield $\None$, because the invocation of $\Fail$
|
|
would transfer control to $H_f$, which is the now the outermost
|
|
handler, and it would drop the continuation and simply return $\None$.
|
|
|
|
The alternative to deep handlers is known as \emph{shallow}
|
|
handlers. They do not embody a particular recursion scheme, rather,
|
|
they correspond to case splits to over computation trees.
|
|
%
|
|
To distinguish between applications of deep and shallow handlers, we
|
|
will mark the latter with a dagger superscript, i.e.
|
|
$\ShallowHandle\; - \;\With\;-$. Syntactically deep and shallow
|
|
handler definitions are identical, however, their typing differ.
|
|
%
|
|
\begin{mathpar}
|
|
%\mprset{flushleft}
|
|
\inferrule*
|
|
{{\bl
|
|
% C = A \eff \{(\ell_i : A_i \opto B_i)_i; R\} \\
|
|
% D = B \eff \{(\ell_i : P_i)_i; R\}\\
|
|
\{\ell_i : A_i \opto B_i\}_i \in \Sigma \\
|
|
H = \{\Return\;x \mapsto M\} \uplus \{ \OpCase{\ell_i}{p_i}{k_i} \mapsto N_i \}_i \\
|
|
\el}\\\\
|
|
\typ{\Gamma, x : A;\Sigma}{M : D}\\\\
|
|
[\typ{\Gamma,p_i : A_i, k_i : B_i \to C;\Sigma}{N_i : D}]_i
|
|
}
|
|
{\typ{\Gamma;\Sigma}{H : C \Harrow D}}
|
|
\end{mathpar}
|
|
%
|
|
The difference is in the typing of the continuation $k_i$. The
|
|
codomains of continuations must now be compatible with the return type
|
|
$C$ of the handled computation. The typing suggests that an invocation
|
|
of $k_i$ does not reinstall the handler. The dynamic semantics reveal
|
|
that a shallow handler does not reify its own definition.
|
|
%
|
|
\begin{reductions}
|
|
\slab{Capture} & \ShallowHandle\;\EC[\Do\;\ell~V] \;\With\; H &\reducesto& M[V/p,\qq{\cont_{\EC}}/k],\\
|
|
\multicolumn{4}{l}{\hfill\bl\text{where $\ell$ is not handled in $\EC$}\\\text{and }\{\ell~p~k \mapsto M\} \in H\el}\\
|
|
\slab{Resume} & \Continue~\cont_{\EC}~V &\reducesto& \EC[V]\\
|
|
\end{reductions}
|
|
%
|
|
The $\slab{Capture}$ reifies the continuation up to the handler, and
|
|
thus the $\slab{Resume}$ rule can only reinstate the captured
|
|
continuation without the handler.
|
|
%
|
|
\dhil{Revisit the toss example with shallow handlers}
|
|
% \begin{reductions}
|
|
% \slab{Capture} & \Handle\;\EC[\Do\;\ell~V] \;\With\; H &\reducesto& M[V/p,\qq{\cont_{\EC}}/k],\\
|
|
% \multicolumn{4}{l}{\hfill\bl\text{where $\ell$ is not handled in $\EC$}\\\text{and }\{\ell~p~k \mapsto M\} \in H\el}\\
|
|
% \slab{Resume} & \Continue~\cont_{\EC}~V &\reducesto& \EC[V]\\
|
|
% \end{reductions}
|
|
%
|
|
|
|
Chapter~\ref{ch:unary-handlers} contains further examples of deep and
|
|
shallow handlers in action.
|
|
%
|
|
\dhil{Consider whether to present the below encodings\dots}
|
|
%
|
|
Deep handlers can be used to simulate shift0 and
|
|
reset0~\cite{KammarLO13}.
|
|
%
|
|
\begin{equations}
|
|
\sembr{\shiftz~k.M} &\defas& \Do\;\dec{Shift0}~(\lambda k.M)\\
|
|
\sembr{\resetz{M}} &\defas&
|
|
\ba[t]{@{~}l}\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;x &\mapsto& x\\
|
|
\OpCase{\dec{Shift0}}{f}{k} &\mapsto& f\,k
|
|
\ea
|
|
\ea
|
|
\end{equations}
|
|
%
|
|
|
|
Shallow handlers can be used to simulate control0 and
|
|
prompt0~\cite{KammarLO13}.
|
|
%
|
|
\begin{equations}
|
|
\sembr{\Controlz~k.M} &\defas& \Do\;\dec{Control0}~(\lambda k.M)\\
|
|
\sembr{\Promptz~M} &\defas&
|
|
\bl
|
|
prompt0\,(\lambda\Unit.M)\\
|
|
\textbf{where}\;
|
|
\bl
|
|
prompt0~m \defas
|
|
\ba[t]{@{~}l}\ShallowHandle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;x &\mapsto& x\\
|
|
\OpCase{\dec{Control0}}{f}{k} &\mapsto& prompt0\,(\lambda\Unit.f\,k)
|
|
\ea
|
|
\ea
|
|
\el
|
|
\el
|
|
\end{equations}
|
|
%
|
|
%Recursive types are required to type the image of this translation
|
|
|
|
\paragraph{\citeauthor{Longley09}'s catch-with-continue}
|
|
%
|
|
\dhil{TODO}
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{\typ{\Gamma, f : A \to B}{M : C \times D} \\ \Ground\;C}
|
|
{\typ{\Gamma}{\Catchcont\;f.M : C \times ((A \to B) \to D) + (A \times (B \to (A \to B) \to C \times D))}}
|
|
\end{mathpar}
|
|
%
|
|
\begin{reductions}
|
|
\slab{Value} &
|
|
\Catchcont \; f . \Record{V;W} &\reducesto& \Inl\; \Record{V;\lambda\,f. W}\\
|
|
\slab{Capture} &
|
|
\Catchcont \; f .\EC[\,f\,V] &\reducesto& \Inr\; \Record{V; \lambda x. \lambda f. \Continue~\cont_{\EC}~x}\\
|
|
\slab{Resume} & \Continue~\cont_{\EC}~V &\reducesto& \EC[V]
|
|
\end{reductions}
|
|
|
|
% \subsection{Second-class control operators}
|
|
% Coroutines, async/await, generators/iterators, amb.
|
|
|
|
% Backtracking: Amb~\cite{McCarthy63}.
|
|
|
|
% Coroutines~\cite{DahlDH72} as introduced by Simula
|
|
% 67~\cite{DahlMN68}. The notion of coroutines was coined by Melvin
|
|
% Conway, who used coroutines as a code idiom in assembly
|
|
% programs~\cite{Knuth97}. Canonical reference for implementing
|
|
% coroutines with call/cc~\cite{HaynesFW86}.
|
|
|
|
\section{Programming continuations}
|
|
\label{sec:programming-continuations}
|
|
%Blind vs non-blind backtracking. Engines. Web
|
|
% programming. Asynchronous
|
|
% programming. Coroutines.
|
|
|
|
Amongst the first uses of continuations were modelling of unrestricted
|
|
jumps, such as \citeauthor{Landin98}'s modelling of \Algol{} labels
|
|
and gotos using the J
|
|
operator~\cite{Landin65,Landin65a,Landin98,Reynolds93}.
|
|
|
|
Backtracking is another early and prominent use of continuations. For
|
|
example, \citet{Burstall69} used the J operator to implement a
|
|
heuristic-driven search procedure with continuation-backed
|
|
backtracking for tree-based search.
|
|
%
|
|
Somewhat related to backtracking, \citet{FriedmanHK84} posed the
|
|
\emph{devils and angels problem} as an example that has no direct
|
|
solution in a programming language without first-class control. Any
|
|
solution to the devils and angels problem involves extensive
|
|
manipulation of control to jump both backwards and forwards to resume
|
|
computation.
|
|
|
|
If the reader ever find themselves in a quiz show asked to single out
|
|
a canonical example of continuation use, then implementation of
|
|
concurrency would be a qualified guess. Cooperative concurrency in
|
|
terms of various forms of coroutines as continuations occur so
|
|
frequently in the literature and in the wild that they have become
|
|
routine.
|
|
%
|
|
\citet{HaynesFW86} published one of the first implementations of
|
|
coroutines using first-class control.
|
|
%
|
|
Preemptive concurrency in the form of engines were implemented by
|
|
\citet{DybvigH89}. An engine is a control abstraction that runs
|
|
computations with an allotted time budget~\cite{HaynesF84}. They used
|
|
continuations to represent strands of computation and timer interrupts
|
|
to suspend continuations.
|
|
%
|
|
\citet{KiselyovS07a} used delimited continuations to explain various
|
|
phenomena of operating systems, including multi-tasking.
|
|
%
|
|
On the web, \citet{Queinnec04} used continuations to model the
|
|
client-server interactions. This model was adapted by
|
|
\citet{CooperLWY06} in Links with support for an Erlang-style
|
|
concurrency model~\cite{ArmstrongVW93}.
|
|
%
|
|
\citet{Leijen17a} and \citet{DolanEHMSW17} gave two different ways of
|
|
implementing the asynchronous programming operator async/await as a
|
|
user-definable library.
|
|
|
|
Continuations have also been used in meta-programming to speed up
|
|
partial evaluation and
|
|
multi-staging~\cite{LawallD94,KameyamaKS11,OishiK17,Yallop17,WeiBTR20}. Let
|
|
insertion is a canonical example of use of continuations in
|
|
multi-staging~\cite{Yallop17}.
|
|
|
|
Probabilistic programming is yet another application domain of
|
|
continuations. \citet{KiselyovS09} used delimited continuations to
|
|
speed up probabilistic programs. \citet{GorinovaMH20} used
|
|
continuations to achieve modularise probabilistic programs and to
|
|
provide a simple and efficient mechanism for reparameterisation of
|
|
inference algorithms.
|
|
%
|
|
In the subject of differentiable programming \citet{WangZDWER19}
|
|
explained reverse-mode automatic differentiation operators in terms of
|
|
delimited continuations.
|
|
|
|
The aforementioned applications of continuations are by no means
|
|
exhaustive, though, the diverse application spectrum underlines the
|
|
versatility of continuations.
|
|
|
|
\section{Constraining continuations}
|
|
\label{sec:constraining-continuations}
|
|
|
|
\citet{FriedmanH85} advocated for constraining the power of
|
|
(undelimited) continuations~\cite{HaynesF87}.
|
|
%
|
|
Even though, they were concerned with callcc and undelimited
|
|
continuations some of their arguments are applicable to other control
|
|
operators and delimited continuations.
|
|
%
|
|
For example, they argued in favour of restricting continuations to be
|
|
one-shot, which means continuations may only be invoked once. Firstly,
|
|
because one-shot continuations admit particularly efficient
|
|
implementations. Secondly, many applications involve only single use
|
|
of continuations. Thirdly, one-shot continuations interact more
|
|
robustly with resources, such as file handles, than general multi-shot
|
|
continuations, because multiple use of a continuation may accidentally
|
|
interact with a resource after it has been released.
|
|
|
|
One-shot continuations by themselves are no saving grace for avoiding
|
|
resource leakage as they may be dropped or used to perform premature
|
|
exits from a block with resources. For example, Racket provides the
|
|
programmer with a facility known as \emph{dynamic-wind} to protect a
|
|
context with resources such that non-local exits properly release
|
|
whatever resources the context has acquired~\cite{Flatt20}.
|
|
%
|
|
An alternative approach is taken by Multicore OCaml, whose
|
|
implementation of effect handlers with one-shot continuations provides
|
|
both a \emph{continue} primitive for continuing a given continuation
|
|
and a \emph{discontinue} primitive for aborting a given
|
|
continuation~\cite{DolanWSYM15,DolanEHMSW17}. The latter throws an
|
|
exception at the operation invocation site to which can be caught by
|
|
local exception handlers to release resources properly.
|
|
%
|
|
This approach is also used by \citet{Fowler19}, who uses a
|
|
substructural type system to statically enforce the use of
|
|
continuations, either by means of a continue or a discontinue.
|
|
|
|
% For example callec is a variation of callcc where continuation
|
|
% invocation is only defined during the dynamic extent of
|
|
% callec~\cite{Flatt20}.
|
|
|
|
\section{Implementing continuations}
|
|
\label{sec:implementing-continuations}
|
|
|
|
There are numerous strategies for implementing continuations. There is
|
|
no best implementation strategy. Each strategy has different
|
|
trade-offs, and as such, there is no ``best'' strategy. In this
|
|
section, I will briefly outline the gist of some implementation
|
|
strategies and their trade-offs. For an in depth analysis the
|
|
interested reader may consult the respective work of
|
|
\citet{ClingerHO88} and \citet{FarvardinR20}, which contain thorough
|
|
studies of implementation strategies for first-class continuations.
|
|
%
|
|
Table~\ref{tbl:ctrl-operators-impls} lists some programming languages
|
|
with support for first-class control operators and their
|
|
implementation strategies.
|
|
|
|
\begin{table}
|
|
\centering
|
|
\begin{tabular}{| l | >{\raggedright}p{4.3cm} | l |}
|
|
\hline
|
|
\multicolumn{1}{|c|}{\textbf{Language}} & \multicolumn{1}{c |}{\textbf{Control operators}} & \multicolumn{1}{c|}{\textbf{Implementation strategies}}\\
|
|
\hline
|
|
Eff & Effect handlers & Virtual machine, interpreter \\
|
|
\hline
|
|
Effekt & Lexical effect handlers & ??\\
|
|
\hline
|
|
Frank & N-ary effect handlers & CEK machine \\
|
|
\hline
|
|
Gauche & callcc, shift/reset & Virtual machine \\
|
|
\hline
|
|
Helium & Effect handlers & CEK machine \\
|
|
\hline
|
|
Koka & Effect handlers & Continuation monad\\
|
|
\hline
|
|
Links & Effect handlers, escape & CEK machine, CPS\\
|
|
\hline
|
|
MLton & callcc & Stack copying\\
|
|
\hline
|
|
Multicore OCaml & Affine effect handlers & Segmented stacks\\
|
|
\hline
|
|
OchaCaml & shift/reset & Virtual machine\\
|
|
\hline
|
|
Racket & callcc, \textCallcomc{}, cupto, fcontrol, control/prompt, shift/reset, splitter, spawn & Segmented stacks\\
|
|
\hline
|
|
% Rhino JavaScript & JI & Interpreter \\
|
|
% \hline
|
|
Scala & shift/reset & CPS\\
|
|
\hline
|
|
SML/NJ & callcc & CPS\\
|
|
\hline
|
|
Wasm/k & control/prompt & Virtual machine \\
|
|
\hline
|
|
\end{tabular}
|
|
\caption{Some languages and their implementation strategies for continuations.}\label{tbl:ctrl-operators-impls}
|
|
\dhil{TODO: Figure out which implementation strategy Effekt uses}
|
|
\end{table}
|
|
%
|
|
The control stack provides a adequate runtime representation of
|
|
continuations as the contiguous sequence of activation records quite
|
|
literally represent what to do next.
|
|
%
|
|
Thus continuation capture can be implemented by making a copy of the
|
|
current stack (possibly up to some delimiter), and continuation
|
|
invocation as reinstatement of the stack. This implementation strategy
|
|
works well if continuations are captured infrequently. The MLton
|
|
implementation of Standard ML utilises this strategy~\cite{Fluet20}.
|
|
A slight variation is to defer the first copy action until the
|
|
continuation is invoked, which requires marking the stack to remember
|
|
which sequence of activation records to copy.
|
|
|
|
Obviously, frequent continuation use on top of a stack copying
|
|
implementation can be expensive time wise as well as space wise,
|
|
because with undelimited continuations multiple copies of the stack
|
|
may be alive simultaneously.
|
|
%
|
|
Typically the prefix of copies will be identical, which suggests they
|
|
ought to be shared. One way to achieve optimal sharing is to move from
|
|
a contiguous stack to a non-contiguous stack representation,
|
|
e.g. representing the stack as a heap allocated linked list of
|
|
activation records~\cite{Danvy87}. With such a representation copying
|
|
is a constant time and space operation, because there is no need to
|
|
actually copy anything as the continuation is just a pointer into the
|
|
stack.
|
|
%
|
|
The disadvantage of this strategy is that it turns every operation
|
|
into an indirection.
|
|
|
|
Segmented stacks provide a middle ground between contiguous stack and
|
|
non-contiguous stack representations. With this representation the
|
|
control stack is represented as a linked list of contiguous stacks
|
|
which makes it possible to only copy a segment of the stack. The
|
|
stacks grown and shrink dynamically as needed. This representation is
|
|
due to \citet{HiebDB90}. It is used by Chez Scheme, which is the
|
|
runtime that powers Racket~\cite{FlattD20}.
|
|
%
|
|
For undelimited continuations the basic idea is to create a pointer to
|
|
the current stack upon continuation capture, and then allocate a new
|
|
stack where subsequent computation happens.
|
|
%
|
|
For delimited continuations the control delimiter identify when a new
|
|
stack should be allocated.
|
|
%
|
|
A potential problem with this representation is \emph{stack
|
|
thrashing}, which is a phenomenon that occurs when a stack is being
|
|
continuously resized.
|
|
%
|
|
This problem was addressed by \citet{BruggemanWD96}, who designed a
|
|
slight variation of segmented stacks optimised for one-shot
|
|
continuations, which has been adapted by Multicore
|
|
OCaml~\cite{DolanEHMSW17}.
|
|
|
|
Full stack copying and segmented stacks both depend on being able to
|
|
manipulate the stack directly. This is seldom possible if the language
|
|
implementer do not have control over the target runtime,
|
|
e.g. compilation to JavaScript. However, it is possible to emulate
|
|
stack copying and segmented stacks in lieu of direct stack access. For
|
|
example, \citet{PettyjohnCMKF05} describe a technique that emulates
|
|
stack copying by piggybacking on the facile stack inception facility
|
|
provided by exception handlers in order to lazily reify the control
|
|
stack.
|
|
%
|
|
\citet{KumarBD98} emulated segmented stacks via threads. Each thread
|
|
has its own local stack, and as such, a collection of threads
|
|
effectively models segmented stacks. To actually implement
|
|
continuations as threads \citeauthor{KumarBD98} also made use of
|
|
standard synchronisation primitives.
|
|
%
|
|
The advantage of these techniques is that they are generally
|
|
applicable and portable. The disadvantage is the performance overhead
|
|
induced by emulation.
|
|
|
|
Abstract and virtual machines are a form of full machine emulation. An
|
|
abstract machine is an idealised machine. Abstract machines, such as
|
|
the CEK machine~\cite{FelleisenF86}, are attractive because they
|
|
provide a suitably high-level framework for defining language
|
|
semantics in terms of control string manipulations, whilst admitting a
|
|
direct implementation.
|
|
%
|
|
We will discuss abstract machines in more detail in
|
|
Chapter~\ref{ch:abstract-machine}.
|
|
%
|
|
The term virtual machine typically connotes an abstract machine that
|
|
works on a byte code representation of programs, whereas the default
|
|
connotation of abstract machine is a machine that works on a rich
|
|
abstract syntax tree representation of programs.
|
|
% \citeauthor{Landin64}'s SECD machine was the
|
|
% first abstract machine for evaluating $\lambda$-calculus
|
|
% terms~\cite{Landin64,Danvy04}.
|
|
%
|
|
% Either machine model has an explicit representation of the control
|
|
% state in terms of an environment and a control string. Thus either machine can to the
|
|
% interpretative overhead.
|
|
The disadvantage of abstract machines is their interpretative
|
|
overhead, although, techniques such as just-in-time compilation can be
|
|
utilised to reduce this overhead.
|
|
|
|
Continuation passing style (CPS) is a canonical implementation
|
|
strategy for continuations --- the word `continuation' even feature in
|
|
its name.
|
|
%
|
|
CPS is a particular idiomatic notation for programs, where every
|
|
function takes an additional argument, the current continuation, as
|
|
input and every function call appears in tail position. Consequently,
|
|
every aspect of control flow is made explicit, which makes CPS a good
|
|
fit for implementing control abstraction. In classic CPS the
|
|
continuation argument is typically represented as a heap allocated
|
|
closure~\cite{Appel92}, however, as we shall see in
|
|
Chapter~\ref{ch:cps} richer representations of continuations are
|
|
possible.
|
|
%
|
|
At first thought it may seem that CPS will not work well in
|
|
environments that lack proper tail calls such as JavaScript. However,
|
|
the contrary is true, because the stackless nature of CPS means it can
|
|
readily be implemented with a trampoline~\cite{GanzFW99}. Alas, at the
|
|
cost of the indirection induced by the trampoline.
|
|
|
|
\part{Design}
|
|
|
|
\chapter{An ML-flavoured programming language based on rows}
|
|
\label{ch:base-language}
|
|
|
|
In this chapter we introduce a core calculus, \BCalc{}, which we shall
|
|
later use as the basis for exploration of design considerations for
|
|
effect handlers. This calculus is based on \CoreLinks{} by
|
|
\citet{LindleyC12}, which distils the essence of the functional
|
|
multi-tier web-programming language
|
|
\Links{}~\cite{CooperLWY06}. \Links{} belongs to the
|
|
ML-family~\cite{MilnerTHM97} of programming languages as it features
|
|
typical characteristics of ML languages such as a static type system
|
|
supporting parametric polymorphism with type inference (in fact Links
|
|
supports first-class polymorphism), and its evaluation semantics is
|
|
strict. However, \Links{} differentiates itself from the rest of the
|
|
ML-family by making crucial use of \emph{row polymorphism} to support
|
|
extensible records, variants, and tracking of computational
|
|
effects. Thus \Links{} has a rather strong emphasis on structural
|
|
types rather than nominal types.
|
|
|
|
\CoreLinks{} captures all of these properties of \Links{}. Our
|
|
calculus \BCalc{} differs in several aspects from \CoreLinks{}. For
|
|
example, the underlying formalism of \CoreLinks{} is call-by-value,
|
|
whilst the formalism of \BCalc{} is \emph{fine-grain
|
|
call-by-value}~\cite{LevyPT03}, which shares similarities with
|
|
A-normal form (ANF)~\cite{FlanaganSDF93} as it syntactically
|
|
distinguishes between value and computation terms by mandating every
|
|
intermediate computation being named. However unlike ANF, fine-grain
|
|
call-by-value remains closed under $\beta$-reduction. The reason for
|
|
choosing fine-grain call-by-value as our formalism is entirely due to
|
|
convenience. As we shall see in Chapter~\ref{ch:unary-handlers}
|
|
fine-grain call-by-value is a convenient formalism for working with
|
|
continuations. Another point of difference between \CoreLinks{} and
|
|
\BCalc{} is that the former models the integrated database query
|
|
sublanguage of \Links{}. We do not consider the query sublanguage at
|
|
all, and instead our focus is entirely on modelling the interaction
|
|
and programming with computational effects.
|
|
|
|
\section{Syntax and static semantics}
|
|
\label{sec:syntax-base-language}
|
|
|
|
As \BCalc{} is intrinsically typed, we begin by presenting the syntax
|
|
of kinds and types in
|
|
Section~\ref{sec:base-language-types}. Subsequently in
|
|
Section~\ref{sec:base-language-terms} we present the term syntax,
|
|
before presenting the formation rules for types in
|
|
Section~\ref{sec:base-language-type-rules}.
|
|
|
|
% Typically the presentation of a programming language begins with its
|
|
% syntax. If the language is typed there are two possible starting
|
|
% points: Either one presents the term syntax first, or alternatively,
|
|
% the type syntax first. Although the choice may seem rather benign
|
|
% there is, however, a philosophical distinction to be drawn between
|
|
% them. Terms are, on their own, entirely meaningless, whilst types
|
|
% provide, on their own, an initial approximation of the semantics of
|
|
% terms. This is particularly true in an intrinsic typed system perhaps
|
|
% less so in an extrinsic typed system. In an intrinsic system types
|
|
% must necessarily be precursory to terms, as terms ultimately depend on
|
|
% the types. Following this argument leaves us with no choice but to
|
|
% first present the type syntax of \BCalc{} and subsequently its term
|
|
% syntax.
|
|
|
|
\subsection{Types and their kinds}
|
|
\label{sec:base-language-types}
|
|
%
|
|
\begin{figure}
|
|
\begin{syntax}
|
|
% \slab{Value types} &A,B &::= & A \to C
|
|
% \mid \alpha
|
|
% \mid \forall \alpha^K.C
|
|
% \mid \Record{R}
|
|
% \mid [R]\\
|
|
% \slab{Computation types}
|
|
% &C,D &::= & A \eff E \\
|
|
% \slab{Effect types} &E &::= & \{R\}\\
|
|
% \slab{Row types} &R &::= & \ell : P;R \mid \rho \mid \cdot \\
|
|
% \slab{Presence types} &P &::= & \Pre{A} \mid \Abs \mid \theta\\
|
|
% %\slab{Labels} &\ell & & \\
|
|
% % \slab{Types} &T &::= & A \mid C \mid E \mid R \mid P \\
|
|
% \slab{Kinds} &K &::= & \Type \mid \Row_\mathcal{L} \mid \Presence
|
|
% \mid \Comp \mid \Effect \\
|
|
% \slab{Label sets} &\mathcal{L} &::=& \emptyset \mid \{\ell\} \uplus \mathcal{L}\\
|
|
% %\slab{Type variables} &\alpha, \rho, \theta& \\
|
|
% \slab{Type environments} &\Gamma &::=& \cdot \mid \Gamma, x:A \\
|
|
% \slab{Kind environments} &\Delta &::=& \cdot \mid \Delta, \alpha:K
|
|
\slab{Value types} &A,B \in \ValTypeCat &::= & A \to C
|
|
\mid \forall \alpha^K.C
|
|
\mid \Record{R} \mid [R]
|
|
\mid \alpha \\
|
|
\slab{Computation types\!\!}
|
|
&C,D \in \CompTypeCat &::= & A \eff E \\
|
|
\slab{Effect types} &E \in \EffectCat &::= & \{R\}\\
|
|
\slab{Row types} &R \in \RowCat &::= & \ell : P;R \mid \rho \mid \cdot \\
|
|
\slab{Presence types\!\!\!\!\!} &P \in \PresenceCat &::= & \Pre{A} \mid \Abs \mid \theta\\
|
|
\\
|
|
\slab{Types} &T \in \TypeCat &::= & A \mid C \mid E \mid R \mid P \\
|
|
\slab{Kinds} &K \in \KindCat &::= & \Type \mid \Comp \mid \Effect \mid \Row_\mathcal{L} \mid \Presence \\
|
|
\slab{Label sets} &\mathcal{L} \in \LabelCat &::=& \emptyset \mid \{\ell\} \uplus \mathcal{L}\\\\
|
|
|
|
\slab{Type environments} &\Gamma \in \TyEnvCat &::=& \cdot \mid \Gamma, x:A \\
|
|
\slab{Kind environments} &\Delta \in \KindEnvCat &::=& \cdot \mid \Delta, \alpha:K \\
|
|
\end{syntax}
|
|
\caption{Syntax of types, kinds, and their environments.}
|
|
\label{fig:base-language-types}
|
|
\end{figure}
|
|
%
|
|
The types are divided into several distinct syntactic categories which
|
|
are given in Figure~\ref{fig:base-language-types} along with the
|
|
syntax of kinds and environments.
|
|
%
|
|
\paragraph{Value types}
|
|
We distinguish between values and computations at the level of
|
|
types. Value types comprise the function type $A \to C$, which maps
|
|
values of type $A$ to computations of type $C$; the polymorphic type
|
|
$\forall \alpha^K . C$ is parameterised by a type variable $\alpha$ of
|
|
kind $K$; and the record type $\Record{R}$ represents records with
|
|
fields constrained by row $R$. Dually, the variant type $[R]$
|
|
represents tagged sums constrained by row $R$.
|
|
|
|
\paragraph{Computation types and effect types}
|
|
The computation type $A \eff E$ is given by a value type $A$ and an
|
|
effect type $E$, which specifies the effectful operations a
|
|
computation inhabiting this type may perform. An effect type
|
|
$E = \{R\}$ is constrained by row $R$.
|
|
|
|
\paragraph{Row types}
|
|
Row types play a pivotal role in our type system as effect, record,
|
|
and variant types are uniformly given by row types. A \emph{row type}
|
|
describes a collection of distinct labels, each annotated by a
|
|
presence type. A presence type indicates whether a label is
|
|
\emph{present} with type $A$ ($\Pre{A}$), \emph{absent} ($\Abs$) or
|
|
\emph{polymorphic} in its presence ($\theta$).
|
|
%
|
|
For example, the effect row $\{\Read:\Pre{\Int},\Write:\Abs,\cdot\}$
|
|
denotes a read-only context in which the operation label $\Read$ may
|
|
occur to access some integer value, whilst the operation label
|
|
$\Write$ cannot appear.
|
|
%
|
|
|
|
Row types are either \emph{closed} or \emph{open}. A closed row type
|
|
ends in~$\cdot$, whilst an open row type ends with a \emph{row
|
|
variable} $\rho$ (in an effect row we usually use $\varepsilon$
|
|
rather than $\rho$ and refer to it as an \emph{effect variable}).
|
|
%
|
|
The example effect row above is closed, an open variation of it ends
|
|
in an effect variable $\varepsilon$,
|
|
i.e. $\{\Read:\Pre{\Int},\Write:\Abs,\varepsilon\}$.
|
|
%
|
|
The row variable in an open row type can be instantiated with
|
|
additional labels subject to the restriction that each label may only
|
|
occur at most once (we enforce this restriction at the level of
|
|
kinds). We identify rows up to the reordering of labels as follows.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*[Lab=\rowlab{Closed}]
|
|
{~}
|
|
{\cdot \equiv_{\mathrm{row}} \cdot}
|
|
|
|
\inferrule*[Lab=\rowlab{Open}]
|
|
{~}
|
|
{\rho \equiv_{\mathrm{row}} \rho'}
|
|
|
|
\inferrule*[Lab=\rowlab{Head}]
|
|
{R \equiv_{\mathrm{row}} R'}
|
|
{\ell:P;R \equiv_{\mathrm{row}} \ell:P;R'}
|
|
|
|
\inferrule*[Lab=\rowlab{Swap}]
|
|
{R \equiv_{\mathrm{row}} R'}
|
|
{\ell:P;\ell':P';R \equiv_{\mathrm{row}} \ell':P';\ell:P;R'}
|
|
\end{mathpar}
|
|
%
|
|
% The last rule $\rowlab{Swap}$ let us identify rows up to the
|
|
% reordering of labels. For instance, the two rows
|
|
% $\ell_1 : P_1; \cdots; \ell_n : P_n; \cdot$ and
|
|
% $\ell_n : P_n; \cdots ; \ell_1 : P_1; \cdot$ are equivalent.
|
|
%
|
|
The \rowlab{Closed} rule states that the closed marker $\cdot$ is
|
|
equivalent to itself, similarly the \rowlab{Open} rule states that any
|
|
two row variables are equivalent if and only if they have the same
|
|
syntactic name. The \rowlab{Head} rule compares the head of two given
|
|
rows and inductively compares their tails. The \rowlab{Swap} rule
|
|
permits reordering of labels. We assume structural equality on
|
|
labels. The \rowlab{Head} rule
|
|
%
|
|
|
|
The standard zero and unit types are definable using rows. We define
|
|
the zero type as the empty, closed variant $\ZeroType \defas
|
|
[\cdot]$. Dually, the unit type is defined as the empty, closed record
|
|
type, i.e. $\UnitType \defas \Record{\cdot}$.
|
|
|
|
% As absent labels in closed rows are redundant we will, for example,
|
|
% consider the following two rows equivalent
|
|
% $\Read:\Pre{\Int},\Write:\Abs,\cdot \equiv_{\mathrm{row}}
|
|
% \Read:\Pre{\Int},\cdot$.
|
|
For brevity, we shall often write $\ell : A$
|
|
to mean $\ell : \Pre{A}$ and omit $\cdot$ for closed rows.
|
|
|
|
%
|
|
\begin{figure}
|
|
\begin{mathpar}
|
|
% alpha : K
|
|
\inferrule*[Lab=\klab{TyVar}]
|
|
{ }
|
|
{\Delta, \alpha : K \vdash \alpha : K}
|
|
|
|
% Computation
|
|
\inferrule*[Lab=\klab{Comp}]
|
|
{ \Delta \vdash A : \Type \\
|
|
\Delta \vdash E : \Effect \\
|
|
}
|
|
{\Delta \vdash A \eff E : \Comp}
|
|
|
|
% A -E-> B, A : Type, E : Row, B : Type
|
|
\inferrule*[Lab=\klab{Fun}]
|
|
{ \Delta \vdash A : \Type \\
|
|
\Delta \vdash C : \Comp \\
|
|
}
|
|
{\Delta \vdash A \to C : \Type}
|
|
|
|
% forall alpha : K . A : Type
|
|
\inferrule*[Lab=\klab{Forall}]
|
|
{ \Delta, \alpha : K \vdash C : \Comp}
|
|
{\Delta \vdash \forall \alpha^K . \, C : \Type}
|
|
|
|
% Record
|
|
\inferrule*[Lab=\klab{Record}]
|
|
{ \Delta \vdash R : \Row_\emptyset}
|
|
{\Delta \vdash \Record{R} : \Type}
|
|
|
|
% Variant
|
|
\inferrule*[Lab=\klab{Variant}]
|
|
{ \Delta \vdash R : \Row_\emptyset}
|
|
{\Delta \vdash [R] : \Type}
|
|
|
|
% Effect
|
|
\inferrule*[Lab=\klab{Effect}]
|
|
{ \Delta \vdash R : \Row_\emptyset}
|
|
{\Delta \vdash \{R\} : \Effect}
|
|
|
|
% Present
|
|
\inferrule*[Lab=\klab{Present}]
|
|
{\Delta \vdash A : \Type}
|
|
{\Delta \vdash \Pre{A} : \Presence}
|
|
|
|
% Absent
|
|
\inferrule*[Lab=\klab{Absent}]
|
|
{ }
|
|
{\Delta \vdash \Abs : \Presence}
|
|
|
|
% Empty row
|
|
\inferrule*[Lab=\klab{EmptyRow}]
|
|
{ }
|
|
{\Delta \vdash \cdot : \Row_\mathcal{L}}
|
|
|
|
% Extend row
|
|
\inferrule*[Lab=\klab{ExtendRow}]
|
|
{ \Delta \vdash P : \Presence \\
|
|
\Delta \vdash R : \Row_{\mathcal{L} \uplus \{\ell\}}
|
|
}
|
|
{\Delta \vdash \ell : P;R : \Row_\mathcal{L}}
|
|
\end{mathpar}
|
|
\caption{Kinding rules}
|
|
\label{fig:base-language-kinding}
|
|
\end{figure}
|
|
%
|
|
|
|
\paragraph{Kinds}
|
|
The kinds classify the different categories of types. The $\Type$ kind
|
|
classifies value types, $\Presence$ classifies presence annotations,
|
|
$\Comp$ classifies computation types, $\Effect$ classifies effect
|
|
types, and lastly $\Row_{\mathcal{L}}$ classifies rows.
|
|
%
|
|
The formation rules for kinds are given in
|
|
Figure~\ref{fig:base-language-kinding}. The kinding judgement
|
|
$\Delta \vdash T : K$ states that type $T$ has kind $K$ in kind
|
|
environment $\Delta$.
|
|
%
|
|
The row kind is annotated by a set of labels $\mathcal{L}$. We use
|
|
this set to track the labels of a given row type to ensure uniqueness
|
|
amongst labels in each row type. For example, the kinding rule
|
|
$\klab{ExtendRow}$ uses this set to constrain which labels may be
|
|
mentioned in the tail of $R$. We shall elaborate on this in
|
|
Section~\ref{sec:row-polymorphism}.
|
|
|
|
\paragraph{Environments}
|
|
Kind and type environments are right-extended sequences of bindings. A
|
|
kind environment binds type variables to their kinds, whilst a type
|
|
environment binds term variables to their types.
|
|
|
|
\paragraph{Type variables} The type structure has three syntactically
|
|
distinct type variables (the kinding system gives us five semantically
|
|
distinct notions of type variables). As we sometimes wish to refer
|
|
collectively to type variables, we define the set of type variables,
|
|
$\TyVarCat$, to be generated by:
|
|
%
|
|
\[
|
|
\TyVarCat \defas
|
|
\ba[t]{@{~}l@{~}l}
|
|
&\{ A \in \ValTypeCat \mid A \text{ has the form } \alpha \}\\
|
|
\cup &\{ R \in \RowCat \mid R \text{ has the form } \rho \}\\
|
|
\cup &\{ P \in \PresenceCat \mid P \text{ has the form } \theta \}
|
|
\ea
|
|
\]
|
|
|
|
% Value types comprise the function type $A \to C$, whose domain
|
|
% is a value type and its codomain is a computation type $B \eff E$,
|
|
% where $E$ is an effect type detailing which effects the implementing
|
|
% function may perform. Value types further comprise type variables
|
|
% $\alpha$ and quantification $\forall \alpha^K.C$, where the quantified
|
|
% type variable $\alpha$ is annotated with its kind $K$. Finally, the
|
|
% value types also contains record types $\Record{R}$ and variant types
|
|
% $[R]$, which are built up using row types $R$. An effect type $E$ is
|
|
% also built up using a row type. A row type is a sequence of fields of
|
|
% labels $\ell$ annotated with their presence information $P$. The
|
|
% presence information denotes whether a label is present $\Pre{A}$ with
|
|
% some type $A$, absent $\Abs$, or polymorphic in its presence
|
|
% $\theta$. A row type may be either \emph{open} or \emph{closed}. An
|
|
% open row ends in a row variable $\rho$ which can be instantiated with
|
|
% additional fields, effectively growing the row, whilst a closed row
|
|
% ends in $\cdot$, meaning the row cannot grow further.
|
|
|
|
% The kinds comprise $\Type$ for regular type variables, $\Presence$ for
|
|
% presence variables, $\Comp$ for computation type variables, $\Effect$
|
|
% for effect variables, and lastly $\Row_{\mathcal{L}}$ for row
|
|
% variables. The row kind is annotated by a set of labels
|
|
% $\mathcal{L}$. We use this set to track the labels of a given row type
|
|
% to ensure uniqueness amongst labels in each row type. We shall
|
|
% elaborate on this in Section~\ref{sec:row-polymorphism}.
|
|
|
|
\paragraph{Free type variables} Sometimes we need to compute the free
|
|
type variables ($\FTV$) of a given type. To this end we define a
|
|
metafunction $\FTV$ by induction on the type structure, $T$, and
|
|
point-wise on type environments, $\Gamma$. Note that we always work up
|
|
to $\alpha$-conversion~\cite{Church32} of types.
|
|
%
|
|
\[
|
|
\ba[t]{@{~}l@{~~~~~~}c@{~}l}
|
|
\multicolumn{3}{c}{\begin{eqs}
|
|
\FTV &:& \TypeCat \to \TyVarCat
|
|
\end{eqs}}\\
|
|
\ba[t]{@{}l}
|
|
\begin{eqs}
|
|
% \FTV &:& \ValTypeCat \to \TyVarCat\\
|
|
\FTV(\alpha) &\defas& \{\alpha\}\\
|
|
\FTV(\forall \alpha^K.C) &\defas& \FTV(C) \setminus \{\alpha\}\\
|
|
\FTV(A \to C) &\defas& \FTV(A) \cup \FTV(C)\\
|
|
\FTV(A \eff E) &\defas& \FTV(A) \cup \FTV(E)\\
|
|
\FTV(\{R\}) &\defas& \FTV(R)\\
|
|
\FTV(\Record{R}) &\defas& \FTV(R)\\
|
|
\FTV([R]) &\defas& \FTV(R)\\
|
|
% \FTV(l:P;R) &\defas& \FTV(P) \cup \FTV(R)\\
|
|
% \FTV(\Pre{A}) &\defas& \FTV(A)\\
|
|
% \FTV(\Abs) &\defas& \emptyset\\
|
|
% \FTV(\theta) &\defas& \{\theta\}
|
|
\end{eqs}\ea & &
|
|
\begin{eqs}
|
|
% \FTV([R]) &\defas& \FTV(R)\\
|
|
% \FTV(\Record{R}) &\defas& \FTV(R)\\
|
|
% \FTV(\{R\}) &\defas& \FTV(R)\\
|
|
% \FTV &:& \RowCat \to \TyVarCat\\
|
|
\FTV(\cdot) &\defas& \emptyset\\
|
|
\FTV(\rho) &\defas& \{\rho\}\\
|
|
\FTV(l:P;R) &\defas& \FTV(P) \cup \FTV(R)\\
|
|
|
|
% \FTV &:& \PresenceCat \to \TyVarCat\\
|
|
\FTV(\theta) &\defas& \{\theta\}\\
|
|
\FTV(\Abs) &\defas& \emptyset\\
|
|
\FTV(\Pre{A}) &\defas& \FTV(A)\\
|
|
\end{eqs}\\\\
|
|
\multicolumn{3}{c}{\begin{eqs}
|
|
\FTV &:& \TyEnvCat \to \TyVarCat\\
|
|
\FTV(\cdot) &\defas& \emptyset\\
|
|
\FTV(\Gamma,x : A) &\defas& \FTV(\Gamma) \cup \FTV(A)
|
|
\end{eqs}}
|
|
% \begin{eqs}
|
|
% \FTV(\theta) &\defas& \{\theta\}\\
|
|
% \FTV(\Abs) &\defas& \emptyset\\
|
|
% \FTV(\Pre{A}) &\defas& \FTV(A)
|
|
% \end{eqs} & &
|
|
% \begin{eqs}
|
|
% \FTV(\cdot) &\defas& \emptyset\\
|
|
% \FTV(\Gamma,x : A) &\defas& \FTV(\Gamma) \cup \FTV(A)
|
|
% \end{eqs}
|
|
\ea
|
|
\]
|
|
%
|
|
|
|
\paragraph{Type substitution}
|
|
We define a type substitution map,
|
|
$\sigma : (\TyVarCat \times \TypeCat)^\ast$ as list of pairs mapping a
|
|
type variable to its replacement. We denote a single mapping as
|
|
$T/\alpha$ meaning substitute $T$ for the variable $\alpha$. We write
|
|
multiple mappings using list notation,
|
|
i.e. $[T_0/\alpha_0,\dots,T_n/\alpha_n]$. The domain of a substitution
|
|
map is set generated by projecting the first component, i.e.
|
|
%
|
|
\[
|
|
\bl
|
|
\dom : (\TyVarCat \times \TypeCat)^\ast \to \TyVarCat\\
|
|
\dom(\sigma) \defas \{ \alpha \mid (\_/\alpha) \in \sigma \}
|
|
\el
|
|
\]
|
|
%
|
|
The application of a type substitution map on a type term, written
|
|
$T\sigma$ for some type $T$, is defined inductively on the type
|
|
structure as follows.
|
|
%
|
|
\[
|
|
\ba[t]{@{~}l@{~}c@{~}r}
|
|
\multicolumn{3}{c}{
|
|
\begin{eqs}
|
|
(A \eff E)\sigma &\defas& A\sigma \eff E\sigma\\
|
|
(A \to C)\sigma &\defas& A\sigma \to C\sigma\\
|
|
(\forall \alpha^K.C)\sigma &\simdefas& \forall \alpha^K.C\sigma\\
|
|
\alpha\sigma &\defas& \begin{cases}
|
|
A & \text{if } (\alpha,A) \in \sigma\\
|
|
\alpha & \text{otherwise}
|
|
\end{cases}
|
|
\end{eqs}}\\
|
|
\begin{eqs}
|
|
\Record{R}\sigma &\defas& \Record{R[B/\beta]}\\
|
|
{[R]}\sigma &\defas& [R\sigma]\\
|
|
\{R\}\sigma &\defas& \{R\sigma\}\\
|
|
\cdot\sigma &\defas& \cdot\\
|
|
\rho\sigma &\defas& \begin{cases}
|
|
R & \text{if } (\rho, R) \in \sigma\\
|
|
\rho & \text{otherwise}
|
|
\end{cases}\\
|
|
\end{eqs}
|
|
& ~~~~~~~~~~ &
|
|
\begin{eqs}
|
|
(\ell : P;R)\sigma &\defas& (\ell : P\sigma; R\sigma)\\
|
|
\theta\sigma &\defas& \begin{cases}
|
|
P & \text{if } (\theta,P) \in \sigma\\
|
|
\theta & \text{otherwise}
|
|
\end{cases}\\
|
|
\Abs\sigma &\defas& \Abs\\
|
|
\Pre{A}\sigma &\defas& \Pre{A\sigma}
|
|
\end{eqs}
|
|
\ea
|
|
\]
|
|
%
|
|
|
|
\paragraph{Types and their inhabitants}
|
|
We now have the basic vocabulary to construct types in $\BCalc$. For
|
|
instance, the signature of the standard polymorphic identity function
|
|
is
|
|
%
|
|
\[
|
|
\forall \alpha^\Type. \alpha \to \alpha \eff \emptyset.
|
|
\]
|
|
%
|
|
Modulo the empty effect signature, this type is akin to the type one
|
|
would give for the identity function in System
|
|
F~\cite{Girard72,Reynolds74}, and thus we can use standard techniques
|
|
from parametricity~\cite{Wadler89} to reason about inhabitants of this
|
|
signature. However, in our system we can give an even more general
|
|
type to the identity function:
|
|
%
|
|
\[
|
|
\forall \alpha^\Type,\varepsilon^{\Row_\emptyset}. \alpha \to \alpha \eff \{\varepsilon\}.
|
|
\]
|
|
%
|
|
This type is polymorphic in its effect signature as signified by the
|
|
singleton open effect row $\{\varepsilon\}$, meaning it may be used in
|
|
an effectful context. By contrast, the former type may only be used in
|
|
a strictly pure context, i.e. the effect-free context.
|
|
%
|
|
\dhil{Maybe say something about reasoning effect types}
|
|
%
|
|
|
|
We can use the effect system to give precise types to effectful
|
|
computations. For example, we can give the signature of some
|
|
polymorphic computation that may only be run in a read-only context
|
|
%
|
|
\[
|
|
\forall \alpha^\Type, \varepsilon^{\Row_{\{\Read,\Write\}}}. \alpha \eff \{\Read:\Int,\Write:\Abs,\varepsilon\}.
|
|
\]
|
|
%
|
|
The effect row comprise a nullary $\Read$ operation returning some
|
|
integer and an absent operation $\Write$. The absence of $\Write$
|
|
means that the computation cannot run in a context that admits a
|
|
present $\Write$. It can, however, run in a context that admits a
|
|
presence polymorphic $\Write : \theta$ as the presence variable
|
|
$\theta$ may instantiated to $\Abs$. An inhabitant of this type may be
|
|
run in larger effect contexts, i.e. contexts that admit more
|
|
operations, because the row ends in an effect variable.
|
|
%
|
|
|
|
The type and effect system is also precise about how a higher-order
|
|
function may use its function arguments. For example consider the
|
|
signature of a map-operation over some datatype such as
|
|
$\dec{Option}~\alpha^\Type \defas [\dec{None};\dec{Some}:\alpha]$
|
|
%
|
|
\[
|
|
\forall \alpha^\Type,\beta^\Type,\varepsilon^{\Row_\emptyset}. \Record{\alpha \to \beta \eff \{\varepsilon\}, \dec{Option}~\alpha} \to \dec{Option}~\beta \eff \{\varepsilon\}.
|
|
\]
|
|
%
|
|
% The $\dec{map}$ function for
|
|
% lists is a canonical example of a higher-order function which is
|
|
% parametric in its own effects and the effects of its function
|
|
% argument. Supposing $\BCalc$ have some polymorphic list datatype
|
|
% $\List$, then we would be able to ascribe the following signature to
|
|
% $\dec{map}$
|
|
% %
|
|
% \[
|
|
% \forall \alpha^\Type,\beta^\Type,\varepsilon^{\Row_\emptyset}. \Record{\alpha \to \beta \eff \{\varepsilon\},\List~\alpha} \to \List~\beta \eff \{\varepsilon\}.
|
|
% \]
|
|
%
|
|
The first argument is the function that will be applied to the data
|
|
carried by second argument. Note that the two effect rows are
|
|
identical and share the same effect variable $\varepsilon$, it is thus
|
|
evident that an inhabitant of this type can only perform whatever
|
|
effects its first argument is allowed to perform.
|
|
|
|
Higher-order functions may also transform their function arguments,
|
|
e.g. modify their effect rows. The following is the signature of a
|
|
higher-order function which restricts its argument's effect context
|
|
%
|
|
\[
|
|
\forall \alpha^\Type, \varepsilon^{\Row_{\{\Read\}}},\varepsilon'^{\Row_\emptyset}. (\UnitType \to \alpha \eff \{\Read:\Int,\varepsilon\}) \to (\UnitType \to \alpha \eff \{\Read:\Abs,\varepsilon\}) \eff \{\varepsilon'\}.
|
|
\]
|
|
%
|
|
The function argument is allowed to perform a $\Read$ operation,
|
|
whilst the returned function cannot. Moreover, the two functions share
|
|
the same effect variable $\varepsilon$. Like the option-map signature
|
|
above, an inhabitant of this type performs no effects of its own as
|
|
the (right-most) effect row is a singleton row containing a distinct
|
|
effect variable $\varepsilon'$.
|
|
|
|
\paragraph{Syntactic sugar}
|
|
Detail the syntactic sugar\dots
|
|
|
|
\subsection{Terms}
|
|
\label{sec:base-language-terms}
|
|
%
|
|
\begin{figure}
|
|
\begin{syntax}
|
|
\slab{Variables} &x \in \VarCat&&\\
|
|
\slab{Values} &V,W \in \ValCat &::= & x
|
|
\mid \lambda x^A .\, M \mid \Lambda \alpha^K .\, M
|
|
\mid \Record{} \mid \Record{\ell = V;W} \mid (\ell~V)^R \\
|
|
& & &\\
|
|
\slab{Computations} &M,N \in \CompCat &::= & V\,W \mid V\,T\\
|
|
& &\mid& \Let\; \Record{\ell=x;y} = V \; \In \; N\\
|
|
& &\mid& \Case\; V \{\ell~x \mapsto M; y \mapsto N\} \mid \Absurd^C~V\\
|
|
& &\mid& \Return~V \mid \Let \; x \revto M \; \In \; N\\
|
|
\slab{Terms} &t \in \TermCat &::= & x \mid V \mid M
|
|
\end{syntax}
|
|
|
|
\caption{Term syntax of \BCalc{}.}
|
|
\label{fig:base-language-term-syntax}
|
|
\end{figure}
|
|
%
|
|
The syntax for terms is given in
|
|
Figure~\ref{fig:base-language-term-syntax}. We assume a countably
|
|
infinite set of names $\VarCat$ from which we draw fresh variable
|
|
names. We shall typically denote term variables by $x$, $y$, or $z$.
|
|
%
|
|
The syntax partitions terms into values and computations.
|
|
%
|
|
Value terms comprise variables ($x$), lambda abstraction
|
|
($\lambda x^A . \, M$), type abstraction ($\Lambda \alpha^K . \, M$),
|
|
and the introduction forms for records and variants. Records are
|
|
introduced using the empty record $(\Record{})$ and record extension
|
|
$(\Record{\ell = V; W})$, whilst variants are introduced using
|
|
injection $((\ell~V)^R)$, which injects a field with label $\ell$ and
|
|
value $V$ into a row whose type is $R$. We include the row type
|
|
annotation in to support bottom-up type reconstruction.
|
|
|
|
All elimination forms are computation terms. Abstraction and type
|
|
abstraction are eliminated using application ($V\,W$) and type
|
|
application ($V\,A$) respectively.
|
|
%
|
|
The record eliminator $(\Let \; \Record{\ell=x;y} = V \; \In \; N)$
|
|
splits a record $V$ into $x$, the value associated with $\ell$, and
|
|
$y$, the rest of the record. Non-empty variants are eliminated using
|
|
the case construct ($\Case\; V\; \{\ell~x \mapsto M; y \mapsto N\}$),
|
|
which evaluates the computation $M$ if the tag of $V$ matches
|
|
$\ell$. Otherwise it falls through to $y$ and evaluates $N$. The
|
|
elimination form for empty variants is ($\Absurd^C~V$).
|
|
%
|
|
There is one computation introduction form, namely, the trivial
|
|
computation $(\Return~V)$ which returns value $V$. Its elimination
|
|
form is the expression $(\Let \; x \revto M \; \In \; N)$ which evaluates
|
|
$M$ and binds the result value to $x$ in $N$.
|
|
%
|
|
|
|
%
|
|
As our calculus is intrinsically typed, we annotate terms with type or
|
|
kind information (term abstraction, type abstraction, injection,
|
|
operations, and empty cases). However, we shall omit these annotations
|
|
whenever they are clear from context.
|
|
|
|
\paragraph{Free variables} A given term is said to be \emph{closed} if
|
|
every applied occurrence of a variable is preceded by some
|
|
corresponding binding occurrence. Any applied occurrence of a variable
|
|
that is not preceded by a binding occurrence is said be \emph{free
|
|
variable}. We define the function $\FV : \TermCat \to \VarCat$
|
|
inductively on the term structure to compute the free variables of any
|
|
given term.
|
|
%
|
|
\[
|
|
\bl
|
|
\ba[t]{@{~}l@{~}c@{~}l}
|
|
\begin{eqs}
|
|
\FV(x) &\defas& \{x\}\\
|
|
\FV(\lambda x^A.M) &\defas& \FV(M) \setminus \{x\}\\
|
|
\FV(\Lambda \alpha^K.M) &\defas& \FV(M)\\[1.0ex]
|
|
\FV(V\,W) &\defas& \FV(V) \cup \FV(W)\\
|
|
\FV(\Return~V) &\defas& \FV(V)\\
|
|
\end{eqs}
|
|
& \qquad\qquad &
|
|
\begin{eqs}
|
|
\FV(\Record{}) &\defas& \emptyset\\
|
|
\FV(\Record{\ell = V; W}) &\defas& \FV(V) \cup \FV(W)\\
|
|
\FV((\ell~V)^R) &\defas& \FV(V)\\[1.0ex]
|
|
\FV(V\,T) &\defas& \FV(V)\\
|
|
\FV(\Absurd^C~V) &\defas& \FV(V)\\
|
|
\end{eqs}
|
|
\ea\\
|
|
\begin{eqs}
|
|
\FV(\Let\;x \revto M \;\In\;N) &\defas& \FV(M) \cup (\FV(N) \setminus \{x\})\\
|
|
\FV(\Let\;\Record{\ell=x;y} = V\;\In\;N) &\defas& \FV(V) \cup (\FV(N) \setminus \{x, y\})\\
|
|
\FV(\Case~V~\{\ell\,x \mapsto M; y \mapsto N\} &\defas& \FV(V) \cup (\FV(M) \setminus \{x\}) \cup (\FV(N) \setminus \{y\})
|
|
\end{eqs}
|
|
\el
|
|
\]
|
|
%
|
|
The function computes the set of free variables bottom-up. Most cases
|
|
are homomorphic on the syntax constructors. The interesting cases are
|
|
those constructs which feature term binders: lambda abstraction, let
|
|
bindings, pair deconstructing, and case splitting. In each of those
|
|
cases we subtract the relevant binder(s) from the set of free
|
|
variables.
|
|
|
|
\paragraph{Tail recursion}
|
|
|
|
In practice implementations of functional programming languages tend
|
|
to be tail-recursive in order to enable unbounded iteration. Otherwise
|
|
nested (repeated) function calls would quickly run out of stack space
|
|
on a conventional computer.
|
|
%
|
|
Intuitively, tail-recursion permits an already allocated stack frame
|
|
for some on-going function call to be reused by a nested function
|
|
call, provided that this nested call is the last thing to occur before
|
|
returning from the on-going function call.
|
|
%
|
|
A special case is when the nested function call is a fresh invocation
|
|
of the on-going function call, i.e. a self-reference. In this case the
|
|
nested function call is known as a \emph{tail recursive call},
|
|
otherwise it is simply known as a \emph{tail call}.
|
|
%
|
|
Thus the qualifier ``tail-recursive'' may be somewhat confusing as for
|
|
an implementation to be tail-recursive it must support recycling of
|
|
stack frames for tail calls; it is not sufficient to support tail
|
|
recursive calls.
|
|
%
|
|
|
|
Any decent implementation of Standard ML~\cite{MilnerTHM97},
|
|
OCaml~\cite{LeroyDFGRV20}, or Scheme~\cite{SperberDFSFM10} will be
|
|
tail-recursive. I deliberately say implementation rather than
|
|
specification, because it is often the case that the specification or
|
|
the user manual do not explicitly require a suitable implementation to
|
|
be tail-recursive; in fact of the three languages just mentioned only
|
|
Scheme explicitly mandates an implementation to be
|
|
tail-recursive~\cite{SperberDFSFM10}.
|
|
%
|
|
% The Scheme specification actually goes further and demands that an
|
|
% implementation is \emph{properly tail-recursive}, which provides
|
|
% strict guarantees on the asymptotic space consumption of tail
|
|
% calls~\cite{Clinger98}.
|
|
|
|
Tail calls will become important in Chapter~\ref{ch:cps} when we will
|
|
discuss continuation passing style as an implementation technique for
|
|
effect handlers, as tail calls happen to be ubiquitous in continuation
|
|
passing style.
|
|
%
|
|
Therefore let us formally characterise tail calls.
|
|
%
|
|
For our purposes, the most robust characterisation is a syntactic
|
|
characterisation, as opposed to a semantic characterisation, because
|
|
in the presence of control effects (which we will add in
|
|
Chapter~\ref{ch:unary-handlers}) it surprisingly tricky to describe
|
|
tail calls in terms of control flow such as ``the last thing to occur
|
|
before returning from the enclosing function'' as a function may
|
|
return multiple times. In particular, the effects of a function may be
|
|
replayed several times.
|
|
%
|
|
|
|
For this reason we will adapt a syntactic characterisation of tail
|
|
calls due to \citet{Clinger98}. First, we define what it means for a
|
|
computation to syntactically \emph{appear in tail position}.
|
|
%
|
|
\begin{definition}[Tail position]\label{def:tail-comp}
|
|
Tail position is a transitive notion for computation terms, which is
|
|
defined inductively as follows.
|
|
%
|
|
\begin{itemize}
|
|
\item The body $M$ of a $\lambda$-abstraction ($\lambda x. M$) appears in
|
|
tail position.
|
|
\item The body $M$ of a $\Lambda$-abstraction $(\Lambda \alpha.M)$
|
|
appears in tail position.
|
|
\item If $\Case\;V\;\{\ell\,x \mapsto M; y \mapsto N\}$ appears in tail
|
|
position, then both $M$ and $N$ appear in tail positions.
|
|
\item If $\Let\;\Record{\ell = x; y} = V \;\In\;N$ appears in tail
|
|
position, then $N$ is in tail position.
|
|
\item If $\Let\;x \revto M\;\In\;N$ appears in tail position, then
|
|
$N$ appear in tail position.
|
|
\item Nothing else appears in tail position.
|
|
\end{itemize}
|
|
\end{definition}
|
|
%
|
|
\begin{definition}[Tail call]\label{def:tail-call}
|
|
An application term $V\,W$ is said to be a tail call if it appears
|
|
in tail position.
|
|
\end{definition}
|
|
%
|
|
% The syntactic position of a tail call is often referred to as the
|
|
% \emph{tail-position}.
|
|
%
|
|
|
|
\subsection{Typing rules}
|
|
\label{sec:base-language-type-rules}
|
|
%
|
|
\begin{figure}
|
|
Values
|
|
\begin{mathpar}
|
|
% Variable
|
|
\inferrule*[Lab=\tylab{Var}]
|
|
{x : A \in \Gamma}
|
|
{\typv{\Delta;\Gamma}{x : A}}
|
|
|
|
% Abstraction
|
|
\inferrule*[Lab=\tylab{Lam}]
|
|
{\typ{\Delta;\Gamma, x : A}{M : C}}
|
|
{\typv{\Delta;\Gamma}{\lambda x^A .\, M : A \to C}}
|
|
|
|
% Polymorphic abstraction
|
|
\inferrule*[Lab=\tylab{PolyLam}]
|
|
{\typv{\Delta,\alpha : K;\Gamma}{M : C} \\
|
|
\alpha \notin \FTV(\Gamma)
|
|
}
|
|
{\typv{\Delta;\Gamma}{\Lambda \alpha^K .\, M : \forall \alpha^K . \,C}}
|
|
\\
|
|
% unit : ()
|
|
\inferrule*[Lab=\tylab{Unit}]
|
|
{ }
|
|
{\typv{\Delta;\Gamma}{\Record{} : \UnitType}}
|
|
|
|
% Extension
|
|
\inferrule*[Lab=\tylab{Extend}]
|
|
{ \typv{\Delta;\Gamma}{V : A} \\
|
|
\typv{\Delta;\Gamma}{W : \Record{\ell:\Abs;R}}
|
|
}
|
|
{\typv{\Delta;\Gamma}{\Record{\ell=V;W} : \Record{\ell:\Pre{A};R}}}
|
|
|
|
% Inject
|
|
\inferrule*[Lab=\tylab{Inject}]
|
|
{\typv{\Delta;\Gamma}{V : A}}
|
|
{\typv{\Delta;\Gamma}{(\ell~V)^R : [\ell : \Pre{A}; R]}}
|
|
\end{mathpar}
|
|
Computations
|
|
\begin{mathpar}
|
|
% Application
|
|
\inferrule*[Lab=\tylab{App}]
|
|
{\typv{\Delta;\Gamma}{V : A \to C} \\
|
|
\typv{\Delta;\Gamma}{W : A}
|
|
}
|
|
{\typ{\Delta;\Gamma}{V\,W : C}}
|
|
|
|
% Polymorphic application
|
|
\inferrule*[Lab=\tylab{PolyApp}]
|
|
{\typv{\Delta;\Gamma}{V : \forall \alpha^K . \, C} \\
|
|
\Delta \vdash A : K
|
|
}
|
|
{\typ{\Delta;\Gamma}{V\,A : C[A/\alpha]}}
|
|
|
|
% Split
|
|
\inferrule*[Lab=\tylab{Split}]
|
|
{\typv{\Delta;\Gamma}{V : \Record{\ell : \Pre{A};R}} \\\\
|
|
\typ{\Delta;\Gamma, x : A, y : \Record{\ell : \Abs; R}}{N : C}
|
|
}
|
|
{\typ{\Delta;\Gamma}{\Let \; \Record{\ell =x;y} = V\; \In \; N : C}}
|
|
|
|
% Case
|
|
\inferrule*[Lab=\tylab{Case}]
|
|
{ \typv{\Delta;\Gamma}{V : [\ell : \Pre{A};R]} \\\\
|
|
\typ{\Delta;\Gamma,x:A}{M : C} \\\\
|
|
\typ{\Delta;\Gamma,y:[\ell : \Abs;R]}{N : C}
|
|
}
|
|
{\typ{\Delta;\Gamma}{\Case \; V \{\ell\; x \mapsto M;y \mapsto N \} : C}}
|
|
|
|
% Absurd
|
|
\inferrule*[Lab=\tylab{Absurd}]
|
|
{\typv{\Delta;\Gamma}{V : []}}
|
|
{\typ{\Delta;\Gamma}{\Absurd^C \; V : C}}
|
|
|
|
% Return
|
|
\inferrule*[Lab=\tylab{Return}]
|
|
{\typv{\Delta;\Gamma}{V : A}}
|
|
{\typc{\Delta;\Gamma}{\Return \; V : A}{E}}
|
|
\\
|
|
% Let
|
|
\inferrule*[Lab=\tylab{Let}]
|
|
{\typc{\Delta;\Gamma}{M : A}{E} \\
|
|
\typ{\Delta;\Gamma, x : A}{N : C}
|
|
}
|
|
{\typ{\Delta;\Gamma}{\Let \; x \revto M\; \In \; N : C}}
|
|
\end{mathpar}
|
|
\caption{Typing rules}
|
|
\label{fig:base-language-type-rules}
|
|
\end{figure}
|
|
%
|
|
Thus the rule states that a type abstraction $(\Lambda \alpha. M)$ has
|
|
type $\forall \alpha.C$ if the computation $M$ has type $C$ assuming
|
|
$\alpha : K$ and $\alpha$ does not appear in the free type variables
|
|
of current type environment $\Gamma$. The \tylab{Unit} rule provides
|
|
the basis for all records as it simply states that the empty record
|
|
has type unit. The \tylab{Extend} rule handles record
|
|
extension. Supposing we wish to extend some record $\Record{W}$ with
|
|
$\ell = V$, that is $\Record{\ell = V; W}$. This extension has type
|
|
$\Record{\ell : \Pre{A};R}$ if and only if $V$ is well-typed and we
|
|
can ascribe $W : \Record{\ell : \Abs; R}$. Since
|
|
$\Record{\ell : \Abs; R}$ must be well-kinded with respect to
|
|
$\Delta$, the label $\ell$ cannot be mentioned in $W$, thus $\ell$
|
|
cannot occur more than once in the record. Similarly, the dual rule
|
|
\tylab{Inject} states that the injection $(\ell~V)^R$ has type
|
|
$[\ell : \Pre{A}; R]$ if the payload $V$ is well-typed. The implicit
|
|
well-kindedness condition on $R$ ensures that $\ell$ cannot be
|
|
injected twice. To illustrate how the kinding system prevents
|
|
duplicated labels consider the following ill-typed example
|
|
%
|
|
\[
|
|
(\dec{S}~\Unit)^{\dec{S}:\UnitType} : [\dec{S}:\UnitType;\dec{S}:\UnitType].
|
|
\]
|
|
%
|
|
Typing fails because the resulting row type is ill-kinded by the
|
|
\klab{ExtendRow}-rule:
|
|
\begin{mathpar}
|
|
\inferrule*[leftskip=6.5em,Right={\klab{Variant}}]
|
|
{\inferrule*[Right={\klab{ExtendRow}}]
|
|
{\vdash \Pre{\UnitType} : \Presence \\
|
|
\inferrule*[Right={\klab{ExtendRow}}]
|
|
{\vdash \Pre{\UnitType} : \Presence \\ \vdash \cdot : \Row_{\color{red}{\{\dec{S}\} \uplus \{\dec{S}\}}}}
|
|
{\vdash \dec{S}:\Pre{\UnitType};\cdot : \Row_{\emptyset \uplus \{\dec{S}\}}}}
|
|
{\vdash \dec{S}:\Pre{\UnitType};\dec{S}:\Pre{\UnitType};\cdot : \Row_{\emptyset}}
|
|
}
|
|
{\vdash [\dec{S}:\Pre{\UnitType};\dec{S}:\Pre{\UnitType};\cdot] : \Type}
|
|
\end{mathpar}
|
|
%
|
|
The two sets $\{\dec{S}\}$ and $\{\dec{S}\}$ are clearly not disjoint,
|
|
thus the second premise of the last application of \klab{ExtendRow}
|
|
cannot be satisfied.
|
|
|
|
\paragraph{Typing computations}
|
|
The \tylab{App} rule states that an application $V\,W$ has computation
|
|
type $C$ if the function-term $V$ has type $A \to C$ and the
|
|
argument term $W$ has type $A$, that is both the argument type and the
|
|
domain type of the abstractor agree.
|
|
%
|
|
The type application rule \tylab{PolyApp} tells us that a type
|
|
application $V\,A$ is well-typed whenever the abstractor term $V$ has
|
|
the polymorphic type $\forall \alpha^K.C$ and the type $A$ has kind
|
|
$K$. This rule makes use of type substitution.
|
|
%
|
|
The \tylab{Split} rule handles typing of record deconstructing. When
|
|
splitting a record term $V$ on some label $\ell$ binding it to $x$ and
|
|
the remainder to $y$. The label we wish to split on must be present
|
|
with some type $A$, hence we require that
|
|
$V : \Record{\ell : \Pre{A}; R}$. This restriction prohibits us for
|
|
splitting on an absent or presence polymorphic label. The
|
|
continuation of the splitting, $N$, must then have some computation
|
|
type $C$ subject to the following restriction: $N : C$ must be
|
|
well-typed under the additional assumptions $x : A$ and
|
|
$y : \Record{\ell : \Abs; R}$, statically ensuring that it is not
|
|
possible to split on $\ell$ again in the continuation $N$.
|
|
%
|
|
The \tylab{Case} rule is similar, but has two possible continuations:
|
|
the success continuation, $M$, and the fall-through continuation, $N$.
|
|
The label being matched must be present with some type $A$ in the type
|
|
of the scrutinee, thus we require $V : [\ell : \Pre{A};R]$. The
|
|
success continuation has some computation $C$ under the assumption
|
|
that the binder $x : A$, whilst the fall-through continuation also has
|
|
type $C$ it is subject to the restriction that the binder
|
|
$y : [\ell : \Abs;R]$ which statically enforces that no subsequent
|
|
case split in $N$ can match on $\ell$.
|
|
%
|
|
The \tylab{Absurd} states that we can ascribe any computation type to
|
|
the term $\Absurd~V$ if $V$ has the empty type $[]$.
|
|
%
|
|
The trivial computation term is typed by the \tylab{Return} rule,
|
|
which says that $\Return\;V$ has computation type $A \eff E$ if the
|
|
value $V$ has type $A$.
|
|
%
|
|
The \tylab{Let} rule types let bindings. The computation being bound,
|
|
$M$, must have computation type $A \eff E$, whilst the continuation,
|
|
$N$, must have computation $C$ subject to the additional assumption
|
|
that the binder $x : A$.
|
|
|
|
\section{Dynamic semantics}
|
|
\label{sec:base-language-dynamic-semantics}
|
|
%
|
|
\begin{figure}
|
|
\begin{reductions}
|
|
\semlab{App} & (\lambda x^A . \, M) V &\reducesto& M[V/x] \\
|
|
\semlab{TyApp} & (\Lambda \alpha^K . \, M) A &\reducesto& M[A/\alpha] \\
|
|
\semlab{Split} & \Let \; \Record{\ell = x;y} = \Record{\ell = V;W} \; \In \; N &\reducesto& N[V/x,W/y] \\
|
|
\semlab{Case_1} &
|
|
\Case \; (\ell~V)^R \{ \ell \; x \mapsto M; y \mapsto N\} &\reducesto& M[V/x] \\
|
|
\semlab{Case_2} &
|
|
\Case \; (\ell~V)^R \{ \ell' \; x \mapsto M; y \mapsto N\} &\reducesto& N[(\ell~V)^R/y], \hfill\quad \text{if } \ell \neq \ell' \\
|
|
\semlab{Let} &
|
|
\Let \; x \revto \Return \; V \; \In \; N &\reducesto& N[V/x] \\
|
|
\semlab{Lift} &
|
|
\EC[M] &\reducesto& \EC[N], \hfill\quad \text{if } M \reducesto N \\
|
|
\end{reductions}
|
|
\begin{syntax}
|
|
\slab{Evaluation contexts} & \mathcal{E} \in \EvalCat &::=& [~] \mid \Let \; x \revto \mathcal{E} \; \In \; N
|
|
\end{syntax}
|
|
%
|
|
\dhil{Describe evaluation contexts as functions: decompose and plug.}
|
|
%
|
|
%%\[
|
|
% Evaluation context lift
|
|
%% \inferrule*[Lab=\semlab{Lift}]
|
|
%% { M \reducesto N }
|
|
%% { \mathcal{E}[M] \reducesto \mathcal{E}[N]}
|
|
%% \]
|
|
|
|
\caption{Contextual small-step semantics}
|
|
\label{fig:base-language-small-step}
|
|
\end{figure}
|
|
%
|
|
In this section I will present the dynamic semantics of \BCalc{}. I
|
|
have chosen opt to use a \citet{Felleisen87}-style contextual
|
|
small-step semantics, since in conjunction with fine-grain
|
|
call-by-value (FGCBV), it yields a considerably simpler semantics than
|
|
the traditional structural operational semantics
|
|
(SOS)~\cite{Plotkin04a}, because only the rule for let bindings admits
|
|
a continuation wheres in ordinary call-by-value SOS each congruence
|
|
rule admits a continuation.
|
|
%
|
|
The simpler semantics comes at the expense of a more verbose syntax,
|
|
which is not a concern as one can readily convert between fine-grain
|
|
call-by-value and ordinary call-by-value.
|
|
|
|
The reduction semantics are based on a substitution model of
|
|
computation. Thus, before presenting the reduction rules, we define an
|
|
adequate substitution function. As usual we work up to
|
|
$\alpha$-conversion~\cite{Church32} of terms in $\BCalc{}$.
|
|
%
|
|
\paragraph{Term substitution}
|
|
We define a term substitution map,
|
|
$\sigma : (\VarCat \times \ValCat)^\ast$ as list of pairs mapping a
|
|
variable to its value replacement. We denote a single mapping as $V/x$
|
|
meaning substitute $V$ for the variable $x$. We write multiple
|
|
mappings using list notation, i.e. $[V_0/x_0,\dots,V_n/x_n]$. The
|
|
domain of a substitution map is set generated by projecting the first
|
|
component, i.e.
|
|
%
|
|
\[
|
|
\bl
|
|
\dom : (\VarCat \times \ValCat)^\ast \to \ValCat\\
|
|
\dom(\sigma) \defas \{ x \mid (\_/x) \in \sigma \}
|
|
\el
|
|
\]
|
|
%
|
|
The application of a type substitution map on a term $t \in \TermCat$,
|
|
written $t\sigma$, is defined inductively on the term structure as
|
|
follows.
|
|
%
|
|
\[
|
|
\ba[t]{@{~}l@{~}c@{~}r}
|
|
\begin{eqs}
|
|
x\sigma &\defas& \begin{cases}
|
|
V & \text{if } (x, V) \in \sigma\\
|
|
x & \text{otherwise}
|
|
\end{cases}\\
|
|
(\lambda x^A.M)\sigma &\simdefas& \lambda x^A.M\sigma\\
|
|
(\Lambda \alpha^K.M)\sigma &\defas& \Lambda \alpha^K.M\sigma\\
|
|
(V~T)\sigma &\defas& V\sigma~T
|
|
\end{eqs}
|
|
&~~&
|
|
\begin{eqs}
|
|
(V~W)\sigma &\defas& V\sigma~W\sigma\\
|
|
\Unit\sigma &\defas& \Unit\\
|
|
\Record{\ell = V; W}\sigma &\defas& \Record{\ell = V\sigma;W\sigma}\\
|
|
(\ell~V)^R\sigma &\defas& (\ell~V\sigma)^R\\
|
|
\end{eqs}\bigskip\\
|
|
\multicolumn{3}{c}{
|
|
\begin{eqs}
|
|
(\Let\;\Record{\ell = x; y} = V\;\In\;N)\sigma &\simdefas& \Let\;\Record{\ell = x; y} = V\sigma\;\In\;N\sigma\\
|
|
(\Case\;(\ell~V)^R\{
|
|
\ell~x \mapsto M
|
|
; y \mapsto N \})\sigma
|
|
&\simdefas&
|
|
\Case\;(\ell~V\sigma)^R\{
|
|
\ell~x \mapsto M\sigma
|
|
; y \mapsto N\sigma \}\\
|
|
(\Let\;x \revto M \;\In\;N)\sigma &\simdefas& \Let\;x \revto M[V/y] \;\In\;N\sigma
|
|
\end{eqs}}
|
|
\ea
|
|
\]
|
|
%
|
|
The attentive reader will notice that I am using the same notation for
|
|
type and term substitutions. In fact, we shall go further and unify
|
|
the two notions of substitution by combining them. As such we may
|
|
think of a combined substitution map as pair of a term substitution
|
|
map and a type substitution map, i.e.
|
|
$\sigma : (\VarCat \times \ValCat)^\ast \times (\TyVarCat \times
|
|
\TypeCat)^\ast$. The application of a combined substitution mostly the
|
|
same as the application of a term substitution map save for a couple
|
|
equations in which we need to apply the type substitution map
|
|
component to a type annotation and type abstraction which now might
|
|
require a change of name of the bound type variable
|
|
%
|
|
\[
|
|
\bl
|
|
(\lambda x^A.M)\sigma \defas \lambda x^{A\sigma.2}.M\sigma, \qquad
|
|
(V~T)\sigma \defas V\sigma~T\sigma.2, \qquad
|
|
(\ell~V)^R\sigma \defas (\ell~V\sigma)^{R\sigma.2}\medskip\\
|
|
|
|
\begin{eqs}
|
|
(\Lambda \alpha^K.M)\sigma &\simdefas& \Lambda \alpha^K.M\sigma\\
|
|
(\Case\;(\ell~V)^R\{
|
|
\ell~x \mapsto M
|
|
; y \mapsto N \})\sigma
|
|
&\simdefas&
|
|
\Case\;(\ell~V\sigma)^{R\sigma.2}\{
|
|
\ell~x \mapsto M\sigma
|
|
; y \mapsto N\sigma \}.
|
|
\end{eqs}
|
|
\el
|
|
\]
|
|
%
|
|
|
|
% We shall go further and use the
|
|
% notation to mean simultaneous substitution of types and terms, that is
|
|
% we
|
|
% %
|
|
% We justify this choice by the fact that we can lift type substitution
|
|
% pointwise on the term syntax constructors, enabling us to use one
|
|
% uniform notation for substitution.
|
|
% %
|
|
% Thus we shall generally allow a mix
|
|
% of pairs of variables and values and pairs of type variables and types
|
|
% to occur in the same substitution map.
|
|
|
|
\paragraph{Reduction semantics}
|
|
The reduction relation $\reducesto \subseteq \CompCat \times \CompCat$
|
|
relates a computation term to another if the former can reduce to the
|
|
latter in a single step. Figure~\ref{fig:base-language-small-step}
|
|
depicts the reduction rules. The application rules \semlab{App} and
|
|
\semlab{TyApp} eliminates a lambda and type abstraction, respectively,
|
|
by substituting the argument for the parameter in their body
|
|
computation $M$.
|
|
%
|
|
Record splitting is handled by the \semlab{Split} rule: splitting on
|
|
some label $\ell$ binds the payload $V$ to $x$ and the remainder $W$
|
|
to $y$ in the continuation $N$.
|
|
%
|
|
Disjunctive case splitting is handled by the two rules
|
|
\semlab{Case_1} and \semlab{Case_2}. The former rule handles the
|
|
success case, when the scrutinee's tag $\ell$ matches the tag of the
|
|
success clause, thus binds the payload $V$ to $x$ and proceeds to
|
|
evaluate the continuation $M$. The latter rule handles the
|
|
fall-through case, here the scrutinee gets bounds to $y$ and
|
|
evaluation proceeds with the continuation $N$.
|
|
%
|
|
The \semlab{Let} rule eliminates a trivial computation term
|
|
$\Return\;V$ by substituting $V$ for $x$ in the continuation $N$.
|
|
%
|
|
|
|
|
|
\paragraph{Evaluation contexts}
|
|
Recall from Section~\ref{sec:base-language-terms},
|
|
Figure~\ref{fig:base-language-term-syntax} that the syntax of let
|
|
bindings allows a general computation term $M$ to occur on the right
|
|
hand side of the binding, i.e. $\Let\;x \revto M \;\In\;N$. Thus we
|
|
are seemingly stuck in the general case, as the \semlab{Let} rule only
|
|
applies if the right hand side is a trivial computation.
|
|
%
|
|
However, it is at this stage we make use of the notion of
|
|
\emph{evaluation contexts} due to \citet{Felleisen87}. An evaluation
|
|
context is syntactic construction which decompose the dynamic
|
|
semantics into a set of base rules (i.e. the rules presented thus far)
|
|
and an inductive rule, which enables us to focus on a particular
|
|
computation term, $M$, in some larger context, $\EC$, and reduce it in
|
|
the said context to another computation $N$ if $M$ reduces outside out
|
|
the context to that particular $N$. In our formalism, we call this
|
|
rule \semlab{Lift}. Evaluation contexts are generated from the empty
|
|
context ($[~]$) and let expressions ($\Let\;x \revto \EC \;\In\;N$).
|
|
|
|
The choices of using fine-grain call-by-value and evaluation contexts
|
|
may seem odd, if not arbitrary at this point; the reader may wonder
|
|
with good reason why we elect to use fine-grain call-by-value over
|
|
ordinary call-by-value. In Chapter~\ref{ch:unary-handlers} we will
|
|
reap the benefits from our design choices, as we shall see that the
|
|
combination of fine-grain call-by-value and evaluation contexts
|
|
provide the basis for a convenient, simple semantic framework for
|
|
working with continuations.
|
|
|
|
\section{Metatheoretic properties of \BCalc{}}
|
|
\label{sec:base-language-metatheory}
|
|
|
|
Thus far we have defined the syntax, static semantics, and dynamic
|
|
semantics of \BCalc{}. In this section, we state and prove some
|
|
customary metatheoretic properties about \BCalc{}.
|
|
%
|
|
|
|
We begin by showing that substitutions preserve typability.
|
|
%
|
|
\begin{lemma}[Preservation of typing under substitution]\label{lem:base-language-subst}
|
|
Let $\sigma$ be any type substitution and $V \in \ValCat$ be any
|
|
value and $M \in \CompCat$ a computation such that
|
|
$\typ{\Delta;\Gamma}{V : A}$ and $\typ{\Delta;\Gamma}{M : C}$, then
|
|
$\typ{\Delta;\Gamma\sigma}{V\sigma : A\sigma}$ and
|
|
$\typ{\Delta;\Gamma\sigma}{M\sigma : C\sigma}$.
|
|
\end{lemma}
|
|
%
|
|
\begin{proof}
|
|
By induction on the typing derivations.
|
|
\end{proof}
|
|
%
|
|
\dhil{It is clear to me at this point, that I want to coalesce the
|
|
substitution functions. Possibly define them as maps rather than ordinary functions.}
|
|
|
|
The reduction semantics satisfy a \emph{unique decomposition}
|
|
property, which guarantees the existence and uniqueness of complete
|
|
decomposition for arbitrary computation terms into evaluation
|
|
contexts.
|
|
%
|
|
\begin{lemma}[Unique decomposition]\label{lem:base-language-uniq-decomp}
|
|
For any computation $M \in \CompCat$ it holds that $M$ is either
|
|
stuck or there exists a unique evaluation context $\EC \in \EvalCat$
|
|
and a redex $N \in \CompCat$ such that $M = \EC[N]$.
|
|
\end{lemma}
|
|
%
|
|
\begin{proof}
|
|
By structural induction on $M$.
|
|
\begin{description}
|
|
\item[Base step] $M = N$ where $N$ is either $\Return\;V$,
|
|
$\Absurd^C\;V$, $V\,W$, or $V\,T$. In each case take $\EC = [\,]$
|
|
such that $M = \EC[N]$.
|
|
\item[Inductive step]
|
|
%
|
|
There are several cases to consider. In each case we must find an
|
|
evaluation context $\EC$ and a computation term $M'$ such that
|
|
$M = \EC[M']$.
|
|
\begin{itemize}
|
|
\item[Case] $M = \Let\;\Record{\ell = x; y} = V\;\In\;N$: Take $\EC = [\,]$ such that $M = \EC[\Let\;\Record{\ell = x; y} = V\;\In\;N]$.
|
|
\item[Case] $M = \Case\;V\,\{\ell\,x \mapsto M'; y \mapsto N\}$:
|
|
Take $\EC = [\,]$ such that
|
|
$M = \EC[\Case\;V\,\{\ell\,x \mapsto M'; y \mapsto N\}]$.
|
|
\item[Case] $M = \Let\;x \revto M' \;\In\;N$: By the induction
|
|
hypothesis it follows that $M'$ is either stuck or it
|
|
decomposes (uniquely) into an evaluation context $\EC'$ and a
|
|
redex $N'$. If $M'$ is stuck, then so is $M$. Otherwise take
|
|
$\EC = \Let\;x \revto \EC'\;\In\;N$ such that $M = \EC[N']$.
|
|
\end{itemize}
|
|
\end{description}
|
|
\end{proof}
|
|
|
|
%
|
|
The calculus enjoys a rather strong \emph{progress} property, which
|
|
states that \emph{every} closed computation term reduces to a trivial
|
|
computation term $\Return\;V$ for some value $V$. In other words, any
|
|
realisable function in \BCalc{} is effect-free and total.
|
|
%
|
|
\begin{definition}[Computation normal form]\label{def:base-language-comp-normal}
|
|
A computation $M \in \CompCat$ is said to be \emph{normal} if it is
|
|
of the form $\Return\; V$ for some value $V \in \ValCat$.
|
|
\end{definition}
|
|
%
|
|
\begin{theorem}[Progress]\label{thm:base-language-progress}
|
|
Suppose $\typ{}{M : C}$, then $M$ is normal or there exists
|
|
$\typ{}{N : C}$ such that $M \reducesto^\ast N$.
|
|
\end{theorem}
|
|
%
|
|
\begin{proof}
|
|
By induction on typing derivations.
|
|
\end{proof}
|
|
%
|
|
% \begin{corollary}
|
|
% Every closed computation term in \BCalc{} is terminating.
|
|
% \end{corollary}
|
|
%
|
|
The calculus also satisfies the \emph{subject reduction} property,
|
|
which states that if some computation $M$ is well typed and reduces to
|
|
some other computation $M'$, then $M'$ is also well typed.
|
|
%
|
|
\begin{theorem}[Subject reduction]\label{thm:base-language-preservation}
|
|
Suppose $\typ{\Gamma}{M : C}$ and $M \reducesto M'$, then
|
|
$\typ{\Gamma}{M' : C}$.
|
|
\end{theorem}
|
|
%
|
|
\begin{proof}
|
|
By induction on typing derivations.
|
|
\end{proof}
|
|
|
|
\section{A primitive effect: recursion}
|
|
\label{sec:base-language-recursion}
|
|
%
|
|
As evident from Theorem~\ref{thm:base-language-progress} \BCalc{}
|
|
admit no computational effects. As a consequence every realisable
|
|
program is terminating. Thus the calculus provide a solid and minimal
|
|
basis for studying the expressiveness of any extension, and in
|
|
particular, which primitive effects any such extension may sneak into
|
|
the calculus.
|
|
|
|
However, we cannot write many (if any) interesting programs in
|
|
\BCalc{}. The calculus is simply not expressive enough. In order to
|
|
bring it closer to the ML-family of languages we endow the calculus
|
|
with a fixpoint operator which introduces recursion as a primitive
|
|
effect. We dub the resulting calculus \BCalcRec{}.
|
|
%
|
|
|
|
First we augment the syntactic category of values with a new
|
|
abstraction form for recursive functions.
|
|
%
|
|
\begin{syntax}
|
|
& V,W \in \ValCat &::=& \cdots \mid \Rec \; f^{A \to C} \, x.M
|
|
\end{syntax}
|
|
%
|
|
The $\Rec$ construct binds the function name $f$ and its argument $x$
|
|
in the body $M$. Typing of recursive functions is standard.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*[Lab=\tylab{Rec}]
|
|
{\typ{\Delta;\Gamma,f : A \to C, x : A}{M : C}}
|
|
{\typ{\Delta;\Gamma}{(\Rec \; f^{A \to C} \, x . M) : A \to C}}
|
|
\end{mathpar}
|
|
%
|
|
The reduction semantics are also standard.
|
|
%
|
|
\begin{reductions}
|
|
\semlab{Rec} &
|
|
(\Rec \; f^{A \to C} \, x.M)\,V &\reducesto& M[(\Rec \; f^{A \to C}\,x.M)/f, V/x]
|
|
\end{reductions}
|
|
%
|
|
Every occurrence of $f$ in $M$ is replaced by the recursive abstractor
|
|
term, while every $x$ in $M$ is replaced by the value argument $V$.
|
|
|
|
The introduction of recursion means we obtain a slightly weaker
|
|
progress theorem as some programs may now diverge.
|
|
%
|
|
\begin{theorem}[Progress]
|
|
\label{thm:base-rec-language-progress}
|
|
Suppose $\typ{}{M : C}$, then $M$ is normal or there exists
|
|
$\typ{}{N : C}$ such that $M \reducesto^\ast N$.
|
|
\end{theorem}
|
|
%
|
|
\begin{proof}
|
|
Similar to the proof of Theorem~\ref{thm:base-language-progress}.
|
|
\end{proof}
|
|
|
|
\subsection{Tracking divergence via the effect system}
|
|
\label{sec:tracking-div}
|
|
%
|
|
With the $\Rec$-operator in \BCalcRec{} we can now implement the
|
|
factorial function.
|
|
%
|
|
\[
|
|
\bl
|
|
\dec{fac} : \Int \to \Int \eff \emptyset\\
|
|
\dec{fac} \defas \Rec\;f~n.
|
|
\ba[t]{@{}l}
|
|
\Let\;is\_zero \revto n = 0\;\In\\
|
|
\If\;is\_zero\;\Then\; \Return\;1\\
|
|
\Else\;\ba[t]{@{~}l}
|
|
\Let\; n' \revto n - 1 \;\In\\
|
|
\Let\; m \revto f~n' \;\In\\
|
|
n * m
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The $\dec{fac}$ function computes $n!$ for any non-negative integer
|
|
$n$. If $n$ is negative then $\dec{fac}$ diverges as the function will
|
|
repeatedly select the $\Else$-branch in the conditional
|
|
expression. Thus this function is not total on its domain. Yet the
|
|
effect signature does not alert us about the potential divergence. In
|
|
fact, in this particular instance the effect row on the computation
|
|
type is empty, which might deceive the doctrinaire to think that this
|
|
function is `pure'. Whether this function is pure or impure depend on
|
|
the precise notion of purity -- which we have yet to choose. In
|
|
Section~\ref{sec:notions-of-purity} we shall make clear the notion of
|
|
purity that we have mind, however, first let us briefly illustrate how
|
|
we might utilise the effect system to track divergence.
|
|
|
|
The key to tracking divergence is to modify the \tylab{Rec} to inject
|
|
some primitive operation into the effect row.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*[Lab=$\tylab{Rec}^\ast$]
|
|
{\typ{\Delta;\Gamma,f : A \to B\eff\{\dec{Div}:\ZeroType\}, x : A}{M : B\eff\{\dec{Div}:\ZeroType\}}}
|
|
{\typ{\Delta;\Gamma}{(\Rec \; f^{A \to B\eff\{\dec{Div}:\ZeroType\}} \, x .M) : A \to B\eff\{\dec{Div}:\ZeroType\}}}
|
|
\end{mathpar}
|
|
%
|
|
In this typing rule we have chosen to inject an operation named
|
|
$\dec{Div}$ into the effect row of the computation type on the
|
|
recursive binder $f$. The operation is primitive, because it can never
|
|
be directly invoked, rather, it occurs as a side-effect of applying a
|
|
$\Rec$-definition.
|
|
%
|
|
Using this typing rule we get that
|
|
$\dec{fac} : \Int \to \Int \eff \{\dec{Div}:\ZeroType\}$. Consequently,
|
|
every application-site of $\dec{fac}$ must now permit the $\dec{Div}$
|
|
operation in order to type check.
|
|
%
|
|
\begin{example}
|
|
We will use the following suspended computation to demonstrate
|
|
effect tracking in action.
|
|
%
|
|
\[
|
|
\bl
|
|
\lambda\Unit. \dec{fac}~3
|
|
\el
|
|
\]
|
|
%
|
|
The computation calculates $3!$ when forced.
|
|
%
|
|
We will now give a typing derivation for this computation to
|
|
illustrate how the application of $\dec{fac}$ causes its effect row
|
|
to be propagated outwards. Let
|
|
$\Gamma = \{\dec{fac} : \Int \to \Int \eff \{\dec{Div}:\ZeroType\}\}$.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*[Right={\tylab{Lam}}]
|
|
{\inferrule*[Right={\tylab{App}}]
|
|
{\typ{\emptyset;\Gamma,\Unit:\Record{}}{\dec{fac} : \Int \to \Int \eff \{\dec{Div}:\ZeroType\}}\\
|
|
\typ{\emptyset;\Gamma,\Unit:\Record{}}{3 : \Int}
|
|
}
|
|
{\typc{\emptyset;\Gamma,\Unit:\Record{}}{\dec{fac}~3 : \Int}{\{\dec{Div}:\ZeroType\}}}
|
|
}
|
|
{\typ{\emptyset;\Gamma}{\lambda\Unit.\dec{fac}~3} : \Unit \to \Int \eff \{\dec{Div}:\ZeroType\}}
|
|
\end{mathpar}
|
|
%
|
|
The information that the computation applies a possibly divergent
|
|
function internally gets reflected externally in its effect
|
|
signature.
|
|
\end{example}
|
|
%
|
|
A possible inconvenience of the current formulation of
|
|
$\tylab{Rec}^\ast$ is that it recursion cannot be mixed with other
|
|
computational effects. The reason being that the effect row on
|
|
$A \to B\eff \{\dec{Div}:\ZeroType\}$ is closed. Thus in a practical
|
|
general-purpose programming language implementation it is likely be
|
|
more convenient to leave the tail of the effect row open as to allow
|
|
recursion to be used in larger effect contexts. The rule formulation
|
|
is also rather coarse as it renders every $\Rec$-definition as
|
|
possibly divergent -- even definitions that are obviously
|
|
non-divergent such as the $\Rec$-variation of the identity function:
|
|
$\Rec\;f\,x.x$. A practical implementation could utilise a static
|
|
termination checker~\cite{Walther94} to obtain more fine-grained
|
|
tracking of divergence.
|
|
% By fairly lightweight means we can obtain a finer analysis of
|
|
% $\Rec$-definitions by simply having an additional typing rule for
|
|
% the application of $\Rec$.
|
|
% %
|
|
% \begin{mathpar}
|
|
% \inferrule*[lab=$\tylab{AppRec}^\ast$]
|
|
% { E' = \{\dec{Div}:\ZeroType\} \uplus E\\
|
|
% \typ{\Delta}{E'}\\\\
|
|
% \typ{\Delta;\Gamma}{\Rec\;f^{A \to B \eff E}\,x.M : A \to B \eff E}\\
|
|
% \typ{\Delta;\Gamma}{W : A}
|
|
% }
|
|
% {\typ{\Delta;\Gamma}{(\Rec\;f^{A \to B \eff E}\,x.M)\,W : B \eff E'}}
|
|
% \end{mathpar}
|
|
% %
|
|
|
|
\subsection{Notions of purity}
|
|
\label{sec:notions-of-purity}
|
|
The term `pure' is heavily overloaded in the programming literature.
|
|
%
|
|
\dhil{In this thesis we use the Haskell notion of purity.}
|
|
|
|
\section{Row polymorphism}
|
|
\label{sec:row-polymorphism}
|
|
\dhil{A discussion of alternative row systems}
|
|
|
|
% \section{Type and effect inference}
|
|
% \dhil{While I would like to detail the type and effect inference, it
|
|
% may not be worth the effort. The reason I would like to do this goes
|
|
% back to 2016 when Richard Eisenberg asked me about how we do effect
|
|
% inference in Links.}
|
|
|
|
\chapter{Programming with control via effect handlers}
|
|
\label{ch:unary-handlers}
|
|
%
|
|
Programming with effect handlers is a dichotomy of \emph{performing}
|
|
and \emph{handling} of effectful operations --- or alternatively a
|
|
dichotomy of \emph{constructing} and \emph{deconstructing} effects. An
|
|
operation is a constructor of an effect. By itself an operation has no
|
|
predefined semantics. A handler deconstructs an effect by
|
|
pattern-matching on its operations. By matching on a particular
|
|
operation, a handler instantiates the operation with a particular
|
|
semantics of its own choosing. The key ingredient to make this work in
|
|
practice is \emph{delimited control}. Performing an operation reifies
|
|
the remainder of the computation up to the nearest enclosing handler
|
|
of the operation as a continuation. This continuation is exposed to
|
|
the programmer via the handler as a first-class value, and thus, it
|
|
may be invoked, discarded, or stored for later use at the discretion
|
|
of the programmer.
|
|
|
|
Effect handlers provide a structured and modular interface for
|
|
programming with delimited control. They are structured in the sense
|
|
that the invocation site of an operation is decoupled from the use
|
|
site of its continuation. A handler consists of a collection of
|
|
operation clauses, one for each operation it handles. Effect handlers
|
|
are modular as a handler will only capture and expose continuations
|
|
for operations that it handles, other operation invocations pass
|
|
seamlessly through the handler such that the operation can be handled
|
|
by another suitable handler. This allows modular construction of
|
|
effectful programs, where multiple handlers can be composed to fully
|
|
interpret the effect signature of the whole program.
|
|
|
|
% There exists multiple flavours of effect handlers. The handlers
|
|
% introduced by \citet{PlotkinP09} are known as \emph{deep} handlers,
|
|
% and they are semantically defined as folds over computation
|
|
% trees. Dually, \emph{shallow} handlers are defined as case-splits over
|
|
% computation trees.
|
|
%
|
|
The purpose of the chapter is to augment the base calculi \BCalc{} and
|
|
\BCalcRec{} with effect handlers, and demonstrate their practical
|
|
versatility by way of a programming case study. The primary focus is
|
|
on so-called \emph{deep} and \emph{shallow} variants of handlers. In
|
|
Section~\ref{sec:unary-deep-handlers} we endow \BCalc{} with deep
|
|
handlers, which we put to use in
|
|
Section~\ref{sec:deep-handlers-in-action} where we implement a
|
|
\UNIX{}-style operating system. In
|
|
Section~\ref{sec:unary-shallow-handlers} we extend \BCalcRec{} with
|
|
shallow handlers, and subsequently we use them to extend the
|
|
functionality of the operating system example. Finally, in
|
|
Section~\ref{sec:unary-parameterised-handlers} we will look at
|
|
\emph{parameterised} handlers, which are a refinement of ordinary deep
|
|
handlers.
|
|
|
|
From here onwards I will make a slight change of terminology to
|
|
disambiguate programmatic continuations, i.e. continuations exposed to
|
|
the programmer, from continuations in continuation passing style
|
|
(Chapter~\ref{ch:cps}) and continuations in abstract machines
|
|
(Chapter~\ref{ch:abstract-machine}). In the remainder of this
|
|
dissertation I refer to programmatic continuations as `resumptions',
|
|
and reserve the term `continuation' for continuations concerning the
|
|
implementation details.
|
|
|
|
\paragraph{Relation to prior work} The deep and shallow handler
|
|
calculi that are introduced in Section~\ref{sec:unary-deep-handlers},
|
|
Section~\ref{sec:unary-shallow-handlers}, and
|
|
Section~\ref{sec:unary-parameterised-handlers} are adapted with minor
|
|
syntactic changes from the following work.
|
|
%
|
|
\begin{enumerate}[i]
|
|
\item \bibentry{HillerstromL16}
|
|
\item \bibentry{HillerstromL18} \label{en:sec-handlers-L18}
|
|
\item \bibentry{HillerstromLA20} \label{en:sec-handlers-HLA20}
|
|
\end{enumerate}
|
|
%
|
|
The `pipes' example in Section~\ref{sec:unary-shallow-handlers}
|
|
appears in items \ref{en:sec-handlers-L18} and
|
|
\ref{en:sec-handlers-HLA20} above.
|
|
|
|
\section{Deep handlers}
|
|
\label{sec:unary-deep-handlers}
|
|
%
|
|
|
|
As our starting point we take the regular base calculus, \BCalc{},
|
|
without the recursion operator and extend it with deep handlers to
|
|
yield the calculus \HCalc{}. We elect to do so because deep handlers
|
|
do not require the power of an explicit fixpoint operator to be a
|
|
practical programming abstraction. Building \HCalc{} on top of
|
|
\BCalcRec{} require no change in semantics.
|
|
%
|
|
Deep handlers~\cite{PlotkinP09,Pretnar10} are defined by folds
|
|
(specifically \emph{catamorphisms}~\cite{MeijerFP91}) over computation
|
|
trees, meaning they provide a uniform semantics to the handled
|
|
operations of a given computation. In contrast, shallow handlers are
|
|
defined as case-splits over computation trees, and thus, allow a
|
|
nonuniform semantics to be given to operations. We will discuss this
|
|
point in more detail in Section~\ref{sec:unary-shallow-handlers}.
|
|
|
|
|
|
\subsection{Performing effectful operations}
|
|
\label{sec:eff-language-perform}
|
|
|
|
An effectful operation is a purely syntactic construction, which has
|
|
no predefined dynamic semantics. In our calculus effectful operations
|
|
are a computational phenomenon, and thus, their introduction form is a
|
|
computation term. To type operation we augment the syntactic category
|
|
of value types with a new arrow.
|
|
%
|
|
\begin{syntax}
|
|
\slab{Value\textrm{ }types} &A,B \in \ValTypeCat &::=& \cdots \mid A \opto B\\
|
|
\slab{Computations} &M,N \in \CompCat &::=& \cdots \mid (\Do \; \ell~V)^E
|
|
\end{syntax}
|
|
%
|
|
The operation arrow, $\opto$, denotes the operation space. The
|
|
operation space arrow is similar to the function space arrow in that
|
|
the type $A$ denotes the domain type of the operation, i.e. the type
|
|
of the operation payload, and the codomain type $B$ denotes the return
|
|
type of the operation. Contrary to the function space constructor,
|
|
$\to$, the operation space constructor does not have an associated
|
|
effect row. As we will see later, the reason that the operation space
|
|
constructor does not have an effect row is that the effects of an
|
|
operation is conferred by its handler.
|
|
|
|
The intended behaviour of the new computation term $(\Do\; \ell~V)^E$
|
|
is that it performs some operation $\ell$ with value argument
|
|
$V$. Thus the $\Do$-construct is similar to the typical
|
|
exception-signalling $\keyw{throw}$ or $\keyw{raise}$ constructs found
|
|
in programming languages with support for exceptions. In fact
|
|
operationally, an effectful operation may be thought of as an
|
|
exception which is resumable~\cite{Leijen17}. The term is annotated
|
|
with an effect row $E$, providing a way to make the current effect
|
|
context accessible during typing.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*[Lab=\tylab{Do}]
|
|
{ \typ{\Delta}{E} \\
|
|
E = \{\ell : A \opto B; R\} \\
|
|
\typ{\Delta;\Gamma}{V : A}
|
|
}
|
|
{\typc{\Delta;\Gamma}{(\Do \; \ell \; V)^E : B}{E}}
|
|
\end{mathpar}
|
|
%
|
|
An operation invocation is only well-typed if the effect row $E$ is
|
|
well-kinded and mentions the operation with a present type, or put
|
|
differently: the current effect context must permit an instance of the
|
|
operation to occur. The argument type $A$ must be the same as the
|
|
domain type of the operation. The type of the whole term is the
|
|
(value) return type of the operation paired with the current effect
|
|
context.
|
|
|
|
We have the basic machinery for writing effectful programs, albeit we
|
|
cannot evaluate those programs without handlers to ascribe a semantics
|
|
to the operations.
|
|
|
|
% \paragraph{Computation trees} We have the basic machinery for writing
|
|
% effectful programs, albeit we cannot evaluate those programs without
|
|
% handlers to ascribe a semantics to the operations.
|
|
% %
|
|
% For instance consider the signature of computations over some state at
|
|
% type $\beta$.
|
|
% %
|
|
% \[
|
|
% \State~\beta \defas \{\Get : \UnitType \opto \beta; \Put : \beta \opto \UnitType\}
|
|
% \]
|
|
% %
|
|
% \[
|
|
% \bl
|
|
% \dec{condupd} : \Record{\Bool;\beta} \to \beta \eff \State~\beta\\
|
|
% \dec{condupd}~\Record{b;v} \defas
|
|
% \bl
|
|
% \Let\; x \revto \Do\;\Get\,\Unit\;\In\\
|
|
% \If\;b\;\Then\;\;\Do\;\Put~v;\,x\;
|
|
% \Else\;x
|
|
% \el
|
|
% \el
|
|
% \]
|
|
% %
|
|
|
|
% This exact notation is due to \citet{Lindley14}, though the idea of
|
|
% using computation trees dates back to at least
|
|
% \citet{Kleene59,Kleene63}.
|
|
|
|
% \dhil{Introduce notation for computation trees.}
|
|
|
|
\subsection{Handling of effectful operations}
|
|
%
|
|
The elimination form for an effectful operation is an effect
|
|
handler. Effect handlers interpret the effectful segments of a
|
|
program.
|
|
%
|
|
The addition of handlers requires us to extend the type algebra of
|
|
$\BCalc$ with a kind for handlers and a new syntactic category for
|
|
handler types.
|
|
%
|
|
\begin{syntax}
|
|
\slab{Kinds} &K \in \KindCat &::=& \cdots \mid \Handler\\
|
|
\slab{Handler\textrm{ }types} &F \in \HandlerTypeCat &::=& C \Harrow D\\
|
|
\slab{Types} &T \in \TypeCat &::=& \cdots \mid F
|
|
\end{syntax}
|
|
%
|
|
The syntactic category of kinds is augmented with the kind $\Handler$
|
|
which we will ascribe to handler types $F$. The arrow, $\Harrow$,
|
|
denotes the handler space. The type structure suggests that a handler
|
|
is a transformer of computations, since by looking solely at the types
|
|
a handler takes a computation of type $C$ and returns another
|
|
computation of type $D$. As such, we may think of a handler as a sort
|
|
of generalised function, that work over computations rather than bare
|
|
values (this observation is exploited in the \Frank{} programming
|
|
language, where a function is but a special case of a
|
|
handler~\cite{LindleyMM17,ConventLMM20}).
|
|
%
|
|
The following kinding rule checks whether a handler type is
|
|
well-kinded.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*[Lab=\klab{Handler}]
|
|
{ \Delta \vdash C : \Comp \\
|
|
\Delta \vdash D : \Comp
|
|
}
|
|
{\Delta \vdash C \Harrow D : \Handler}
|
|
\end{mathpar}
|
|
%
|
|
With the type structure in place, we can move on to the term syntax
|
|
for handlers. Handlers extend the syntactic category of computations
|
|
with a new computation form as well as introducing a new syntactic
|
|
category of handler definitions.
|
|
%
|
|
\begin{syntax}
|
|
\slab{Computations} &M,N \in \CompCat &::=& \cdots \mid \Handle \; M \; \With \; H\\[1ex]
|
|
\slab{Handlers} &H \in \HandlerCat &::=& \{ \Return \; x \mapsto M \}
|
|
\mid \{ \OpCase{\ell}{p}{r} \mapsto N \} \uplus H\\
|
|
\slab{Terms} &t \in \TermCat &::=& \cdots \mid H
|
|
\end{syntax}
|
|
%
|
|
The handle construct $(\Handle \; M \; \With \; H)$ is the counterpart
|
|
to $\Do$. It runs computation $M$ using handler $H$. A handler $H$
|
|
consists of a return clause $\{\Return \; x \mapsto M\}$ and a
|
|
possibly empty set of operation clauses
|
|
$\{\OpCase{\ell}{p_\ell}{r_\ell} \mapsto N_\ell\}_{\ell \in \mathcal{L}}$.
|
|
%
|
|
The return clause $\{\Return \; x \mapsto M\}$ defines how to
|
|
interpret the final return value of a handled computation, i.e. a
|
|
computation that has been fully reduced to $\Return~V$ for some value
|
|
$V$. The variable $x$ is bound to the final return value in the body
|
|
$M$.
|
|
%
|
|
Each operation clause
|
|
$\{\OpCase{\ell}{p_\ell}{r_\ell} \mapsto N_\ell\}_{\ell \in
|
|
\mathcal{L}}$ defines how to interpret an invocation of some
|
|
operation $\ell$. The variables $p_\ell$ and $r_\ell$ are bound in the
|
|
body $N_\ell$. The binding occurrence $p_\ell$ binds the payload of
|
|
the operation and $r_\ell$ binds the resumption of the operation
|
|
invocation, which is the delimited continuation from the invocation
|
|
site up of $\ell$ to and including the enclosing handler.
|
|
|
|
Given a handler $H$, we often wish to refer to the clause for a
|
|
particular operation or the return clause; for these purposes we
|
|
define two convenient projections on handlers in the metalanguage.
|
|
\[
|
|
\ba{@{~}r@{~}c@{~}l@{~}l}
|
|
\hell &\defas& \{\OpCase{\ell}{p}{r} \mapsto N \}, &\quad \text{where } \{\OpCase{\ell}{p}{r} \mapsto N \} \in H\\
|
|
\hret &\defas& \{\Return\; x \mapsto N \}, &\quad \text{where } \{\Return\; x \mapsto N \} \in H\\
|
|
\ea
|
|
\]
|
|
%
|
|
The $\hell$ projection yields the singleton set consisting of the
|
|
operation clause in $H$ that handles the operation $\ell$, whilst
|
|
$\hret$ yields the singleton set containing the return clause of $H$.
|
|
%
|
|
We define the \emph{domain} of an handler as the set of operation
|
|
labels it handles, i.e.
|
|
%
|
|
\begin{equations}
|
|
\dom &:& \HandlerCat \to \LabelCat\\
|
|
\dom(\{\Return\;x \mapsto M\}) &\defas& \emptyset\\
|
|
\dom(\{\OpCase{\ell}{p}{r} \mapsto M\} \uplus H) &\defas& \{\ell\} \cup \dom(H)
|
|
\end{equations}
|
|
|
|
\subsection{Static semantics}
|
|
|
|
There are two typing rules for handlers. The first rule type checks
|
|
the $\Handle$-construct and the second rule type checks handler
|
|
definitions.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*[Lab=\tylab{Handle}]
|
|
{
|
|
\typ{\Gamma}{M : C} \\
|
|
\typ{\Gamma}{H : C \Harrow D}
|
|
}
|
|
{\Gamma \vdash \Handle \; M \; \With\; H : D}
|
|
|
|
|
|
%\mprset{flushleft}
|
|
\inferrule*[Lab=\tylab{Handler}]
|
|
{{\bl
|
|
C = A \eff \{(\ell_i : A_i \opto B_i)_i; R\} \\
|
|
D = B \eff \{(\ell_i : P_i)_i; R\}\\
|
|
H = \{\Return\;x \mapsto M\} \uplus \{ \OpCase{\ell_i}{p_i}{r_i} \mapsto N_i \}_i
|
|
\el}\\\\
|
|
\typ{\Delta;\Gamma, x : A}{M : D}\\\\
|
|
[\typ{\Delta;\Gamma,p_i : A_i, r_i : B_i \to D}{N_i : D}]_i
|
|
}
|
|
{\typ{\Delta;\Gamma}{H : C \Harrow D}}
|
|
\end{mathpar}
|
|
%
|
|
The \tylab{Handle} rule is simply the application rule for handlers.
|
|
%
|
|
The \tylab{Handler} rule is where most of the work happens. The effect
|
|
rows on the input computation type $C$ and the output computation type
|
|
$D$ must mention every operation in the domain of the handler. In the
|
|
output row those operations may be either present ($\Pre{A}$), absent
|
|
($\Abs$), or polymorphic in their presence ($\theta$), whilst in the
|
|
input row they must be mentioned with a present type as those types
|
|
are used to type operation clauses.
|
|
%
|
|
In each operation clause the resumption $r_i$ must have the same
|
|
return type, $D$, as its handler. In the return clause the binder $x$
|
|
has the same type, $C$, as the result of the input computation.
|
|
|
|
|
|
\subsection{Dynamic semantics}
|
|
|
|
We augment the operational semantics with two new reduction rules: one
|
|
for handling return values and another for handling operations.
|
|
%{\small{
|
|
\begin{reductions}
|
|
\semlab{Ret} &
|
|
\Handle \; (\Return \; V) \; \With \; H &\reducesto& N[V/x], \hfill\text{where } \hret = \{ \Return \; x \mapsto N \} \\
|
|
\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@{}}{
|
|
\hfill\ba[t]{@{~}r@{~}l}
|
|
\text{where}& \hell = \{ \OpCase{\ell}{p}{r} \mapsto N \}\\
|
|
\text{and} & \ell \notin \BL(\EC)
|
|
\ea
|
|
}
|
|
\end{reductions}%}}%
|
|
%
|
|
The rule \semlab{Ret} invokes the return clause of the current handler
|
|
$H$ and substitutes $V$ for $x$ in the body $N$.
|
|
%
|
|
The rule \semlab{Op} handles an operation $\ell$ subject to two
|
|
conditions. The first condition ensures that the operation is only
|
|
captured by a handler if its handler definition $H$ contains a
|
|
corresponding operation clause for the operation. Otherwise the
|
|
operation passes seamlessly through the handler such that another
|
|
suitable handler can handle the operation. This phenomenon is known as
|
|
\emph{effect forwarding}. It is key to enable modular composition of
|
|
effectful computations.
|
|
%
|
|
The second condition ensures the operation $\ell$ and that the
|
|
operation does not appear in the \emph{bound labels} ($\BL$) of the
|
|
inner context $\EC$. The bound label condition enforces that an
|
|
operation is always handled by the nearest enclosing suitable handler.
|
|
%
|
|
Formally, we define the notion of bound labels,
|
|
$\BL : \EvalCat \to \LabelCat$, inductively over the structure of
|
|
evaluation contexts.
|
|
%
|
|
\begin{equations}
|
|
\BL([~]) &=& \emptyset \\
|
|
\BL(\Let\;x \revto \EC\;\In\;N) &=& \BL(\EC) \\
|
|
\BL(\Handle\;\EC\;\With\;H) &=& \BL(\EC) \cup \dom(H) \\
|
|
\end{equations}
|
|
%
|
|
To illustrate the necessity of this condition consider the following
|
|
example with two nested handlers which both handle the same operation
|
|
$\ell$.
|
|
%
|
|
\[
|
|
\bl
|
|
\ba{@{~}r@{~}c@{~}l}
|
|
H_{\mathsf{inner}} &\defas& \{\OpCase{\ell}{p}{r} \mapsto r~42; \Return\;x \mapsto \Return~x\}\\
|
|
H_{\mathsf{outer}} &\defas& \{\OpCase{\ell}{p}{r} \mapsto r~0;\Return\;x \mapsto \Return~x \}
|
|
\ea\medskip\\
|
|
\Handle \;
|
|
\left(\Handle\; \Do\;\ell~\Record{}\;\With\; H_{\mathsf{inner}}\right)\;
|
|
\With\; H_{\mathsf{outer}}
|
|
\reducesto^+ \begin{cases}
|
|
\Return\;42 & \text{Innermost}\\
|
|
\Return\;0 & \text{Outermost}
|
|
\end{cases}
|
|
\el
|
|
\]
|
|
%
|
|
Without the bound label condition there are two possible results as
|
|
the choice of which handler to pick for $\ell$ is ambiguous, meaning
|
|
reduction would be nondeterministic. Conversely, with the bound label
|
|
condition we obtain that the above term reduces to $\Return\;42$,
|
|
because $\ell$ is bound in the computation term of the outermost
|
|
$\Handle$.
|
|
%
|
|
|
|
The decision to always select the nearest enclosing suitable handler
|
|
for an operation invocation is a conscious choice. In fact, it is the
|
|
\emph{only} natural and sensible choice as picking any other handler
|
|
than the nearest enclosing renders programming with effect handlers
|
|
anti-modular. Consider the other extreme of always selecting the
|
|
outermost suitable handler, then the meaning of any effectful program
|
|
fragment depends on the entire ambient context. For example, consider
|
|
using integer addition as the composition operator to compose the
|
|
inner handle expression from above with a copy of itself.
|
|
%
|
|
\[
|
|
\bl
|
|
\dec{fortytwo} \defas \Handle\;\Do\;\ell~\Unit\;\With\;H_{\mathsf{inner}} \medskip\\
|
|
\EC[\dec{fortytwo} + \dec{fortytwo}] \reducesto^+ \begin{cases}
|
|
\Return\; 84 & \text{when $\EC$ is empty}\\
|
|
? & \text{otherwise}
|
|
\end{cases}
|
|
\el
|
|
\]
|
|
%
|
|
Clearly, if the ambient context $\EC$ is empty, then we can derive the
|
|
result by reasoning locally about each constituent separately and
|
|
subsequently add their results together to obtain the computation term
|
|
$\Return\;84$. Conversely, if the ambient context is nonempty, then we
|
|
need to account for the possibility that some handler for $\ell$ is
|
|
could be present in the context. For instance if
|
|
$\EC = \Handle\;[~]\;\With\;H_{\mathsf{outer}}$ then the result would
|
|
be $\Return\;0$, which we cannot derive locally from looking at the
|
|
immediate constituents. Thus we can argue that if we want programming
|
|
to remain modular and compositional, then we must necessarily always
|
|
select the nearest enclosing suitable handler for an operation.
|
|
%
|
|
|
|
The resumption $r$ includes both the captured evaluation context and
|
|
the handler. Invoking the resumption causes the both the evaluation
|
|
context and handler to be reinstalled, meaning subsequent invocations
|
|
of $\ell$ get handled by the same handler. This is a defining
|
|
characteristic of deep handlers.
|
|
|
|
The metatheoretic properties of $\BCalc$ transfer to $\HCalc$ with
|
|
little extra effort, although we must amend the definition of
|
|
computation normal forms as there are now two ways in which a
|
|
computation term can terminate: successfully returning a value or
|
|
getting stuck on an unhandled operation.
|
|
%
|
|
\begin{definition}[Computation normal forms]
|
|
We say that a computation term $N$ is normal with respect to an
|
|
effect signature $E$, if $N$ is either of the form $\Return\;V$, or
|
|
$\EC[\Do\;\ell\,W]$ where $\ell \in E$ and $\ell \notin \BL(\EC)$.
|
|
\end{definition}
|
|
%
|
|
|
|
\begin{theorem}[Progress]
|
|
Suppose $\typ{}{M : C}$, then either there exists $\typ{}{N : C}$
|
|
such that $M \reducesto^+ N$ and $N$ is normal, or $M$ diverges.
|
|
\end{theorem}
|
|
|
|
%
|
|
\begin{theorem}[Preservation]
|
|
Suppose $\typ{\Gamma}{M : C}$ and $M \reducesto M'$, then
|
|
$\typ{\Gamma}{M' : C}$.
|
|
\end{theorem}
|
|
|
|
\section{Composing \UNIX{} with effect handlers}
|
|
\label{sec:deep-handlers-in-action}
|
|
|
|
There are several analogies for effect handlers, e.g. as interpreters
|
|
for effects, folds over computation trees, etc. A particularly
|
|
compelling programmatic analogy for effect handlers is \emph{effect
|
|
handlers as composable operating systems}. Effect handlers and
|
|
operating systems share operational characteristics: an operating
|
|
system interprets a set of system commands performed via system calls,
|
|
which is similar to how an effect handler interprets a set of abstract
|
|
operations performed via operation invocations. This analogy was
|
|
suggested to me by James McKinna (personal communication, 2017).
|
|
%
|
|
The compelling aspect of this analogy is that we can understand a
|
|
monolithic and complex operating system like \UNIX{}~\cite{RitchieT74}
|
|
as a collection of effect handlers, or alternatively, a collection of
|
|
tiny operating systems, that when composed yield a semantics for
|
|
\UNIX{}.
|
|
|
|
In this section we will take this reading of effect handlers
|
|
literally, and demonstrate how we can harness the power of (deep)
|
|
effect handlers to implement a \UNIX{}-style operating system with
|
|
multiple user sessions, time-sharing, and file i/o. We dub the system
|
|
\OSname{}.
|
|
%
|
|
It is a case study that demonstrates the versatility of effect
|
|
handlers, and shows how standard computational effects such as
|
|
\emph{exceptions}, \emph{dynamic binding}, \emph{nondeterminism}, and
|
|
\emph{state} make up the essence of an operating system.
|
|
|
|
For the sake of clarity, we will occasionally make some blatant
|
|
simplifications, nevertheless the resulting implementation will
|
|
capture the essence of a \UNIX{}-like operating system.
|
|
%
|
|
The implementation will be composed of several small modular effect
|
|
handlers, that each handles a particular set of system commands. In
|
|
this respect, we will truly realise \OSname{} in the spirit of the
|
|
\UNIX{} philosophy~\cite[Section~1.6]{Raymond03}.
|
|
|
|
% This case study demonstrates that we can decompose a monolithic
|
|
% operating system like \UNIX{} into a collection of specialised effect
|
|
% handlers. Each handler interprets a particular system command.
|
|
|
|
% A systems software engineering reading of effect handlers may be to
|
|
% understand them as modular ``tiny operating systems''. Operationally,
|
|
% how an \emph{operating system} interprets a set of \emph{system
|
|
% commands} performed via \emph{system calls} is similar to how an
|
|
% effect handler interprets a set of abstract operations performed via
|
|
% operation invocations.
|
|
% %
|
|
% This reading was suggested to me by James McKinna (personal
|
|
% communication). In this section I will take this reading literally,
|
|
% and demonstrate how we can use the power of (deep) effect handlers to
|
|
% implement a tiny operating system that supports multiple users,
|
|
% time-sharing, and file i/o.
|
|
% %
|
|
% The operating system will be a variation of \UNIX{}~\cite{RitchieT74},
|
|
% which we will call \OSname{}.
|
|
% %
|
|
% To make the task tractable we will occasionally jump some hops and
|
|
% make some simplifying assumptions, nevertheless the resulting
|
|
% implementation will capture the essence of a \UNIX{}-like operating
|
|
% system.
|
|
% %
|
|
% The implementation will be composed of several small modular effect
|
|
% handlers, that each handles a particular set of system commands. In
|
|
% this respect, we will truly realise \OSname{} in the spirit of the
|
|
% \UNIX{} philosophy~\cite[Section~1.6]{Raymond03}. The implementation of
|
|
% the operating system will showcase several computational effects in
|
|
% action including \emph{dynamic binding}, \emph{nondeterminism}, and
|
|
% \emph{state}.
|
|
|
|
\subsection{Basic i/o}
|
|
\label{sec:tiny-unix-bio}
|
|
|
|
The file system is a cornerstone of \UNIX{} as the notion of \emph{file}
|
|
in \UNIX{} provides a unified abstraction for storing text, interprocess
|
|
communication, and access to devices such as terminals, printers,
|
|
network, etc.
|
|
%
|
|
Initially, we shall take a rather basic view of the file system. In
|
|
fact, our initial system will only contain a single file, and
|
|
moreover, the system will only support writing operations. This system
|
|
hardly qualifies as a \UNIX{} file system. Nevertheless, it serves a
|
|
crucial role for development of \OSname{}, because it provides the
|
|
only means for us to be able to observe the effects of processes.
|
|
%
|
|
We defer development of a more advanced file system to
|
|
Section~\ref{sec:tiny-unix-io}.
|
|
|
|
Much like \UNIX{} we shall model a file as a list of characters, that is
|
|
$\UFile \defas \List~\Char$. For convenience we will use the same
|
|
model for strings, $\String \defas \List~\Char$, such that we can use
|
|
string literal notation to denote the $\strlit{contents of a file}$.
|
|
%
|
|
The signature of the basic file system will consist of a single
|
|
operation $\Write$ for writing a list of characters to the file.
|
|
%
|
|
\[
|
|
\BIO \defas \{\Write : \Record{\UFD;\String} \opto \UnitType\}
|
|
\]
|
|
%
|
|
The operation is parameterised by a $\UFD$ and a character
|
|
sequence. We will leave the $\UFD$ type abstract until
|
|
Section~\ref{sec:tiny-unix-io}, however, we shall assume the existence
|
|
of a term $\stdout : \UFD$ such that we can perform invocations of
|
|
$\Write$.
|
|
%
|
|
Let us define a suitable handler for this operation.
|
|
%
|
|
\[
|
|
\bl
|
|
\basicIO : (\UnitType \to \alpha \eff \BIO) \to \Record{\alpha; \UFile}\\
|
|
\basicIO~m \defas
|
|
\ba[t]{@{~}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& \Record{res;\nil}\\
|
|
\OpCase{\Write}{\Record{\_;cs}}{resume} &\mapsto&
|
|
\ba[t]{@{}l}
|
|
\Let\; \Record{res;file} = resume\,\Unit\;\In\\
|
|
\Record{res; cs \concat file}
|
|
\ea
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The handler takes as input a computation that produces some value
|
|
$\alpha$, and in doing so may perform the $\BIO$ effect.
|
|
%
|
|
The handler ultimately returns a pair consisting of the return value
|
|
$\alpha$ and the final state of the file.
|
|
%
|
|
The $\Return$-case pairs the result $res$ with the empty file $\nil$
|
|
which models the scenario where the computation $m$ performed no
|
|
$\Write$-operations, e.g.
|
|
$\basicIO\,(\lambda\Unit.\Unit) \reducesto^+
|
|
\Record{\Unit;\strlit{}}$.
|
|
%
|
|
The $\Write$-case extends the file by first invoking the resumption,
|
|
whose return type is the same as the handler's return type, thus it
|
|
returns a pair containing the result of $m$ and the file state. The
|
|
file gets extended with the character sequence $cs$ before it is
|
|
returned along with the original result of $m$.
|
|
%
|
|
Intuitively, we may think of this implementation of $\Write$ as a
|
|
peculiar instance of buffered writing, where the contents of the
|
|
operation are committed to the file in last-in-first-out order,
|
|
i.e. the contents of the last write will be committed first.
|
|
|
|
Let us define an auxiliary function that writes a string to the
|
|
$\stdout$ file.
|
|
%
|
|
\[
|
|
\bl
|
|
\echo : \String \to \UnitType \eff\, \BIO\\%\{\Write : \Record{\UFD;\String} \opto \UnitType\}\\
|
|
\echo~cs \defas \Do\;\Write\,\Record{\stdout;cs}
|
|
\el
|
|
\]
|
|
%
|
|
The function $\echo$ is a simple wrapper around an invocation of
|
|
$\Write$.
|
|
%
|
|
We can now write some contents to the file and observe the effects.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\basicIO\,(\lambda\Unit. \echo~\strlit{Hello}; \echo~\strlit{World})\\
|
|
\reducesto^+& \Record{\Unit;\strlit{HelloWorld}} : \Record{\UnitType;\UFile}
|
|
\ea
|
|
\]
|
|
|
|
\subsection{Exceptions: non-local exits}
|
|
\label{sec:tiny-unix-exit}
|
|
|
|
A process may terminate successfully by running to completion, or it
|
|
may terminate with success or failure in the middle of some
|
|
computation by performing an \emph{exit} system call. The exit system
|
|
call is typically parameterised by an integer value intended to
|
|
indicate whether the exit was due to success or failure. By
|
|
convention, \UNIX{} interprets the integer zero as success and any
|
|
nonzero integer as failure, where the specific value is supposed to
|
|
correspond to some known error code.
|
|
%
|
|
|
|
We can model the exit system call by way of a single operation
|
|
$\Exit$.
|
|
%
|
|
\[
|
|
\Status \defas \{\Exit : \Int \opto \ZeroType\}
|
|
\]
|
|
%
|
|
The operation is parameterised by an integer value, however, an
|
|
invocation of $\Exit$ can never return, because the type $\ZeroType$ is
|
|
uninhabited. Thus $\Exit$ acts like an exception.
|
|
%
|
|
It is convenient to abstract invocations of $\Exit$ to make it
|
|
possible to invoke the operation in any context.
|
|
%
|
|
\[
|
|
\bl
|
|
\exit : \Int \to \alpha \eff \Status\\
|
|
\exit~n \defas \Absurd\;(\Do\;\Exit~n)
|
|
\el
|
|
\]
|
|
%
|
|
The $\Absurd$ computation term is used to coerce the return type
|
|
$\ZeroType$ of $\Fail$ into $\alpha$. This coercion is safe, because
|
|
$\ZeroType$ is an uninhabited type.
|
|
%
|
|
An interpretation of $\Exit$ amounts to implementing an exception
|
|
handler.
|
|
%
|
|
\[
|
|
\bl
|
|
\status : (\UnitType \to \alpha \eff \Status) \to \Int\\
|
|
\status~m \defas
|
|
\ba[t]{@{~}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;\_ &\mapsto& 0\\
|
|
\ExnCase{\Exit}{n} &\mapsto& n
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
Following the \UNIX{} convention, the $\Return$-case interprets a
|
|
successful completion of $m$ as the integer $0$. The operation case
|
|
returns whatever payload the $\Exit$ operation was carrying. As a
|
|
consequence, outside of $\status$, an invocation of $\Exit~0$ in $m$
|
|
is indistinguishable from $m$ returning normally, e.g.
|
|
$\status\,(\lambda\Unit.\exit~0) = \status\,(\lambda\Unit.\Unit)$.
|
|
|
|
To illustrate $\status$ and $\exit$ in action consider the following
|
|
example, where the computation gets terminated mid-way.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\bl
|
|
\basicIO\,(\lambda\Unit.
|
|
\status\,(\lambda\Unit.
|
|
\echo~\strlit{dead};\exit~1;\echo~\strlit{code}))
|
|
\el\\
|
|
\reducesto^+& \Record{1;\strlit{dead}} : \Record{\Int;\UFile}
|
|
\ea
|
|
\]
|
|
%
|
|
The (delimited) continuation of $\exit~1$ is effectively dead code.
|
|
|
|
\subsection{Dynamic binding: user-specific environments}
|
|
\label{sec:tiny-unix-env}
|
|
|
|
When a process is run in \UNIX{}, the operating system makes available
|
|
to the process a collection of name-value pairs called the
|
|
\emph{environment}.
|
|
%
|
|
The name of a name-value pair is known as an \emph{environment
|
|
variable}.
|
|
%
|
|
During execution the process may perform a system call to ask the
|
|
operating system for the value of some environment variable.
|
|
%
|
|
The value of environment variables may change throughout process
|
|
execution, moreover, the value of some environment variables may vary
|
|
according to which user asks the environment.
|
|
%
|
|
For example, an environment may contain the environment variable
|
|
\texttt{USER} that is bound to the name of the inquiring user.
|
|
|
|
An environment variable can be viewed as an instance of dynamic
|
|
binding. The idea of dynamic binding as a binding form in programming
|
|
dates back as far as the original implementation of
|
|
Lisp~\cite{McCarthy60}, and still remains an integral feature in
|
|
successors such as Emacs Lisp~\cite{LewisLSG20}. It is well-known that
|
|
dynamic binding can be encoded as a computational effect by using
|
|
delimited control~\cite{KiselyovSS06}.
|
|
%
|
|
Unsurprisingly, we will use this insight to simulate user-specific
|
|
environments using effect handlers.
|
|
|
|
For simplicity we fix the users of the operating system to be root,
|
|
Alice, and Bob.
|
|
%
|
|
\[
|
|
\User \defas [\Alice;\Bob;\Root]
|
|
\]
|
|
|
|
Our environment will only support a single environment variable
|
|
intended to store the name of the current user. The value of this
|
|
variable can be accessed via an operation $\Ask : \UnitType \opto \String$.
|
|
%
|
|
% \[
|
|
% \EnvE \defas \{\Ask : \UnitType \opto \String\}
|
|
% \]
|
|
%
|
|
Using this operation we can readily implement the \emph{whoami}
|
|
utility from the GNU coreutils~\cite[Section~20.3]{MacKenzieMPPBYS20},
|
|
which returns the name of the current user.
|
|
%
|
|
\[
|
|
\bl
|
|
\whoami : \UnitType \to \String \eff \{\Ask : \UnitType \opto \String\}\\
|
|
\whoami~\Unit \defas \Do\;\Ask~\Unit
|
|
\el
|
|
\]
|
|
%
|
|
The following handler implements the environment.
|
|
%
|
|
\[
|
|
\bl
|
|
\environment : \Record{\User;\UnitType \to \alpha \eff \{\Ask : \UnitType \opto \String\}} \to \alpha\\
|
|
\environment~\Record{user;m} \defas
|
|
\ba[t]{@{~}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& res\\
|
|
\OpCase{\Ask}{\Unit}{resume} &\mapsto&
|
|
\bl
|
|
\Case\;user\,\{
|
|
\ba[t]{@{}l@{~}c@{~}l}
|
|
\Alice &\mapsto& resume~\strlit{alice}\\
|
|
\Bob &\mapsto& resume~\strlit{bob}\\
|
|
\Root &\mapsto& resume~\strlit{root}\}
|
|
\ea
|
|
\el
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The handler takes as input the current $user$ and a computation that
|
|
may perform the $\Ask$ operation. When an invocation of $\Ask$ occurs
|
|
the handler pattern matches on the $user$ parameter and resumes with a
|
|
string representation of the user. With this implementation we can
|
|
interpret an application of $\whoami$.
|
|
%
|
|
\[
|
|
\environment~\Record{\Root;\whoami} \reducesto^+ \strlit{root} : \String
|
|
\]
|
|
%
|
|
It is not difficult to extend this basic environment model to support
|
|
an arbitrary number of variables. This can be done by parameterising
|
|
the $\Ask$ operation by some name representation (e.g. a string),
|
|
which the environment handler can use to index into a list of string
|
|
values. In case the name is unbound the environment, the handler can
|
|
embrace the laissez-faire attitude of \UNIX{} and resume with the
|
|
empty string.
|
|
|
|
\paragraph{User session management}
|
|
%
|
|
It is somewhat pointless to have multiple user-specific environments,
|
|
if the system does not support some mechanism for user session
|
|
handling, such as signing in as a different user.
|
|
%
|
|
In \UNIX{} the command \emph{substitute user} (su) enables the invoker
|
|
to impersonate another user account, provided the invoker has
|
|
sufficient privileges.
|
|
%
|
|
We will implement su as an operation $\Su : \User \opto \UnitType$
|
|
which is parameterised by the user to be impersonated.
|
|
%
|
|
To model the security aspects of su, we will use the weakest possible
|
|
security model: unconditional trust. Put differently, we will not
|
|
bother with security at all to keep things relatively simple.
|
|
%
|
|
Consequently, anyone can impersonate anyone else.
|
|
|
|
The session signature consists of two operations, $\Ask$, which we
|
|
used above, and $\Su$, for switching user.
|
|
%
|
|
\[
|
|
\EnvE \defas \{\Ask : \UnitType \opto \String;\Su : \User \opto \UnitType\}
|
|
\]
|
|
%
|
|
As usual, we define a small wrapper around invocations of $\Su$.
|
|
%
|
|
\[
|
|
\bl
|
|
\su : \User \to \UnitType \eff \{\Su : \User \opto \UnitType\}\\
|
|
\su~user \defas \Do\;\Su~user
|
|
\el
|
|
\]
|
|
%
|
|
|
|
The intended operational behaviour of an invocation of $\Su~user$ is
|
|
to load the environment belonging to $user$ and continue the
|
|
continuation under this environment.
|
|
%
|
|
We can achieve this behaviour by defining a handler for $\Su$ that
|
|
invokes the provided resumption under a fresh instance of the
|
|
$\environment$ handler.
|
|
%
|
|
\[
|
|
\bl
|
|
\sessionmgr : \Record{\User; \UnitType \to \alpha \eff \EnvE} \to \alpha\\
|
|
\sessionmgr\,\Record{user;m} \defas
|
|
\environment\langle{}user;(\lambda\Unit.
|
|
\ba[t]{@{}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& res\\
|
|
\OpCase{\Su}{user'}{resume} &\mapsto& \environment\Record{user';resume})\rangle
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The function $\sessionmgr$ manages a user session. It takes two
|
|
arguments: the initial user ($user$) and the computation ($m$) to run
|
|
in the current session. An initial instance of $\environment$ is
|
|
installed with $user$ as argument. The computation argument is a
|
|
handler for $\Su$ enclosing the computation $m$. The $\Su$-case
|
|
installs a new instance of $\environment$, which is the environment
|
|
belonging to $user'$, and runs the resumption $resume$ under this
|
|
instance.
|
|
%
|
|
The new instance of $\environment$ shadows the initial instance, and
|
|
therefore it will intercept and handle any subsequent invocations of
|
|
$\Ask$ arising from running the resumption. A subsequent invocation of
|
|
$\Su$ will install another environment instance, which will shadow
|
|
both the previously installed instance and the initial instance.
|
|
%
|
|
|
|
To make this concrete, let us plug together the all components of our
|
|
system we have defined thus far.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\bl
|
|
\basicIO\,(\lambda\Unit.\\
|
|
\qquad\sessionmgr\,\Record{\Root;\lambda\Unit.\\
|
|
\qquad\qquad\status\,(\lambda\Unit.
|
|
\ba[t]{@{}l@{~}l}
|
|
\su~\Alice;&\echo\,(\whoami\,\Unit);~\echo~\strlit{ };\\
|
|
\su~\Bob; &\echo\,(\whoami\,\Unit);~\echo~\strlit{ };\\
|
|
\su~\Root; &\echo\,(\whoami\,\Unit))})
|
|
\ea
|
|
\el \smallskip\\
|
|
\reducesto^+& \Record{0;\strlit{alice bob root}} : \Record{\Int;\UFile}
|
|
\ea
|
|
\]
|
|
%
|
|
The session manager ($\sessionmgr$) is installed in between the basic
|
|
IO handler ($\basicIO$) and the process status handler
|
|
($\status$). The initial user is $\Root$, and thus the initial
|
|
environment is the environment that belongs to the root user. Main
|
|
computation signs in as $\Alice$ and writes the result of the system
|
|
call $\whoami$ to the global file, and then repeats these steps for
|
|
$\Bob$ and $\Root$.
|
|
%
|
|
Ultimately, the computation terminates successfully (as indicated by
|
|
$0$ in the first component of the result) with global file containing
|
|
the three user names.
|
|
%
|
|
|
|
The above example demonstrates that we now have the basic building
|
|
blocks to build a multi-user system.
|
|
%
|
|
\dhil{Remark on the concrete layering of handlers.}
|
|
|
|
\subsection{Nondeterminism: time sharing}
|
|
\label{sec:tiny-unix-time}
|
|
|
|
Time sharing is a mechanism that enables multiple processes to run
|
|
concurrently, and hence, multiple users to work concurrently.
|
|
%
|
|
Thus far in our system there is exactly one process.
|
|
%
|
|
In \UNIX{} there exists only a single process whilst the system is
|
|
bootstrapping itself into operation. After bootstrapping is complete
|
|
the system duplicates the initial process to start running user
|
|
managed processes, which may duplicate themselves to create further
|
|
processes.
|
|
%
|
|
The process duplication primitive in \UNIX{} is called
|
|
\emph{fork}~\cite{RitchieT74}.
|
|
%
|
|
The fork-invoking process is typically referred to as the parent
|
|
process, whilst its clone is referred to as the child process.
|
|
%
|
|
Following an invocation of fork, the parent process is provided with a
|
|
nonzero identifier for the child process and the child process is
|
|
provided with the zero identifier. This enables processes to determine
|
|
their respective role in the parent-child relationship, e.g.
|
|
%
|
|
\[
|
|
\bl
|
|
\Let\;i\revto fork~\Unit\;\In\\
|
|
\If\;i = 0\;\Then\;
|
|
~\textit{child's code}\\
|
|
\Else\;~\textit{parent's code}
|
|
\el
|
|
\]
|
|
%
|
|
In our system, we can model fork as an effectful operation, that
|
|
returns a boolean to indicate the process role; by convention we will
|
|
interpret the return value $\True$ to mean that the process assumes
|
|
the role of parent.
|
|
%
|
|
\[
|
|
\bl
|
|
\fork : \UnitType \to \Bool \eff \{\Fork : \UnitType \opto \Bool\}\\
|
|
\fork~\Unit \defas \Do\;\Fork~\Unit
|
|
\el
|
|
\]
|
|
%
|
|
In \UNIX{} the parent process \emph{continues} execution after the
|
|
fork point, and the child process \emph{begins} its execution after
|
|
the fork point.
|
|
%
|
|
Thus, operationally, we may understand fork as returning twice to its
|
|
invocation site. We can implement this behaviour by invoking the
|
|
resumption arising from an invocation of $\Fork$ twice: first with
|
|
$\True$ to continue the parent process, and subsequently with $\False$
|
|
to start the child process (or the other way around if we feel
|
|
inclined).
|
|
%
|
|
The following handler implements this behaviour.
|
|
%
|
|
\[
|
|
\bl
|
|
\nondet : (\UnitType \to \alpha \eff \{\Fork:\UnitType \opto \Bool\}) \to \List~\alpha\\
|
|
\nondet~m \defas
|
|
\ba[t]{@{}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& [res]\\
|
|
\OpCase{\Fork}{\Unit}{resume} &\mapsto& resume~\True \concat resume~\False
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The $\Return$-case returns a singleton list containing a result of
|
|
running $m$.
|
|
%
|
|
The $\Fork$-case invokes the provided resumption $resume$ twice. Each
|
|
invocation of $resume$ effectively copies $m$ and runs each copy to
|
|
completion. Each copy returns through the $\Return$-case, hence each
|
|
invocation of $resume$ returns a list of the possible results obtained
|
|
by interpreting $\Fork$ first as $\True$ and subsequently as
|
|
$\False$. The results are joined by list concatenation ($\concat$).
|
|
%
|
|
Thus the handler returns a list of all the possible results of $m$.
|
|
%
|
|
In fact, this handler is exactly the standard handler for
|
|
nondeterministic choice, which satisfies the standard semi-lattice
|
|
equations~\cite{PlotkinP09,PlotkinP13}.
|
|
% \dhil{This is an instance of non-blind backtracking~\cite{FriedmanHK84}}
|
|
|
|
Let us consider $\nondet$ together with the previously defined
|
|
handlers. But first, let us define two computations.
|
|
%
|
|
\[
|
|
\bl
|
|
\quoteRitchie,\;\quoteHamlet : \UnitType \to \UnitType \eff \{\Write: \Record{\UFD;\String} \opto \UnitType\} \smallskip\\
|
|
\quoteRitchie\,\Unit \defas
|
|
\ba[t]{@{~}l}
|
|
\echo~\strlit{UNIX is basically };\\
|
|
\echo~\strlit{a simple operating system, };\\
|
|
\echo~\strlit{but };\\
|
|
\echo~\texttt{"}
|
|
\ba[t]{@{}l}
|
|
\texttt{you have to be a genius }\\
|
|
\texttt{to understand the simplicity.\nl{}"}
|
|
\ea
|
|
\ea \smallskip\\
|
|
\quoteHamlet\,\Unit \defas
|
|
\ba[t]{@{}l}
|
|
\echo~\strlit{To be, or not to be, };\\
|
|
\echo~\strlit{that is the question:\nl};\\
|
|
\echo~\strlit{Whether 'tis nobler in the mind to suffer\nl}
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The computation $\quoteRitchie$ writes a quote by Dennis Ritchie to
|
|
the file, whilst the computation $\quoteHamlet$ writes a few lines of
|
|
William Shakespeare's \emph{The Tragedy of Hamlet, Prince of Denmark},
|
|
Act III, Scene I~\cite{Shakespeare6416} to the file.
|
|
%
|
|
Using $\nondet$ and $\fork$ together with the previously defined
|
|
infrastructure, we can fork the initial process such that both of the
|
|
above computations are run concurrently.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\bl
|
|
\basicIO\,(\lambda\Unit.\\
|
|
\qquad\nondet\,(\lambda\Unit.\\
|
|
\qquad\qquad\sessionmgr\,\Record{\Root;\lambda\Unit.\\
|
|
\qquad\qquad\qquad\status\,(\lambda\Unit.
|
|
\ba[t]{@{}l}
|
|
\If\;\fork~\Unit\;\Then\;
|
|
\su~\Alice;\,
|
|
\quoteRitchie~\Unit\\
|
|
\Else\;
|
|
\su~\Bob;\,
|
|
\quoteHamlet~\Unit)}))
|
|
\ea
|
|
\el \smallskip\\
|
|
\reducesto^+&
|
|
\Record{
|
|
\ba[t]{@{}l}
|
|
[0, 0];
|
|
\texttt{"}\ba[t]{@{}l}
|
|
\texttt{UNIX is basically a simple operating system, but }\\
|
|
\texttt{you have to be a genius to understand the simplicity.\nl}\\
|
|
\texttt{To be, or not to be, that is the question:\nl}\\
|
|
\texttt{Whether 'tis nobler in the mind to suffer\nl"}} : \Record{\List~\Int; \UFile}
|
|
\ea
|
|
\ea
|
|
\ea
|
|
\]
|
|
%
|
|
The computation running under the $\status$ handler immediately
|
|
performs an invocation of fork, causing $\nondet$ to explore both the
|
|
$\Then$-branch and the $\Else$-branch. In the former, $\Alice$ signs
|
|
in and quotes Ritchie, whilst in the latter Bob signs in and quotes a
|
|
Hamlet.
|
|
%
|
|
Looking at the output there is supposedly no interleaving of
|
|
computation, since the individual writes have not been
|
|
interleaved. From the stack of handlers, we \emph{know} that there has
|
|
been no interleaving of computation, because no handler in the stack
|
|
handles interleaving. Thus, our system only supports time sharing in
|
|
the extreme sense: we know from the $\nondet$ handler that every
|
|
effect of the parent process will be performed and handled before the
|
|
child process gets to run. In order to be able to share time properly
|
|
amongst processes, we must be able to interrupt them.
|
|
|
|
\paragraph{Interleaving computation}
|
|
%
|
|
We need an operation for interruptions and corresponding handler to
|
|
handle interrupts in order for the system to support interleaving of
|
|
processes.
|
|
%
|
|
\[
|
|
\bl
|
|
\interrupt : \UnitType \to \UnitType \eff \{\Interrupt : \UnitType \opto \UnitType\}\\
|
|
\interrupt~\Unit \defas \Do\;\Interrupt~\Unit
|
|
\el
|
|
\]
|
|
%
|
|
The intended behaviour of an invocation of $\Interrupt$ is to suspend
|
|
the invoking computation in order to yield time for another
|
|
computation to run.
|
|
%
|
|
We can achieve this behaviour by reifying the process state. For the
|
|
purpose of interleaving processes via interruptions it suffices to
|
|
view a process as being in either of two states: 1) it is done, that
|
|
is it has run to completion, or 2) it is paused, meaning it has
|
|
yielded to provide room for another process to run.
|
|
%
|
|
We can model the state using a recursive variant type parameterised by
|
|
some return value $\alpha$ and a set of effects $\varepsilon$ that the
|
|
process may perform.
|
|
%
|
|
\[
|
|
\Pstate~\alpha~\varepsilon \defas \forall \theta.
|
|
\ba[t]{@{}l@{}l}
|
|
[&\Done:\alpha;\\
|
|
&\Suspended:\UnitType \to \Pstate~\alpha~\varepsilon \eff \{\Interrupt:\theta;\varepsilon\} ]
|
|
\ea
|
|
\]
|
|
%
|
|
\dhil{Cite resumption monad}
|
|
%
|
|
The $\Done$-tag simply carries the return value of type $\alpha$. The
|
|
$\Suspended$-tag carries a suspended computation, which returns
|
|
another instance of $\Pstate$, and may or may not perform any further
|
|
invocations of $\Interrupt$. Note that, the presence variable $\theta$
|
|
in the effect row is universally quantified in the type alias
|
|
definition. The reason for this particular definition is that the type
|
|
of a value carried by $\Suspended$ is precisely the type of a
|
|
resumption originating from a handler that handles only the operation
|
|
$\Interrupt$ such as the following handler.
|
|
%
|
|
\[
|
|
\bl
|
|
\reifyP : (\UnitType \to \alpha \eff \{\Interrupt: \UnitType \opto \UnitType;\varepsilon\}) \to \Pstate~\alpha~\varepsilon\\
|
|
\reifyP~m \defas
|
|
\ba[t]{@{}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& \Done~res\\
|
|
\OpCase{\Interrupt}{\Unit}{resume} &\mapsto& \Suspended~resume
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
This handler tags and returns values with $\Done$. It also tags and
|
|
returns the resumption provided by the $\Interrupt$-case with
|
|
$\Suspended$. If we compose this handler with the nondeterminism
|
|
handler, then we obtain a term with the following type.
|
|
%
|
|
\[
|
|
\nondet\,(\lambda\Unit.\reifyP~m) : \List~(\Pstate~\alpha~\{\Fork: \UnitType \opto \Bool;\varepsilon\})
|
|
\]
|
|
%
|
|
for some $m : \UnitType \to \{\Proc;\varepsilon\}$ where
|
|
$\Proc \defas \{\Fork: \UnitType \opto \Bool;\Interrupt: \UnitType
|
|
\opto \UnitType\}$.
|
|
%
|
|
The composition yields a list of process states, some of which may be
|
|
in suspended state. In particular, the suspended computations may have
|
|
unhandled instances of $\Fork$ as signified by it being present in the
|
|
effect row. The reason for this is that in the above composition when
|
|
$\reifyP$ produces a $\Suspended$-tagged resumption, it immediately
|
|
returns through the $\Return$-case of $\nondet$, meaning that the
|
|
resumption escapes the $\nondet$. Recall that a resumption is a
|
|
delimited continuation that captures the extent from the operation
|
|
invocation up to and including the nearest enclosing suitable
|
|
handler. In this particular instance, it means that the $\nondet$
|
|
handler is part of the extent.
|
|
%
|
|
We ultimately want to return just a list of $\alpha$s to ensure every
|
|
process has run to completion. To achieve this, we need a function
|
|
that keeps track of the state of every process, and in particular it
|
|
must run each $\Suspended$-tagged computation under the $\nondet$
|
|
handler to produce another list of process state, which must be
|
|
handled recursively.
|
|
%
|
|
\[
|
|
\bl
|
|
\schedule : \List~(\Pstate~\alpha~\{\Fork:\Bool;\varepsilon\}) \to \List~\alpha \eff \varepsilon\\
|
|
\schedule~ps \defas
|
|
\ba[t]{@{}l}
|
|
\Let\;run \revto
|
|
\Rec\;sched\,\Record{ps;done}.\\
|
|
\qquad\Case\;ps\;\{
|
|
\ba[t]{@{}r@{~}c@{~}l}
|
|
\nil &\mapsto& done\\
|
|
(\Done~res) \cons ps' &\mapsto& sched\,\Record{ps';res \cons done}\\
|
|
(\Suspended~m) \cons ps' &\mapsto& sched\,\Record{ps' \concat (\nondet~m);\, done} \}
|
|
\ea\\
|
|
\In\;run\,\Record{ps;\nil}
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The function $\schedule$ implements a process scheduler. It takes as
|
|
input a list of process states, where $\Suspended$-tagged computations
|
|
may perform the $\Fork$ operation. Locally it defines a recursive
|
|
function $sched$ which carries a list of active processes $ps$ and the
|
|
results of completed processes $done$. The function inspects the
|
|
process list $ps$ to test whether it is empty or nonempty. If it is
|
|
empty it returns the list of results $done$. Otherwise, if the head is
|
|
$\Done$-tagged value, then the function is recursively invoked with
|
|
tail of processes $ps'$ and the list $done$ augmented with the value
|
|
$res$. If the head is a $\Suspended$-tagged computation $m$, then
|
|
$sched$ is recursively invoked with the process list $ps'$
|
|
concatenated with the result of running $m$ under the $\nondet$
|
|
handler.
|
|
|
|
%
|
|
Using the above machinery, we can define a function which adds
|
|
time-sharing capabilities to the system.
|
|
%
|
|
\[
|
|
\bl
|
|
\timeshare : (\UnitType \to \alpha \eff \Proc) \to \List~\alpha\\
|
|
\timeshare~m \defas \schedule\,[\Suspended\,(\lambda\Unit.\reifyP~m)]
|
|
\el
|
|
\]
|
|
%
|
|
The function $\timeshare$ handles the invocations of $\Fork$ and
|
|
$\Interrupt$ in some computation $m$ by starting it in suspended state
|
|
under the $\reifyP$ handler. The $\schedule$ actually starts the
|
|
computation, when it runs the computation under the $\nondet$ handler.
|
|
%
|
|
|
|
The question remains how to inject invocations of $\Interrupt$ such
|
|
that computation gets interleaved.
|
|
|
|
\paragraph{Interruption via interception}
|
|
%
|
|
To implement process preemption operating systems typically to rely on
|
|
the underlying hardware to asynchronously generate some kind of
|
|
interruption signals. These signals can be caught by the operating
|
|
system's process scheduler, which can then decide to which processes
|
|
to suspend and continue.
|
|
%
|
|
If our core calculi had an integrated notion of asynchrony and effects
|
|
along the lines of \citeauthor{AhmanP21}'s core calculus
|
|
$\lambda_{\text{\ae}}$~\cite{AhmanP21}, then we could potentially
|
|
treat interruption signals as asynchronous effectful operations, which
|
|
can occur spontaneously and, as suggested by \citet{DolanEHMSW17} and
|
|
realised by \citet{Poulson20}, be handled by a user-definable handler.
|
|
%
|
|
|
|
In the absence of asynchronous effects we have to inject synchronous
|
|
interruptions ourselves.
|
|
%
|
|
One extreme approach is to trust the user to perform invocations of
|
|
$\Interrupt$ periodically.
|
|
%
|
|
Another approach is based on the fact that every effect (except for
|
|
divergence) occurs via some operation invocation, and every-so-often
|
|
the user is likely to perform computational effect, thus the basic
|
|
idea is to bundle $\Interrupt$ with invocations of other
|
|
operations. For example, we can insert an instance of $\Interrupt$ in
|
|
some of the wrapper functions for operation invocations that we have
|
|
defined so conscientiously thus far. The problem with this approach is
|
|
that it requires a change of type signatures. To exemplify this
|
|
problem consider type of the $\echo$ function if we were to bundle an
|
|
invocation of $\Interrupt$ along side $\Write$.
|
|
%
|
|
\[
|
|
\bl
|
|
\echo' : \String \to \UnitType \eff \{\Interrupt : \UnitType \opto \UnitType;\Write : \Record{\UFD;\String} \opto \UnitType\}\\
|
|
\echo'~cs \defas \Do\;\Interrupt\,\Unit;\,\Do\;\Write\,\Record{\stdout;cs}
|
|
\el
|
|
\]
|
|
%
|
|
In addition to $\Write$ the effect row must now necessarily mention
|
|
the $\Interrupt$ operation. As a consequence this approach is not
|
|
backwards compatible, since the original definition of $\echo$ can be
|
|
used in a context that prohibits occurrences of $\Interrupt$. Clearly,
|
|
this alternative definition cannot be applied in such a context.
|
|
|
|
There is backwards-compatible way to bundle the two operations
|
|
together. We can implement a handler that \emph{intercepts}
|
|
invocations of $\Write$ and handles them by performing an interrupt
|
|
and, crucially, reperforming the intercepted write operation.
|
|
%
|
|
\[
|
|
\bl
|
|
\dec{interruptWrite} :
|
|
\ba[t]{@{~}l@{~}l}
|
|
&(\UnitType \to \alpha \eff \{\Interrupt : \UnitType \opto \UnitType;\Write : \Record{\UFD;\String} \opto \UnitType\})\\
|
|
\to& \alpha \eff \{\Interrupt : \UnitType \opto \UnitType;\Write : \Record{\UFD;\String} \opto \UnitType\}
|
|
\ea\\
|
|
\dec{interruptWrite}~m \defas
|
|
\ba[t]{@{~}l}
|
|
\Handle\;m~\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& res\\
|
|
\OpCase{\Write}{\Record{fd;cs}}{resume} &\mapsto&
|
|
\ba[t]{@{}l}
|
|
\interrupt\,\Unit;\\
|
|
resume\,(\Do\;\Write~\Record{fd;cs})
|
|
\ea
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
This handler is not `self-contained' as the other handlers we have
|
|
defined previously. It gives in some sense a `partial' interpretation
|
|
of $\Write$ as it leaves open the semantics of $\Interrupt$ and
|
|
$\Write$, i.e. this handler must be run in a suitable context of other
|
|
handlers.
|
|
|
|
Let us plug this handler into the previous example to see what
|
|
happens.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\bl
|
|
\basicIO\,(\lambda\Unit.\\
|
|
\qquad\timeshare\,(\lambda\Unit.\\
|
|
\qquad\qquad\dec{interruptWrite}\,(\lambda\Unit.\\
|
|
\qquad\qquad\qquad\sessionmgr\,\Record{\Root;\lambda\Unit.\\
|
|
\qquad\qquad\qquad\qquad\status\,(\lambda\Unit.
|
|
\ba[t]{@{}l}
|
|
\If\;\fork~\Unit\;\Then\;
|
|
\su~\Alice;\,
|
|
\quoteRitchie~\Unit\\
|
|
\Else\;
|
|
\su~\Bob;\,
|
|
\quoteHamlet~\Unit)})))
|
|
\ea
|
|
\el \smallskip\\
|
|
\reducesto^+&
|
|
\bl
|
|
\Record{
|
|
\ba[t]{@{}l}
|
|
[0, 0];
|
|
\texttt{"}\ba[t]{@{}l}
|
|
\texttt{UNIX is basically To be, or not to be,\nl{}}\\
|
|
\texttt{a simple operating system, that is the question:\nl{}}\\
|
|
\texttt{but Whether 'tis nobler in the mind to suffer\nl{}}\\
|
|
\texttt{you have to be a genius to understand the simplicity.\nl{}"}}
|
|
\ea
|
|
\ea\\
|
|
: \Record{\List~\Int; \UFile}
|
|
\el
|
|
\ea
|
|
\]
|
|
%
|
|
Evidently, each write operation has been interleaved, resulting in a
|
|
mishmash poetry of Shakespeare and \UNIX{}.
|
|
%
|
|
% To some this may be a shambolic treatment of classical arts, whilst to
|
|
% others this may be a modern contemporaneous treatment. As the saying
|
|
% goes: art is in the eye of the beholder.
|
|
|
|
\subsection{State: file i/o}
|
|
\label{sec:tiny-unix-io}
|
|
|
|
Thus far the system supports limited I/O, abnormal process
|
|
termination, multiple user sessions, and multi-tasking via concurrent
|
|
processes. At this stage we have most of core features in place. We
|
|
still have to complete the I/O model. The current I/O model provides
|
|
an incomplete file system consisting of a single write-only file.
|
|
%
|
|
In this section we will implement a \UNIX{}-like file system that
|
|
supports file creation, opening, truncation, read and write
|
|
operations, and file linking.
|
|
%
|
|
|
|
To implement a file system we will need to use state. State can
|
|
readily be implemented with an effect handler~\cite{KammarLO13}.
|
|
%
|
|
It is a deliberate choice to leave state for last, because once you
|
|
have state it is tempting to use it excessively --- to the extent it
|
|
becomes platitudinous.
|
|
%
|
|
As demonstrated in the previous sections, it is possible to achieve
|
|
many things that have a stateful flavour without explicit state by
|
|
harnessing the implicit state provided by the program stack.
|
|
|
|
In the following subsection, I will provide an interface for stateful
|
|
operations and their implementation in terms of a handler. The
|
|
stateful operations will be put to use in the subsequent subsection to
|
|
implement a basic sequential file system.
|
|
|
|
\subsubsection{Handling state}
|
|
|
|
The interface for accessing and updating a state cell consists of two
|
|
operations.
|
|
%
|
|
\[
|
|
\State~\beta \defas \{\Get:\UnitType \opto \beta;\Put:\beta \opto \UnitType\}
|
|
\]
|
|
%
|
|
The intended operational behaviour of $\Get$ operation is to read the
|
|
value of type $\beta$ of the state cell, whilst the $\Put$ operation
|
|
is intended to replace the current value held by the state cell with
|
|
another value of type $\beta$. As per usual business, the following
|
|
functions abstract the invocation of the operations.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{\quad\qquad\quad}c@{~}l}
|
|
\Uget : \UnitType \to \beta \eff \{\Get:\UnitType \opto \beta\}
|
|
& &
|
|
\Uput : \UnitType \to \beta \eff \{\Put:\beta \opto \UnitType\}\\
|
|
\Uget~\Unit \defas \Do\;\Get~\Unit
|
|
& &
|
|
\Uput~st \defas \Do\;\Put~st
|
|
\el
|
|
\]
|
|
%
|
|
The following handler interprets the operations.
|
|
%
|
|
\[
|
|
\bl
|
|
\runState : \Record{\beta;\UnitType \to \alpha \eff \State~\beta} \to \Record{\alpha;\beta}\\
|
|
\runState~\Record{st_0;m} \defas
|
|
\ba[t]{@{}l}
|
|
\Let\;run \revto
|
|
\ba[t]{@{}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& \lambda st.\Record{res;st}\\
|
|
\OpCase{\Get}{\Unit}{resume} &\mapsto& \lambda st.resume~st~st\\
|
|
\OpCase{\Put}{st'}{resume} &\mapsto& \lambda st.resume~\Unit~st'
|
|
\ea
|
|
\ea\\
|
|
\In\;run~st_0
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The $\runState$ handler provides a generic way to interpret any
|
|
stateful computation. It takes as its first parameter the initial
|
|
value of the state cell. The second parameter is a potentially
|
|
stateful computation. Ultimately, the handler returns the value of the
|
|
input computation along with the current value of the state cell.
|
|
|
|
This formulation of state handling is analogous to the standard
|
|
monadic implementation of state handling~\citep{Wadler95}. In the
|
|
context of handlers, the implementation uses a technique known as
|
|
\emph{parameter-passing}~\citep{PlotkinP09,Pretnar15}.
|
|
%
|
|
Each case returns a state-accepting function.
|
|
%
|
|
The $\Return$-case returns a function that produces a pair consisting
|
|
of return value of $m$ and the final state $st$.
|
|
%
|
|
The $\Get$-case returns a function that applies the resumption
|
|
$resume$ to the current state $st$. Recall that return type of a
|
|
resumption is the same as its handler's return type, so since the
|
|
handler returns a function, it follows that
|
|
$resume : \beta \to \beta \to \Record{\alpha, \beta}$. In other words,
|
|
the invocation of $resume$ produces another state-accepting
|
|
function. This function arises from the next activation of the handler
|
|
either by way of a subsequent operation invocation in $m$ or the
|
|
completion of $m$ to invoke the $\Return$-case. Since $\Get$ does not
|
|
modify the value of the state cell it passes $st$ unmodified to the
|
|
next handler activation.
|
|
%
|
|
In the $\Put$-case the resumption must also produce a state-accepting
|
|
function of the same type, however, the type of the resumption is
|
|
slightly different
|
|
$resume : \UnitType \to \beta \to \Record{\alpha, \beta}$. The unit
|
|
type is the expected return type of $\Put$. The state-accepting
|
|
function arising from $resume~\Unit$ is supplied with the new state
|
|
value $st'$. This application effectively discards the current state
|
|
value $st$.
|
|
|
|
The first operation invocation in $m$, or if it completes without
|
|
invoking $\Get$ or $\Put$, the handler returns a function that accepts
|
|
the initial state. The function gets bound to $run$ which is
|
|
subsequently applied to the provided initial state $st_0$ which causes
|
|
evaluation of the stateful fragment of $m$ to continue.
|
|
%
|
|
\dhil{Discuss briefly local vs global state~\cite{PauwelsSM19}}
|
|
|
|
|
|
\subsubsection{Basic serial file system}
|
|
%
|
|
\begin{figure}[t]
|
|
\centering
|
|
\begin{tabular}[t]{| l |}
|
|
\hline
|
|
\multicolumn{1}{| c |}{\textbf{Directory}} \\
|
|
\hline
|
|
\strlit{hamlet}\tikzmark{hamlet}\\
|
|
\hline
|
|
\strlit{ritchie.txt}\tikzmark{ritchie}\\
|
|
\hline
|
|
\multicolumn{1}{| c |}{$\vdots$}\\
|
|
\hline
|
|
\strlit{stdout}\tikzmark{stdout}\\
|
|
\hline
|
|
\multicolumn{1}{| c |}{$\vdots$}\\
|
|
\hline
|
|
\strlit{act3}\tikzmark{act3}\\
|
|
\hline
|
|
\end{tabular}
|
|
\hspace{1.5cm}
|
|
\begin{tabular}[t]{| c |}
|
|
\hline
|
|
\multicolumn{1}{| c |}{\textbf{I-List}} \\
|
|
\hline
|
|
1\tikzmark{ritchieino}\\
|
|
\hline
|
|
2\tikzmark{hamletino}\\
|
|
\hline
|
|
\multicolumn{1}{| c |}{$\vdots$}\\
|
|
\hline
|
|
1\tikzmark{stdoutino}\\
|
|
\hline
|
|
\end{tabular}
|
|
\hspace{1.5cm}
|
|
\begin{tabular}[t]{| l |}
|
|
\hline
|
|
\multicolumn{1}{| c |}{\textbf{Data region}} \\
|
|
\hline
|
|
\tikzmark{stdoutdr}\strlit{}\\
|
|
\hline
|
|
\tikzmark{hamletdr}\strlit{To be, or not to be...}\\
|
|
\hline
|
|
\multicolumn{1}{| c |}{$\vdots$}\\
|
|
\hline
|
|
\tikzmark{ritchiedr}\strlit{UNIX is basically...}\\
|
|
\hline
|
|
\end{tabular}
|
|
%% Hamlet arrows.
|
|
\tikz[remember picture,overlay]\draw[->,thick,out=30,in=160] ([xshift=1.23cm,yshift=0.1cm]pic cs:hamlet) to ([xshift=-0.85cm,yshift=0.1cm]pic cs:hamletino) node[] {};
|
|
\tikz[remember picture,overlay]\draw[->,thick,out=30,in=180] ([xshift=0.62cm,yshift=0.1cm]pic cs:hamletino) to ([xshift=-0.23cm,yshift=0.1cm]pic cs:hamletdr) node[] {};
|
|
%% Ritchie arrows.
|
|
\tikz[remember picture,overlay]\draw[->,thick,out=-30,in=180] ([xshift=0.22cm,yshift=0.1cm]pic cs:ritchie) to ([xshift=-0.85cm,yshift=0.1cm]pic cs:ritchieino) node[] {};
|
|
\tikz[remember picture,overlay]\draw[->,thick,out=30,in=180] ([xshift=0.62cm,yshift=0.1cm]pic cs:ritchieino) to ([xshift=-0.23cm,yshift=0.1cm]pic cs:ritchiedr) node[] {};
|
|
%% Act3 arrow.
|
|
\tikz[remember picture,overlay]\draw[->,thick,out=10,in=210] ([xshift=1.64cm,yshift=0.1cm]pic cs:act3) to ([xshift=-0.85cm,yshift=-0.5mm]pic cs:hamletino) node[] {};
|
|
%% Stdout arrows.
|
|
\tikz[remember picture,overlay]\draw[->,thick,out=30,in=180] ([xshift=1.23cm,yshift=0.1cm]pic cs:stdout) to ([xshift=-0.85cm,yshift=0.1cm]pic cs:stdoutino) node[] {};
|
|
\tikz[remember picture,overlay]\draw[->,thick,out=30,in=180] ([xshift=0.62cm,yshift=0.1cm]pic cs:stdoutino) to ([xshift=-0.23cm,yshift=0.1cm]pic cs:stdoutdr) node[] {};
|
|
\caption{\UNIX{} directory, i-list, and data region mappings.}\label{fig:unix-mappings}
|
|
\end{figure}
|
|
%
|
|
A file system provide an abstraction over storage media in a computer
|
|
system by organising the storage space into a collection of files.
|
|
This abstraction facilities typical file operations: allocation,
|
|
deletion, reading, and writing.
|
|
%
|
|
\UNIX{} dogmatises the notion of file to the point where
|
|
\emph{everything is a file}. A typical \UNIX{}-style file system
|
|
differentiates between ordinary files, directory files, and special
|
|
files~\cite{RitchieT74}. An ordinary file is a sequence of
|
|
characters. A directory file is a container for all kinds of files. A
|
|
special file is an interface for interacting with an i/o device.
|
|
|
|
We will implement a \emph{basic serial file system}, which we dub
|
|
\fsname{}.
|
|
%
|
|
It will be basic in the sense that it models the bare minimum to pass
|
|
as a file system, that is we will implement support for the four basic
|
|
operations: file allocation, file deletion, file reading, and file
|
|
writing.
|
|
%
|
|
The read and write operations will be serial, meaning every file is
|
|
read in order from its first character to its last character, and
|
|
every file is written to by appending the new content.
|
|
%
|
|
\fsname{} will only contain ordinary files, and as a result
|
|
the file hierarchy will be entirely flat. Although, the system can
|
|
readily be extended to be hierarchical, it comes at the expense of
|
|
extra complexity, that blurs rather than illuminates the model.
|
|
|
|
\paragraph{Directory, i-list, and data region}
|
|
%
|
|
A storage medium is an array of bytes. An \UNIX{} file system is
|
|
implemented on top of this array by interpreting certain intervals of
|
|
the array differently. These intervals provide the space for the
|
|
essential administrative structures for file organisation.
|
|
%
|
|
\begin{enumerate}
|
|
\item The \emph{directory} is a collection of human-readable names for
|
|
files. In general, a file may have multiple names. Each name is
|
|
stored along with a pointer into the i-list.
|
|
\item The \emph{i-list} is a collection of i-nodes. Each i-node
|
|
contains the meta-data for a file along with a pointer into the data
|
|
region.
|
|
\item The \emph{data region} contains the actual file contents.
|
|
\end{enumerate}
|
|
%
|
|
These structures make up the \fsname{}.
|
|
%
|
|
Figure~\ref{fig:unix-mappings} depicts an example with the three
|
|
structures and a mapping between them.
|
|
%
|
|
The only file metadata tracked by \fsname{} is the number of names for
|
|
a file.
|
|
%
|
|
The three structures and their mappings can be implemented using
|
|
association lists. Although, a better practical choice may be a
|
|
functional map or functional array~\cite{Okasaki99}, association lists
|
|
have the advantage of having a simple, straightforward implementation.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{\qquad}c@{~}l}
|
|
\Directory \defas \List~\Record{\String;\Int} &&%
|
|
\DataRegion \defas \List~\Record{\Int;\UFile} \smallskip\\
|
|
\INode \defas \Record{lno:\Int;loc:\Int} &&%
|
|
\IList \defas \List~\Record{\Int;\INode}
|
|
\ea
|
|
\]
|
|
%
|
|
Mathematically, we may think the type $\dec{Directory}$ as denoting a
|
|
partial function $\C^\ast \pto \Z$, where $\C$ is a suitable
|
|
alphabet. The function produces an index into the i-list.
|
|
%
|
|
Similarly, the type $\dec{IList}$ denotes a partial function
|
|
$\Z \pto \Z \times \Z$, where the codomain is the denotation of
|
|
$\dec{INode}$. The first component of the pair is the number of names
|
|
linked to the i-node, and as such $\Z$ is really an overapproximation
|
|
as an i-node cannot have a negative number of names. The second
|
|
component is an index into the data region.
|
|
%
|
|
The denotation of the type $\dec{DataRegion}$ is another partial
|
|
function $\Z \pto \C^\ast$.
|
|
|
|
We define the type of the file system to be a record of the three
|
|
association lists along with two counters for the next available index
|
|
into the data region and i-list, respectively.
|
|
%
|
|
\[
|
|
\FileSystem \defas \Record{
|
|
\ba[t]{@{}l}
|
|
dir:\Directory;ilist:\IList;dreg:\DataRegion;\\
|
|
dnext:\Int;inext:\Int}
|
|
\ea
|
|
\]
|
|
%
|
|
We can then give an implementation of the initial state of the file
|
|
system.
|
|
%
|
|
\[
|
|
\dec{fs}_0 \defas \Record{
|
|
\ba[t]{@{}l}
|
|
dir=[\Record{\strlit{stdout};0}];ilist=[\Record{0;\Record{lno=1;loc=0}}];dreg=[\Record{0;\strlit{}}];\\
|
|
dnext=1;inext=1}
|
|
\ea
|
|
\]
|
|
%
|
|
Initially the file system contains a single, empty file with the name
|
|
$\texttt{stdout}$. Next we will implement the basic operations on the
|
|
file system separately.
|
|
|
|
We have made a gross simplification here, as a typical file system
|
|
would provide some \emph{file descriptor} abstraction for managing
|
|
access open files. In \fsname{} we will operate directly on i-nodes,
|
|
meaning we define $\UFD \defas \Int$, meaning the file open operation
|
|
will return an i-node identifier. As consequence it does not matter
|
|
whether a file is closed after use as file closing would be a no-op
|
|
(closing a file does not change the state of its i-node). Therefore
|
|
\fsname{} will not provide a close operation. As a further consequence
|
|
the file system will have no resource leakage.
|
|
|
|
\paragraph{File reading and writing}
|
|
%
|
|
Let us begin by giving a semantics to file reading and writing. We
|
|
need an abstract operation for each file operation.
|
|
%
|
|
\[
|
|
\dec{FileRW} \defas \{\URead : \Int \opto \Option~\String;\UWrite : \Record{\Int;\String} \opto \UnitType\}
|
|
\]
|
|
%
|
|
The operation $\URead$ is parameterised by an i-node number
|
|
(i.e. index into the i-list) and possibly returns the contents of the
|
|
file pointed to by the i-node. The operation may fail if it is
|
|
provided with a stale i-node number. Thus the option type is used to
|
|
signal failure or success to the caller.
|
|
%
|
|
The $\UWrite$ operation is parameterised by an i-node number and some
|
|
strings to be appended onto the file pointed to by the i-node. The
|
|
operation returns unit, and thus the operation does not signal to its
|
|
caller whether it failed or succeed.
|
|
%
|
|
Before we implement a handler for the operations, we will implement
|
|
primitive read and write operations that operate directly on the file
|
|
system. We will use the primitive operations to implement the
|
|
semantics for $\URead$ and $\UWrite$. To implement the primitive the
|
|
operations we will need two basic functions on association lists. I
|
|
will only their signatures here.
|
|
%
|
|
\[
|
|
\bl
|
|
\lookup : \Record{\alpha;\List\,\Record{\alpha;\beta}} \to \beta \eff \{\Fail : \UnitType \opto \ZeroType\} \smallskip\\
|
|
\modify : \Record{\alpha;\beta;\List\,\Record{\alpha;\beta}} \to \Record{\alpha;\beta}
|
|
\el
|
|
\]
|
|
%
|
|
Given a key of type $\alpha$ the $\lookup$ function returns the
|
|
corresponding value of type $\beta$ in the given association list. If
|
|
the key does not exists, then the function invokes the $\Fail$
|
|
operation to signal failure.
|
|
%
|
|
The $\modify$ function takes a key and a value. If the key exists in
|
|
the provided association list, then it replaces the value bound by the
|
|
key with the provided value.
|
|
%
|
|
Using these functions we can implement the primitive read and write
|
|
operations.
|
|
%
|
|
\[
|
|
\bl
|
|
\fread : \Record{\Int;\FileSystem} \to \String \eff \{\Fail : \UnitType \opto \ZeroType\}\\
|
|
\fread\,\Record{ino;fs} \defas
|
|
\ba[t]{@{}l}
|
|
\Let\;inode \revto \lookup\,\Record{ino; fs.ilist}\;\In\\
|
|
\lookup\,\Record{inode.loc; fs.dreg}
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The function $\fread$ takes as input the i-node number for the file to
|
|
be read and a file system. First it looks up the i-node structure in
|
|
the i-list, and then it uses the location in the i-node to look up the
|
|
file contents in the data region. Since $\fread$ performs no exception
|
|
handling it will fail if either look up fails. The implementation of
|
|
the primitive write operation is similar.
|
|
%
|
|
\[
|
|
\bl
|
|
\fwrite : \Record{\Int;\String;\FileSystem} \to \FileSystem \eff \{\Fail : \UnitType \opto \ZeroType\}\\
|
|
\fwrite\,\Record{ino;cs;fs} \defas
|
|
\ba[t]{@{}l}
|
|
\Let\;inode \revto \lookup\,\Record{ino; fs.ilist}\;\In\\
|
|
\Let\;file \revto \lookup\,\Record{inode.loc; fs.dreg}\;\In\\
|
|
\Record{\,fs\;\keyw{with}\;dreg = \modify\,\Record{inode.loc;file \concat cs;fs}}
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The first two lines grab hold of the file, whilst the last line
|
|
updates the data region in file system by appending the string $cs$
|
|
onto the file.
|
|
%
|
|
Before we can implement the handler, we need an exception handling
|
|
mechanism. The following exception handler interprets $\Fail$ as some
|
|
default value.
|
|
%
|
|
\[
|
|
\bl
|
|
\faild : \Record{\alpha;\UnitType \to \alpha \eff \{\Fail : \UnitType \opto \ZeroType\}} \to \alpha\\
|
|
\faild\,\Record{default;m} \defas
|
|
\ba[t]{@{~}l}
|
|
\Handle\;m~\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;x &\mapsto& x\\
|
|
\OpCase{\Fail}{\Unit}{\_} &\mapsto& default
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The $\Fail$-case is simply the default value, whilst the
|
|
$\Return$-case is the identity.
|
|
%
|
|
Now we can use all the above pieces to implement a handler for the
|
|
$\URead$ and $\UWrite$ operations.
|
|
%
|
|
\[
|
|
\bl
|
|
\fileRW : (\UnitType \to \alpha \eff \dec{FileRW}) \to \alpha \eff \State~\FileSystem\\
|
|
\fileRW~m \defas
|
|
\ba[t]{@{}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& res\\
|
|
\OpCase{\URead}{ino}{resume} &\mapsto&
|
|
\bl
|
|
\Let\;cs\revto \faild\,\Record{\None;\lambda\Unit.\\
|
|
\quad\Some\,(\fread\,\Record{ino;\Uget\,\Unit})}\\
|
|
\In\;resume\,cs
|
|
\el\\
|
|
\OpCase{\UWrite}{\Record{ino;cs}}{resume} &\mapsto&
|
|
\ba[t]{@{}l}
|
|
\faild~\Record{\Unit; \lambda \Unit.\\
|
|
\quad\bl
|
|
\Let\;fs \revto \fwrite\,\Record{ino;cs;\Uget\,\Unit}\\
|
|
\In\;\Uput~fs};\,resume\,\Unit
|
|
\el
|
|
\ea
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The $\URead$-case uses the $\fread$ function to implement reading a
|
|
file. The file system state is retrieved using the state operation
|
|
$\Uget$. The possible failure of $\fread$ is dealt with by the
|
|
$\faild$ handler by interpreting failure as $\None$.
|
|
%
|
|
The $\UWrite$-case makes use of the $\fwrite$ function to implement
|
|
writing to a file. Again the file system state is retrieved using
|
|
$\Uget$. The $\Uput$ operation is used to update the file system state
|
|
with the state produced by the successful invocation of
|
|
$\fwrite$. Failure is interpreted as unit, meaning that from the
|
|
caller perspective the operation fails silently.
|
|
|
|
\paragraph{File creation and opening}
|
|
The signature of file creation and opening is unsurprisingly comprised
|
|
of two operations.
|
|
%
|
|
\[
|
|
\dec{FileCO} \defas \{\UCreate : \String \opto \Option~\Int; \UOpen : \String \opto \Option~\Int\}
|
|
\]
|
|
%
|
|
The implementation of file creation and opening follows the same
|
|
pattern as the implementation of reading and writing. As before, we
|
|
implement a primitive routine for each operation that interacts
|
|
directly with the file system structure. We first implement the
|
|
primitive file opening function as the file creation function depends
|
|
on this function.
|
|
%
|
|
\[
|
|
\bl
|
|
\fopen : \Record{\String;\FileSystem} \to \Int \eff \{\Fail : \UnitType \opto \ZeroType\}\\
|
|
\fopen\,\Record{fname;fs} \defas \lookup\,\Record{fname; fs.dir}
|
|
\el
|
|
\]
|
|
%
|
|
Opening a file in the file system simply corresponds to returning the
|
|
i-node index associated with the filename in the directory table.
|
|
|
|
The \UNIX{} file create command does one of two things depending on
|
|
the state of the file system. If the create command is provided with
|
|
the name of a file that is already present in the directory, then the
|
|
system truncates the file, and returns the file descriptor for the
|
|
file. Otherwise the system allocates a new empty file and returns its
|
|
file descriptor~\cite{RitchieT74}. To check whether a file already
|
|
exists in the directory we need a function $\dec{has}$ that given a
|
|
filename and the file system state returns whether there exists a file
|
|
with the given name. This function can be built completely generically
|
|
from the functions we already have at our disposal.
|
|
%
|
|
\[
|
|
\bl
|
|
\dec{has} : \Record{\alpha;\List~\Record{\alpha;\beta}} \to \Bool\\
|
|
\dec{has}\,\Record{k;xs} \defas \faild\,\Record{\False;(\lambda\Unit.\lookup\,\Record{k;xs};\True)}
|
|
\el
|
|
\]
|
|
%
|
|
The function $\dec{has}$ applies $\lookup$ under the failure handler
|
|
with default value $\False$. If $\lookup$ returns successfully then
|
|
its result is ignored, and the computation returns $\True$, otherwise
|
|
the computation returns the default value $\False$.
|
|
%
|
|
With this function we can implement the semantics of create.
|
|
%
|
|
\[
|
|
\bl
|
|
\fcreate : \Record{\String;\FileSystem} \to \Record{\Int;\FileSystem} \eff \{\Fail : \UnitType \opto \ZeroType\}\\
|
|
\fcreate\,\Record{fname;fs} \defas
|
|
\ba[t]{@{}l}
|
|
\If\;\dec{has}\,\Record{fname;fs.dir}\;\Then\\
|
|
\quad\bl
|
|
\Let\;ino \revto \fopen\,\Record{fname;fs}\;\In\\
|
|
\Let\;inode \revto \lookup\,\Record{ino;fs}\;\In\\
|
|
\Let\;dreg' \revto \modify\,\Record{inode.loc; \strlit{}; fs.dreg}\;\In\\
|
|
\Record{ino;\Record{fs\;\With\;dreg = dreg'}}
|
|
\el\\
|
|
\Else\\
|
|
\quad\bl
|
|
\Let\;loc \revto fs.lnext \;\In\\
|
|
\Let\;dreg \revto \Record{loc; \strlit{}} \cons fs.dreg\;\In\\
|
|
\Let\;ino \revto fs.inext \;\In\\
|
|
\Let\;inode \revto \Record{loc=loc;lno=1}\;\In\\
|
|
\Let\;ilist \revto \Record{ino;inode} \cons fs.ilist \;\In\\
|
|
\Let\;dir \revto \Record{fname; ino} \cons fs.dir \;\In\\
|
|
\Record{ino;\Record{
|
|
\bl
|
|
dir=dir;ilist=ilist;dreg=dreg;\\
|
|
lnext=loc+1;inext=ino+1}}
|
|
\el
|
|
\el
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The $\Then$-branch accounts for the case where the filename $fname$
|
|
already exists in the directory. First we retrieve the i-node for the
|
|
file to obtain its location in the data region such that we can
|
|
truncate the file contents.
|
|
%
|
|
The branch returns the i-node index along with the modified file
|
|
system. The $\Else$-branch allocates a new empty file. First we
|
|
allocate a location in the data region by copying the value of
|
|
$fs.lnext$ and consing the location and empty string onto
|
|
$fs.dreg$. The next three lines allocates the i-node for the file in a
|
|
similar fashion. The second to last line associates the filename with
|
|
the new i-node. The last line returns the identifier for the i-node
|
|
along with the modified file system, where the next location ($lnext$)
|
|
and next i-node identifier ($inext$) have been incremented.
|
|
%
|
|
It is worth noting that the effect signature of $\dec{has}$ mentions
|
|
$\Fail$ even though it will (most likely) never fail. It is present in
|
|
the effect row due to the use of $\lookup$ in the $\Then$-branch. This
|
|
application of $\lookup$ can only fail if the file system is in an
|
|
inconsistent state, where the index $ino$ has become stale. The
|
|
$\dec{f}$-family of functions have been carefully engineered to always
|
|
leave the file system in a consistent state.
|
|
%
|
|
|
|
Now we can implement the semantics for the $\UCreate$ and $\UOpen$
|
|
effectful operations. The implementation is similar to the
|
|
implementation of $\fileRW$.
|
|
%
|
|
\[
|
|
\bl
|
|
\fileAlloc : (\UnitType \to \alpha \eff \dec{FileCO}) \to \alpha \eff \State~\FileSystem\\
|
|
\fileAlloc~m \defas
|
|
\ba[t]{@{}l}
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& res\\
|
|
\OpCase{\UCreate}{fname}{resume} &\mapsto&
|
|
\bl
|
|
\Let\;ino \revto \faild\,\Record{\None; \lambda\Unit.\\
|
|
\quad\bl
|
|
\Let\;\Record{ino;fs} = \fcreate\,\Record{\,fname;\Uget\,\Unit}\\
|
|
\In\;\Uput~fs;\,\Some~ino}
|
|
\el\\
|
|
\In\; resume\,ino
|
|
\el\\
|
|
\OpCase{\UOpen}{fname}{resume} &\mapsto&
|
|
\ba[t]{@{}l}
|
|
\Let\; ino \revto \faild~\Record{\None; \lambda \Unit.\\
|
|
\quad\Some\,(\fopen\,\Record{fname;\Uget\,\Unit})}\\
|
|
\In\;resume\,ino
|
|
\ea
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
|
|
\paragraph{Stream redirection}
|
|
%
|
|
The processes we have defined so far use the $\echo$ utility to write
|
|
to the $\stdout$ file. The target file $\stdout$ is hardwired into the
|
|
definition of $\echo$ (Section~\ref{sec:tiny-unix-bio}). To take
|
|
advantage of the capabilities of the new file system we could choose
|
|
to modify the definition of $\echo$ such that it is parameterised by
|
|
the target file. However, such a modification is a breaking
|
|
change. Instead we can define a \emph{stream redirection} operator
|
|
that allow us to redefine the target of $\Write$ operations locally.
|
|
%
|
|
\[
|
|
\bl
|
|
\redirect :
|
|
\bl
|
|
\Record{\UnitType \to \alpha \eff \{\Write : \Record{\Int;\String} \opto \UnitType\}; \String}\\
|
|
\to \alpha \eff \{\UCreate : \String \opto \Option~\Int;\Exit : \Int \opto \ZeroType;\Write : \Record{\Int;\String} \opto \UnitType\}
|
|
\el\\
|
|
m~\redirect~fname \defas
|
|
\ba[t]{@{}l}
|
|
\Let\;ino \revto \Case\;\Do\;\UCreate~fname\;\{
|
|
\ba[t]{@{~}l@{~}c@{~}l}
|
|
\None &\mapsto& \exit\,1\\
|
|
\Some~ino &\mapsto& ino\}
|
|
\ea\\
|
|
\In\;\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& res\\
|
|
\OpCase{\Write}{\Record{\_;cs}}{resume} &\mapsto& resume\,(\Do\;\Write\,\Record{ino;cs})
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The operator $\redirect$ first attempts to create a new target file
|
|
with name $fname$. If it fails it simply exits with code
|
|
$1$. Otherwise it continues with the i-node reference $ino$. The
|
|
handler overloads the definition of $\Write$ inside the provided
|
|
computation $m$. The new definition drops the i-node reference of the
|
|
initial target file and replaces it by the reference to new target
|
|
file.
|
|
|
|
This stream redirection operator is slightly more general than the
|
|
original redirection operator in the original \UNIX{} environment. As
|
|
the \UNIX{} redirection operator only redirects writes targeted at the
|
|
\emph{stdout} file~\cite{RitchieT74}, whereas the above operator
|
|
redirects writes regardless of their initial target.
|
|
%
|
|
It is straightforward to implement this original \UNIX{} behaviour by
|
|
inspecting the first argument of $\Write$ in the operation clause
|
|
before committing to performing the redirecting $\Write$ operation.
|
|
%
|
|
Modern \UNIX{} environments typically provide more fine-grained
|
|
control over redirects, for example by allowing the user to specify on
|
|
a per file basis which writes should be redirected. Again, we can
|
|
implement this behaviour by comparing the provided file descriptor
|
|
with the descriptor in the payload of $\Write$.
|
|
|
|
% ([0, 0, 0],
|
|
% (dir = [("hamlet", 2), ("ritchie.txt", 1), ("stdout", 0)],
|
|
% dregion = [(2, "To be, or not to be,
|
|
% that is the question:
|
|
% Whether 'tis nobler in the mind to suffer
|
|
% "),
|
|
% (1, "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.
|
|
% "), (
|
|
% 0, "")],
|
|
% inext = 3,
|
|
% inodes = [(2, (lno = 1, loc = 2)), (1, (lno = 1, loc = 1)), (0, (lno = 1, loc = 0))],
|
|
% lnext = 3)) : ([Int], FileSystem)
|
|
% links> init(fsys0, example7);
|
|
% ([0, 0, 0],
|
|
% (dir = [("hamlet", 2), ("ritchie.txt", 1), ("stdout", 0)],
|
|
% dregion = [(2, "To be, or not to be,
|
|
% that is the question:
|
|
% Whether 'tis nobler in the mind to suffer
|
|
% "),
|
|
% (1, "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.
|
|
% "), (
|
|
% 0, "")],
|
|
% inext = 3,
|
|
% inodes = [(2, (lno = 1, loc = 2)), (1, (lno = 1, loc = 1)), (0, (lno = 1, loc = 0))],
|
|
% lnext = 3)) : ([Int], FileSystem)
|
|
\medskip We can plug everything together to observe the new file
|
|
system in action.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\bl
|
|
\runState\,\Record{\dec{fs}_0;\fileRW\,(\lambda\Unit.\\
|
|
\quad\fileAlloc\,(\lambda\Unit.\\
|
|
\qquad\timeshare\,(\lambda\Unit.\\
|
|
\qquad\quad\dec{interruptWrite}\,(\lambda\Unit.\\
|
|
\qquad\qquad\sessionmgr\,\Record{\Root;\lambda\Unit.\\
|
|
\qquad\qquad\quad\status\,(\lambda\Unit.
|
|
\ba[t]{@{}l}
|
|
\If\;\fork~\Unit\;\Then\;
|
|
\su~\Alice;\,
|
|
\quoteRitchie~\redirect~\strlit{ritchie.txt}\\
|
|
\Else\;
|
|
\su~\Bob;\,
|
|
\quoteHamlet~\redirect~\strlit{hamlet})}))))}
|
|
\ea
|
|
\el \smallskip\\
|
|
\reducesto^+&
|
|
\bl
|
|
\Record{
|
|
\ba[t]{@{}l}
|
|
[0, 0];\\
|
|
\Record{
|
|
\ba[t]{@{}l}
|
|
dir=[\Record{\strlit{hamlet};2},
|
|
\Record{\strlit{ritchie.txt};1},
|
|
\Record{\strlit{stdout};0}];\\
|
|
ilist=[\Record{2;\Record{lno=1;loc=2}},
|
|
\Record{1;\Record{lno=1;loc=1}},
|
|
\Record{0;\Record{lno=1;loc=0}}];\\
|
|
dreg=[
|
|
\ba[t]{@{}l}
|
|
\Record{2;
|
|
\ba[t]{@{}l@{}l}
|
|
\texttt{"}&\texttt{To be, or not to be,\nl{}that is the question:\nl{}}\\
|
|
&\texttt{Whether 'tis nobler in the mind to suffer\nl{}"}},
|
|
\ea\\
|
|
\Record{1;
|
|
\ba[t]{@{}l@{}l}
|
|
\texttt{"}&\texttt{UNIX is basically a simple operating system, }\\
|
|
&\texttt{but you have to be a genius to understand the simplicity.\nl{"}}},
|
|
\ea\\
|
|
\Record{0; \strlit{}}]; lnext=3; inext=3}}\\
|
|
\ea
|
|
\ea
|
|
\ea\\
|
|
: \Record{\List~\Int; \FileSystem}
|
|
\el
|
|
\ea
|
|
\]
|
|
%
|
|
The writes of the processes $\quoteRitchie$ and $\quoteHamlet$ are now
|
|
being redirected to designated files \texttt{ritchie.txt} and
|
|
\texttt{hamlet}, respectively. The operating system returns the
|
|
completion status of all the processes along with the current state of
|
|
the file system such that it can be used as the initial file system
|
|
state on the next start of the operating system.
|
|
|
|
\subsubsection{File linking and unlinking}
|
|
%
|
|
At this point the implementation of \fsname{} is almost feature
|
|
complete. However, we have yet to implement two dual file operations:
|
|
linking and unlinking. The former enables us to associate a new
|
|
filename with an existing i-node, thus providing a mechanism for
|
|
making soft copies of files (i.e. the file contents are
|
|
shared). The latter lets us dissociate a filename from an i-node, thus
|
|
providing a means for removing files. The interface of linking and
|
|
unlinking is given below.
|
|
%
|
|
\[
|
|
\dec{FileLU} \defas \{\ULink : \Record{\String;\String} \opto \UnitType; \UUnlink : \String \opto \UnitType\}
|
|
\]
|
|
%
|
|
The $\ULink$ operation is parameterised by two strings. The first
|
|
string is the name of the \emph{source} file and the second string is
|
|
the \emph{destination} name (i.e. the new name). The $\UUnlink$
|
|
operation takes a single string argument, which is the name of the
|
|
file to be removed.
|
|
|
|
As before, we bundle the low level operations on the file system state
|
|
into their own functions. We start with file linking.
|
|
%
|
|
\[
|
|
\bl
|
|
\flink : \Record{\String;\String;\FileSystem} \to \FileSystem \eff \{\Fail : \UnitType \opto \ZeroType\}\\
|
|
\flink\,\Record{src;dest;fs} \defas
|
|
\bl
|
|
\If\;\dec{has}\,\Record{dest;fs.dir}\;\Then\;\Absurd~\Do\;\Fail\,\Unit\\
|
|
\Else\;
|
|
\bl
|
|
\Let\;ino \revto \lookup~\Record{src;fs.dir}\;\In\\
|
|
\Let\;dir' \revto \Record{dest;ino} \cons fs.dir\;\In\\
|
|
\Let\;inode \revto \lookup~\Record{ino;fs.ilist}\;\In\\
|
|
\Let\;inode' \revto \Record{inode\;\With\;lno = inode.lno + 1}\;\In\\
|
|
\Let\;ilist' \revto \modify\,\Record{ino;inode';fs.ilist}\;\In\\
|
|
\Record{fs\;\With\;dir = dir';ilist = ilist'}
|
|
\el
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The function $\flink$ checks whether the destination filename, $dest$,
|
|
already exists in the directory. If it exists then the function raises
|
|
the $\Fail$ exception. Otherwise it looks up the index of the i-node,
|
|
$ino$, associated with the source file, $src$. Next, the directory is
|
|
extended with the destination filename, which gets associated with
|
|
this index, meaning $src$ and $dest$ both share the same
|
|
i-node. Finally, the link count of the i-node at index $ino$ gets
|
|
incremented, and the function returns the updated file system state.
|
|
%
|
|
|
|
The semantics of file unlinking is slightly more complicated as an
|
|
i-node may become unlinked, meaning that it needs to garbage collected
|
|
along with its file contents in the data region. To implement file
|
|
removal we make use of another standard operation on association
|
|
lists.
|
|
%
|
|
\[
|
|
\remove : \Record{\alpha;\Record{\alpha;\beta}} \to \Record{\alpha;\beta}
|
|
\]
|
|
%
|
|
The first parameter to $\remove$ is the key associated with the entry
|
|
to be removed from the association list, which is given as the second
|
|
parameter. If the association list does not have an entry for the
|
|
given key, then the function behaves as the identity. The behaviour of
|
|
the function in case of multiple entries for a single key does not
|
|
matter as our system is carefully set up to ensure that each key has
|
|
an unique entry.
|
|
%
|
|
\[
|
|
\bl
|
|
\funlink : \Record{\String;\FileSystem} \to \FileSystem \eff \{\Fail : \UnitType \opto \ZeroType\}\\
|
|
\funlink\,\Record{fname;fs} \defas
|
|
\bl
|
|
\If\;\dec{has}\,\Record{fname;fs.dir}\;\Then\\
|
|
\quad
|
|
\bl
|
|
\Let\;ino \revto \lookup\,\Record{fname;fs.dir}\;\In\\
|
|
\Let\;dir' \revto \remove\,\Record{fname;fs.dir}\;\In\\
|
|
\Let\;inode \revto \lookup\,\Record{ino;fs.ilist}\;\In\\
|
|
\Let\;\Record{ilist';dreg'} \revto
|
|
\bl
|
|
\If\;inode.lno > 1\;\Then\\
|
|
\quad\bl
|
|
\Let\;inode' \revto \Record{inode\;\With\;lno = inode.lno - 1}\\
|
|
\In\;\Record{\modify\,\Record{ino;inode';fs.ilist};fs.dreg}
|
|
\el\\
|
|
\Else\;
|
|
\Record{\bl\remove\,\Record{ino;fs.ilist};\\
|
|
\remove\,\Record{inode.loc;fs.dreg}}
|
|
\el
|
|
\el\\
|
|
\In\;\Record{fs\;\With\;dir = dir'; ilist = ilist'; dreg = dreg'}
|
|
\el\\
|
|
\Else\; \Absurd~\Do\;\Fail\,\Unit
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The $\funlink$ function checks whether the given filename $fname$
|
|
exists in the directory. If it does not, then it raises the $\Fail$
|
|
exceptions. However, if it does exist then the function proceeds to
|
|
lookup the index of the i-node for the file, which gets bound to
|
|
$ino$, and subsequently remove the filename from the
|
|
directory. Afterwards it looks up the i-node with index $ino$. Now one
|
|
of two things happen depending on the current link count of the
|
|
i-node. If the count is greater than one, then we need only decrement
|
|
the link count by one, thus we modify the i-node structure. If the
|
|
link count is 1, then i-node is about to become stale, thus we must
|
|
garbage collect it by removing both the i-node from the i-list and the
|
|
contents from the data region. Either branch returns the new state of
|
|
i-list and data region. Finally, the function returns the new file
|
|
system state.
|
|
|
|
With the $\flink$ and $\funlink$ functions, we can implement the
|
|
semantics for $\ULink$ and $\UUnlink$ operations following the same
|
|
patterns as for the other file system operations.
|
|
%
|
|
\[
|
|
\bl
|
|
\fileLU : (\UnitType \to \alpha \eff \FileLU) \to \alpha \eff \State~\FileSystem\\
|
|
\fileLU~m \defas
|
|
\bl
|
|
\Handle\;m\,\Unit\;\With\\
|
|
~\ba{@{~}l@{~}c@{~}l}
|
|
\Return\;res &\mapsto& res\\
|
|
\OpCase{\ULink}{\Record{src;dest}}{resume} &\mapsto&
|
|
\bl
|
|
\faild\,\Record{\Unit; \lambda\Unit.\\
|
|
\quad\bl
|
|
\Let\;fs = \flink\,\Record{src;dest;\Uget\,\Unit}\\
|
|
\In\;\Uput~fs}; resume\,\Unit
|
|
\el
|
|
\el\\
|
|
\OpCase{\UUnlink}{fname}{resume} &\mapsto&
|
|
\bl
|
|
\faild\,\Record{\Unit; \lambda\Unit.\\
|
|
\quad\bl
|
|
\Let\;fs = \funlink\,\Record{fname;\Uget\,\Unit}\\
|
|
\In\;\Uput~fs}; resume\,\Unit
|
|
\el
|
|
\el
|
|
\ea
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The composition of $\fileRW$, $\fileAlloc$, and $\fileLU$ complete the
|
|
implementation of \fsname{}.
|
|
%
|
|
\[
|
|
\bl
|
|
\FileIO \defas \{\FileRW;\FileCO;\FileLU\} \medskip\\
|
|
\fileIO : (\UnitType \to \alpha \eff \FileIO) \to \alpha \eff \State~\FileSystem \\
|
|
\fileIO~m \defas \fileRW\,(\lambda\Unit. \fileAlloc\,(\lambda\Unit.\fileLU\,m))
|
|
\el
|
|
\]
|
|
%
|
|
The three handlers may as well be implemented as a single monolithic
|
|
handler, since they implement different operations, return the same
|
|
value, and make use of the same state cell. In practice a monolithic
|
|
handler may have better performance. However, a sufficiently clever
|
|
compiler would be able to take advantage of the fusion laws of deep
|
|
handlers to fuse the three handlers into one (e.g. using the technique
|
|
of \citet{WuS15}), and thus allow modular composition without
|
|
composition.
|
|
|
|
We now have the building blocks to implement a file copying
|
|
utility. We will implement the utility such that it takes an argument
|
|
to decide whether it should make a soft copy such that the source file
|
|
and destination file are linked, or it should make a hard copy such
|
|
that a new i-node is allocated and the bytes in the data regions gets
|
|
duplicated.
|
|
%
|
|
\[
|
|
\bl
|
|
\dec{cp} : \Record{\Bool;\String;\String} \to \UnitType \eff \{\FileIO;\Exit : \Int \opto \ZeroType\}\\
|
|
\dec{cp}~\Record{link;src;dest} \defas
|
|
\bl
|
|
\If\;link\;\Then\;\Do\;\ULink\,\Record{src;dest}\;\\
|
|
\Else\; \bl
|
|
\Case\;\Do\;\UOpen~src\\
|
|
\{ \ba[t]{@{~}l@{~}c@{~}l}
|
|
\None &\mapsto& \exit~1\\
|
|
\Some~ino &\mapsto& \\
|
|
\multicolumn{3}{l}{\quad\Case\;\Do\;\URead~ino\;\{
|
|
\ba[t]{@{~}l@{~}c@{~}l}
|
|
\None &\mapsto& \exit~1\\
|
|
\Some~cs &\mapsto& \echo~cs~\redirect~dest \} \}
|
|
\ea}
|
|
\ea
|
|
\el
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
If the $link$ parameter is $\True$, then the utility makes a soft copy
|
|
by performing the operation $\ULink$ to link the source file and
|
|
destination file. Otherwise the utility makes a hard copy by first
|
|
opening the source file. If $\UOpen$ returns the $\None$ (i.e. the
|
|
open failed) then the utility exits with code $1$. If the open
|
|
succeeds then the entire file contents are read. If the read operation
|
|
fails then we again just exit, however, in the event that it succeeds
|
|
we apply the $\echo$ to the file contents and redirects the output to
|
|
the file $dest$.
|
|
|
|
The logic for file removal is part of the semantics for
|
|
$\UUnlink$. Therefore the implementation of a file removal utility is
|
|
simply an application of the operation $\UUnlink$.
|
|
%
|
|
\[
|
|
\bl
|
|
\dec{rm} : \String \to \UnitType \eff \{\UUnlink : \String \opto \UnitType\}\\
|
|
\dec{rm}~fname \defas \Do\;\UUnlink~fname
|
|
\el
|
|
\]
|
|
%
|
|
We can now plug it all together.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\bl
|
|
\runState\,\Record{\dec{fs}_0;\fileIO\,(\lambda\Unit.\\
|
|
\quad\timeshare\,(\lambda\Unit.\\
|
|
\qquad\dec{interruptWrite}\,(\lambda\Unit.\\
|
|
\qquad\quad\sessionmgr\,\Record{\Root;\lambda\Unit.\\
|
|
\qquad\qquad\status\,(\lambda\Unit.
|
|
\ba[t]{@{}l}
|
|
\If\;\fork~\Unit\;\\
|
|
\Then\;
|
|
\bl
|
|
\su~\Alice;\,
|
|
\quoteRitchie~\redirect~\strlit{ritchie.txt};\\
|
|
\dec{cp}\,\Record{\False;\strlit{ritchie.txt};\strlit{ritchie}};\\
|
|
\dec{rm}\,\strlit{ritchie.txt}
|
|
\el\\
|
|
\Else\;
|
|
\bl
|
|
\su~\Bob;\,
|
|
\quoteHamlet~\redirect~\strlit{hamlet};\\
|
|
\dec{cp}\,\Record{\True;\strlit{hamlet};\strlit{act3}}
|
|
)}))))}
|
|
\el
|
|
\ea
|
|
\el \smallskip\\
|
|
\reducesto^+&
|
|
\bl
|
|
\Record{
|
|
\ba[t]{@{}l}
|
|
[0, 0];\\
|
|
\Record{
|
|
\ba[t]{@{}l}
|
|
dir=[\Record{\strlit{ritchie};3},\Record{\strlit{act3};2},\Record{\strlit{hamlet};2},
|
|
\Record{\strlit{stdout};0}];\\
|
|
ilist=[\Record{3;\Record{lno=1;loc=3}},
|
|
\Record{2;\Record{lno=2;loc=2}},
|
|
\Record{0;\Record{lno=1;loc=0}}];\\
|
|
dreg=[
|
|
\ba[t]{@{}l}
|
|
\Record{3;
|
|
\ba[t]{@{}l@{}l}
|
|
\texttt{"}&\texttt{UNIX is basically a simple operating system, }\\
|
|
&\texttt{but you have to be a genius to understand the simplicity.\nl{"}}},
|
|
\ea\\
|
|
\Record{2;
|
|
\ba[t]{@{}l@{}l}
|
|
\texttt{"}&\texttt{To be, or not to be,\nl{}that is the question:\nl{}}\\
|
|
&\texttt{Whether 'tis nobler in the mind to suffer\nl{}"}},
|
|
\ea\\
|
|
\Record{0; \strlit{}}]; lnext=4; inext=4}}\\
|
|
\ea
|
|
\ea
|
|
\ea\\
|
|
: \Record{\List~\Int; \FileSystem}
|
|
\el
|
|
\ea
|
|
\]
|
|
%
|
|
Alice copies the file \texttt{ritchie.txt} as \texttt{ritchie}, and
|
|
subsequently removes the original file, which effectively amounts to a
|
|
roundabout way of renaming a file. It is evident from the file system
|
|
state that the file is a hard copy as the contents of
|
|
\texttt{ritchie.txt} now reside in location $3$ rather than location
|
|
$1$ in the data region. Bob makes a soft copy of the file
|
|
\texttt{hamlet} as \texttt{act3}, which is evident by looking at the
|
|
directory where the two filenames point to the same i-node (with index
|
|
$2$), whose link counter has value $2$.
|
|
|
|
\paragraph{Summary} Throughout this section we have used effect
|
|
handlers to give a semantics to a \UNIX{}-style operating system by
|
|
treating system calls as effectful operations, whose semantics are
|
|
given by handlers, acting as composable micro-kernels. Starting from a
|
|
simple bare minimum file I/O model we seen how the modularity of
|
|
effect handlers enable us to develop a feature-rich operating system
|
|
in an incremental way by composing several handlers to implement a
|
|
basic file system, multi-user environments, and multi-tasking
|
|
support. Each incremental change to the system has been backwards
|
|
compatible with previous changes in the sense that we have not
|
|
modified any previously defined interfaces in order to support a new
|
|
feature. It serves as a testament to demonstrate the versatility of
|
|
effect handlers, and it suggests that handlers can be a viable option
|
|
to use with legacy code bases to retrofit functionality. The operating
|
|
system makes use of fourteen operations, which are being handled by
|
|
twelve handlers, some of which are used multiple times, e.g. the
|
|
$\environment$ and $\redirect$ handlers.
|
|
|
|
|
|
% \begin{figure}[t]
|
|
% \centering
|
|
% \begin{tikzpicture}[node distance=4cm,auto,>=stealth']
|
|
% \node[] (server) {\bfseries Bob (server)};
|
|
% \node[left = of server] (client) {\bfseries Alice (client)};
|
|
% \node[below of=server, node distance=5cm] (server_ground) {};
|
|
% \node[below of=client, node distance=5cm] (client_ground) {};
|
|
% %
|
|
% \draw (client) -- (client_ground);
|
|
% \draw (server) -- (server_ground);
|
|
% \draw[->,thick] ($(client)!0.25!(client_ground)$) -- node[rotate=-6,above,scale=0.7,midway]{SYN 42} ($(server)!0.40!(server_ground)$);
|
|
% \draw[<-,thick] ($(client)!0.56!(client_ground)$) -- node[rotate=6,above,scale=0.7,midway]{SYN 84;ACK 43} ($(server)!0.41!(server_ground)$);
|
|
% \draw[->,thick] ($(client)!0.57!(client_ground)$) -- node[rotate=-6,above,scale=0.7,midway]{ACK 85} ($(server)!0.72!(server_ground)$);
|
|
% \end{tikzpicture}
|
|
% \caption{Sequence diagram for the TCP handshake example.}\label{fig:tcp-handshake}
|
|
% \end{figure}
|
|
|
|
% \paragraph{TCP threeway handshake}
|
|
|
|
% The existing literature already contain an extensive amount of
|
|
% introductory examples of programming with (deep) effect
|
|
% handlers~\cite{KammarLO13,Pretnar15,Leijen17}.
|
|
|
|
|
|
% \subsubsection{Exception handling}
|
|
% \label{sec:exn-handling-in-action}
|
|
|
|
% Effect handlers subsume a variety of control abstractions, and
|
|
% arguably the simplest such abstraction is exception handling.
|
|
|
|
% \begin{example}[Option monad, directly]
|
|
% %
|
|
% To handle the possibility of failure in a pure functional
|
|
% programming language (e.g. Haskell~\cite{JonesABBBFHHHHJJLMPRRW99}),
|
|
% a computation is run under a particular monad $m$ with some monadic
|
|
% operation $\fail : \Unit \to m~\alpha$ for signalling failure.
|
|
% %
|
|
% Concretely, one can use the \emph{option monad} which interprets the
|
|
% success of as $\Some$ value and failure as $\None$.
|
|
% %
|
|
% For good measure, let us first define the option type constructor.
|
|
% %
|
|
% \[
|
|
% \Option~\alpha \defas [\Some:\alpha;\None]
|
|
% \]
|
|
% %
|
|
% The constructor is parameterised by a type variable $\alpha$. The
|
|
% data constructor $\Some$ carries a payload of type $\alpha$, whilst
|
|
% the other data constructor $\None$ carries no payload.
|
|
% %
|
|
% The monadic interface and its implementation for $\Option$ is as
|
|
% follows.
|
|
% %
|
|
% \[
|
|
% \bl
|
|
% \return : \alpha \to \Option~\alpha\\
|
|
% \return~x \defas \Some~x \smallskip\\
|
|
% - \bind - : \Option~\alpha \to (\alpha \to \Option~\beta) \to \Option~\beta\\
|
|
% m \bind k \defas \Case\;m\;\{
|
|
% \ba[t]{@{}l@{~}c@{~}l}
|
|
% \None &\mapsto& \None\\
|
|
% \Some~x &\mapsto& k~x \}
|
|
% \ea \smallskip\\
|
|
% \fail : \Unit \to \Option~\alpha\\
|
|
% \fail~\Unit \defas \None
|
|
% \el
|
|
% \]
|
|
% %
|
|
% The $\return$ operation lifts a given value into monad by tagging it
|
|
% with $\Some$. The $\bind$ operation (pronounced bind) is the monadic
|
|
% sequencing operation. It takes $m$, an instance of the monad, along
|
|
% with a continuation $k$ and pattern matches on $m$ to determine
|
|
% whether to apply the continuation. If $m$ is $\None$ then (a new
|
|
% instance of) $\None$ is returned -- this essentially models
|
|
% short-circuiting of failed computations. Otherwise if $m$ is $\Some$
|
|
% we apply the continuation $k$ to the payload $x$. The $\fail$
|
|
% operation is simply the constant $\None$.
|
|
% %
|
|
|
|
% Let us put the monad to use. An illustrative example is safe
|
|
% division. Mathematical division is not defined when the denominator
|
|
% is zero. It is standard for implementations of division in safe
|
|
% programming languages to raise an exception, which we can code
|
|
% monadically as follows.
|
|
% %
|
|
% \[
|
|
% \bl
|
|
% -/_{\dec{m}}- : \Record{\Float, \Float} \to \Option~\Float\\
|
|
% n/_{\dec{m}}\,d \defas
|
|
% \If\;d = 0 \;\Then\;\fail~\Unit\;
|
|
% \Else\;\return~(n \div d)
|
|
% \el
|
|
% \]
|
|
% %
|
|
% If the provided denominator $d$ is zero, then the implementation
|
|
% signals failure by invoking the $\fail$ operation. Otherwise, the
|
|
% implementation performs the mathematical division and lifts the
|
|
% result into the monad via $\return$.
|
|
% %
|
|
% A monadic reading of the type signature tells us not only that the
|
|
% computation may fail, but also that failure is interpreted using the
|
|
% $\Option$ monad.
|
|
|
|
% Let us use this safe implementation of division to implement a safe
|
|
% function for computing the reciprocal plus one for a given number
|
|
% $x$, i.e. $\frac{1}{x} + 1$.
|
|
% %
|
|
% \[
|
|
% \bl
|
|
% \dec{rpo_m} : \Float \to \Option~\Float\\
|
|
% \dec{rpo_m}~x \defas (1.0 /_{\dec{m}}\,x) \bind (\lambda y. \return~(y + 1.0))
|
|
% \el
|
|
% \]
|
|
% %
|
|
% The implementation first computes the (monadic) result of dividing 1
|
|
% by $x$, and subsequently sequences this result with a continuation
|
|
% that adds one to the result.
|
|
% %
|
|
% Consider some example evaluations.
|
|
% %
|
|
% \[
|
|
% \ba{@{~}l@{~}c@{~}l}
|
|
% \dec{rpo_m}~1.0 &\reducesto^+& \Some~2.0\\
|
|
% \dec{rpo_m}~(-1.0) &\reducesto^+& \Some~0.0\\
|
|
% \dec{rpo_m}~0.0 &\reducesto^+& \None
|
|
% \el
|
|
% \]
|
|
% %
|
|
% The first (respectively second) evaluation follows because
|
|
% $1.0/_{\dec{m}}\,1.0$ returns $\Some~1.0$ (respectively
|
|
% $\Some~(-1.0)$), meaning that $\bind$ applies the continuation to
|
|
% produce the result $\Some~2.0$ (respectively $\Some~0.0$).
|
|
% %
|
|
% The last evaluation follows because $1.0/_{\dec{m}}\,0.0$ returns
|
|
% $\None$, consequently $\bind$ does not apply the continuation, thus
|
|
% producing the result $\None$.
|
|
|
|
% This idea of using a monad to model failure stems from denotational
|
|
% semantics and is due to Moggi~\cite{Moggi89}.
|
|
|
|
% Let us now change perspective and reimplement the above example
|
|
% using effect handlers. We can translate the monadic interface into
|
|
% an effect signature consisting of a single operation $\Fail$, whose
|
|
% codomain is the empty type $\Zero$. We also define an auxiliary
|
|
% function $\fail$ which packages an invocation of $\Fail$.
|
|
% %
|
|
% \[
|
|
% \bl
|
|
% \Exn \defas \{\Fail: \Unit \opto \Zero\} \medskip\\
|
|
% \fail : \Unit \to \alpha \eff \Exn\\
|
|
% \fail \defas \lambda\Unit.\Absurd\;(\Do\;\Fail)
|
|
% \el
|
|
% \]
|
|
% %
|
|
% The $\Absurd$ computation term is used to coerce the return type
|
|
% $\Zero$ of $\Fail$ into $\alpha$. This coercion is safe, because an
|
|
% invocation of $\Fail$ can never return as there are no inhabitants
|
|
% of type $\Zero$.
|
|
|
|
% We can now reimplement the safe division operator.
|
|
% %
|
|
% \[
|
|
% \bl
|
|
% -/- : \Record{\Float, \Float} \to \Float \eff \Exn\\
|
|
% n/d \defas
|
|
% \If\;d = 0 \;\Then\;\fail~\Unit\;
|
|
% \Else\;n \div d
|
|
% \el
|
|
% \]
|
|
% %
|
|
% The primary difference is that the interpretation of failure is no
|
|
% longer fixed. The type signature conveys that the computation may
|
|
% fail, but it says nothing about how failure is interpreted.
|
|
% %
|
|
% It is straightforward to implement the reciprocal function.
|
|
% %
|
|
% \[
|
|
% \bl
|
|
% \dec{rpo} : \Float \to \Float \eff \Exn\\
|
|
% \dec{rpo}~x \defas (1.0 / x) + 1.0
|
|
% \el
|
|
% \]
|
|
% %
|
|
% The monadic bind and return are now gone. We still need to provide
|
|
% an interpretation of $\Fail$. We do this by way of a handler that
|
|
% interprets success as $\Some$ and failure as $\None$.
|
|
% \[
|
|
% \bl
|
|
% \optionalise : (\Unit \to \alpha \eff \Exn) \to \Option~\alpha\\
|
|
% \optionalise \defas \lambda m.
|
|
% \ba[t]{@{~}l}
|
|
% \Handle\;m~\Unit\;\With\\
|
|
% ~\ba{@{~}l@{~}c@{~}l}
|
|
% \Return\;x &\mapsto& \Some~x\\
|
|
% \Fail~\Unit~resume &\mapsto& \None
|
|
% \ea
|
|
% \ea
|
|
% \el
|
|
% \]
|
|
% %
|
|
% The $\Return$-case injects the result of $m~\Unit$ into the option
|
|
% type. The $\Fail$-case discards the provided resumption and returns
|
|
% $\None$. Discarding the resumption effectively short-circuits the
|
|
% handled computation. In fact, there is no alternative to discard the
|
|
% resumption in this case as $resume : \Zero \to \Option~\alpha$
|
|
% cannot be invoked. Let us use this handler to interpret the
|
|
% examples.
|
|
% %
|
|
% \[
|
|
% \ba{@{~}l@{~}c@{~}l}
|
|
% \optionalise\,(\lambda\Unit.\dec{rpo}~1.0) &\reducesto^+& \Some~2.0\\
|
|
% \optionalise\,(\lambda\Unit.\dec{rpo}~(-1.0)) &\reducesto^+& \Some~0.0\\
|
|
% \optionalise\,(\lambda\Unit.\dec{rpo}~0.0) &\reducesto^+& \None
|
|
% \el
|
|
% \]
|
|
% %
|
|
% The first two evaluations follow because $\dec{rpo}$ returns
|
|
% successfully, and hence, the handler tags the respective results
|
|
% with $\Some$. The last evaluation follows because the safe division
|
|
% operator ($-/-$) inside $\dec{rpo}$ performs an invocation of $\Fail$,
|
|
% causing the handler to halt the computation and return $\None$.
|
|
|
|
% It is worth noting that we are free to choose another the
|
|
% interpretation of $\Fail$. To conclude this example, let us exercise
|
|
% this freedom and interpret failure outside of $\Option$. For
|
|
% example, we can interpret failure as some default constant.
|
|
% %
|
|
% \[
|
|
% \bl
|
|
% \faild : \Record{\alpha,\Unit \to \alpha \eff \Exn} \to \alpha\\
|
|
% \faild \defas \lambda \Record{default,m}.
|
|
% \ba[t]{@{~}l}
|
|
% \Handle\;m~\Unit\;\With\\
|
|
% ~\ba{@{~}l@{~}c@{~}l}
|
|
% \Return\;x &\mapsto& x\\
|
|
% \Fail~\Unit~\_ &\mapsto& default
|
|
% \ea
|
|
% \ea
|
|
% \el
|
|
% \]
|
|
% %
|
|
% Now the $\Return$-case is just the identity and $\Fail$ is
|
|
% interpreted as the provided default value.
|
|
% %
|
|
% We can reinterpret the above examples using $\faild$ and, for
|
|
% instance, choose the constant $0.0$ as the default value.
|
|
% %
|
|
% \[
|
|
% \ba{@{~}l@{~}c@{~}l}
|
|
% \faild\,\Record{0.0,\lambda\Unit.\dec{rpo}~1.0} &\reducesto^+& 2.0\\
|
|
% \faild\,\Record{0.0,\lambda\Unit.\dec{rpo}~(-1.0)} &\reducesto^+& 0.0\\
|
|
% \faild\,\Record{0.0,\lambda\Unit.\dec{rpo}~0.0} &\reducesto^+& 0.0
|
|
% \el
|
|
% \]
|
|
% %
|
|
% Since failure is now interpreted as $0.0$ the second and third
|
|
% computations produce the same result, even though the second
|
|
% computation is successful and the third computation is failing.
|
|
% \end{example}
|
|
|
|
% \begin{example}[Catch~\cite{SussmanS75}]
|
|
% \end{example}
|
|
|
|
% \subsubsection{Blind and non-blind backtracking}
|
|
|
|
% \begin{example}[Non-blind backtracking]
|
|
% \dhil{Nondeterminism}
|
|
% \end{example}
|
|
|
|
% \subsubsection{Stateful computation}
|
|
|
|
% \begin{example}[Dynamic binding]
|
|
% \dhil{Reader}
|
|
% \end{example}
|
|
|
|
% \begin{example}[State handling]
|
|
% \dhil{State}
|
|
% \end{example}
|
|
|
|
% \subsubsection{Generators and iterators}
|
|
|
|
% \begin{example}[Inversion of control]
|
|
% \dhil{Inversion of control: generator from iterator}
|
|
% \end{example}
|
|
|
|
% \begin{example}[Cooperative routines]
|
|
% \dhil{Coop}
|
|
% \end{example}
|
|
|
|
% \subsection{Coding nontermination}
|
|
|
|
\section{Shallow handlers}
|
|
\label{sec:unary-shallow-handlers}
|
|
|
|
Shallow handlers are an alternative to deep handlers. Shallow handlers
|
|
are defined as case-splits over computation trees, whereas deep
|
|
handlers are defined as folds. Consequently, a shallow handler
|
|
application unfolds only a single layer of the computation tree.
|
|
%
|
|
Semantically, the difference between deep and shallow handlers is
|
|
analogous to the difference between \citet{Church41} and
|
|
\citet{Scott62} encoding techniques for data types in the sense that
|
|
the recursion is intrinsic to the former, whilst recursion is
|
|
extrinsic to the latter.
|
|
%
|
|
Thus a fixpoint operator is necessary to make programming with shallow
|
|
handlers practical.
|
|
|
|
Shallow handlers offer more flexibility than deep handlers as they do
|
|
not hard wire a particular recursion scheme. Shallow handlers are
|
|
favourable when catamorphisms are not the natural solution to the
|
|
problem at hand.
|
|
%
|
|
A canonical example of when shallow handlers are desirable over deep
|
|
handlers is \UNIX{}-style pipes, where the natural implementation is
|
|
in terms of two mutually recursive functions (specifically
|
|
\emph{mutumorphisms}~\cite{Fokkinga90}), which is convoluted to
|
|
implement with deep
|
|
handlers~\cite{KammarLO13,HillerstromL18,HillerstromLA20}.
|
|
|
|
In this section we take $\BCalcRec$ as our starting point and extend
|
|
it with shallow handlers, resulting in the calculus $\SCalc$. The
|
|
calculus borrows some syntax and semantics from \HCalc{}, whose
|
|
presentation will not be duplicated in this section.
|
|
% Often deep handlers are attractive because they are semantically
|
|
% well-behaved and provide appropriate structure for efficient
|
|
% implementations using optimisations such as fusion~\cite{WuS15}, and
|
|
% as we saw in the previous they codify a wide variety of applications.
|
|
% %
|
|
% However, they are not always convenient for implementing other
|
|
% structural recursion schemes such as mutual recursion.
|
|
|
|
\subsection{Syntax and static semantics}
|
|
The syntax and semantics for effectful operation invocations are the
|
|
same as in $\HCalc$. Handler definitions and applications also have
|
|
the same syntax as in \HCalc{}, although we shall annotate the
|
|
application form for shallow handlers with a superscript $\dagger$ to
|
|
distinguish it from deep handler application.
|
|
%
|
|
\begin{syntax}
|
|
\slab{Computations} &M,N \in \CompCat &::=& \cdots \mid \ShallowHandle \; M \; \With \; H\\[1ex]
|
|
\end{syntax}
|
|
%
|
|
The static semantics for $\Handle^\dagger$ are the same as the static
|
|
semantics for $\Handle$.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*[Lab=\tylab{Handle^\dagger}]
|
|
{
|
|
\typ{\Gamma}{M : C} \\
|
|
\typ{\Gamma}{H : C \Harrow D}
|
|
}
|
|
{\Gamma \vdash \ShallowHandle \; M \; \With\; H : D}
|
|
|
|
|
|
%\mprset{flushleft}
|
|
\inferrule*[Lab=\tylab{Handler^\dagger}]
|
|
{{\bl
|
|
C = A \eff \{(\ell_i : A_i \opto B_i)_i; R\} \\
|
|
D = B \eff \{(\ell_i : P_i)_i; R\}\\
|
|
H = \{\Return\;x \mapsto M\} \uplus \{ \OpCase{\ell_i}{p_i}{r_i} \mapsto N_i \}_i
|
|
\el}\\\\
|
|
\typ{\Delta;\Gamma, x : A}{M : D}\\\\
|
|
[\typ{\Delta;\Gamma,p_i : A_i, r_i : B_i \to C}{N_i : D}]_i
|
|
}
|
|
{\typ{\Delta;\Gamma}{H : C \Harrow D}}
|
|
\end{mathpar}
|
|
%
|
|
The \tylab{Handler^\dagger} rule is remarkably similar to the
|
|
\tylab{Handler} rule. In fact, the only difference is the typing of
|
|
resumptions $r_i$. The codomain of $r_i$ is $C$ rather than $D$,
|
|
meaning that a resumption returns a value of the same type as the
|
|
input computation. In general the type $C$ may be different from the
|
|
output type $D$, thus it is evident from this typing rule that the
|
|
handler does not guard invocations of resumptions $r_i$.
|
|
|
|
|
|
\subsection{Dynamic semantics}
|
|
|
|
There are two reduction rules.
|
|
%{\small{
|
|
\begin{reductions}
|
|
\semlab{Ret^\dagger} &
|
|
\ShallowHandle \; (\Return \; V) \; \With \; H &\reducesto& N[V/x], \hfill\text{where } \hret = \{ \Return \; x \mapsto N \} \\
|
|
\semlab{Op^\dagger} &
|
|
\ShallowHandle \; \EC[\Do \; \ell \, V] \; \With \; H
|
|
&\reducesto& N[V/p, \lambda y . \, \EC[\Return \; y]/r], \\
|
|
\multicolumn{4}{@{}r@{}}{
|
|
\hfill\ba[t]{@{~}r@{~}l}
|
|
\text{where}& \hell = \{ \OpCase{\ell}{p}{r} \mapsto N \}\\
|
|
\text{and} & \ell \notin \BL(\EC)
|
|
\ea
|
|
}
|
|
\end{reductions}%}}%
|
|
%
|
|
The rule \semlab{Ret^\dagger} is the same as the \semlab{Ret} rule for
|
|
deep handlers --- there is no difference in how the return value is
|
|
handled. The \semlab{Op^\dagger} rule is almost the same as the
|
|
\semlab{Op} rule the crucial difference being the construction of the
|
|
resumption $r$. The resumption consists entirely of the captured
|
|
context $\EC$. Thus an invocation of $r$ does not reinstall its
|
|
handler as in the setting of deep handlers, meaning is up to the
|
|
programmer to supply the handler the next invocation of $\ell$ inside
|
|
$\EC$. This handler may be different from $H$.
|
|
|
|
\subsection{\UNIX{}-style pipes}
|
|
\label{sec:pipes}
|
|
|
|
A \UNIX{} pipe is an abstraction for streaming communication between
|
|
two processes. Technically, a pipe works by connecting the standard
|
|
out file descriptor of the first process to the standard in file
|
|
descriptor of the second process. The second process can then process
|
|
the output of the first process by reading its own standard in
|
|
file~\cite{RitchieT74}.
|
|
|
|
We could implement pipes using the file system, however, it would
|
|
require us to implement a substantial amount of bookkeeping as we
|
|
would have to generate and garbage collect a standard out file and a
|
|
standard in file per process. Instead we can represent the files as
|
|
effectful operations and connect them via handlers.
|
|
%
|
|
With shallow handlers we can implement a demand-driven Unix pipeline
|
|
operator as two mutually recursive handlers.
|
|
%
|
|
\[
|
|
\bl
|
|
\Pipe : \Record{\UnitType \to \alpha \eff \{ \Yield : \beta \opto \UnitType \}, \UnitType \to \alpha\eff\{ \Await : \UnitType \opto \beta \}} \to \alpha \\
|
|
\Pipe\, \Record{p; c} \defas
|
|
\bl
|
|
\ShallowHandle\; c\,\Unit \;\With\; \\
|
|
~\ba[m]{@{}l@{~}c@{~}l@{}}
|
|
\Return~x &\mapsto& x \\
|
|
\OpCase{\Await}{\Unit}{resume} &\mapsto& \Copipe\,\Record{resume; p} \\
|
|
\ea
|
|
\el\medskip\\
|
|
|
|
\Copipe : \Record{\beta \to \alpha\eff\{ \Await : \UnitType \opto \beta\}, \UnitType \to \alpha\eff\{ \Yield : \beta \opto \UnitType\}} \to \alpha \\
|
|
\Copipe\, \Record{c; p} \defas
|
|
\bl
|
|
\ShallowHandle\; p\,\Unit \;\With\; \\
|
|
~\ba[m]{@{}l@{~}c@{~}l@{}}
|
|
\Return~x &\mapsto& x \\
|
|
\OpCase{\Yield}{y}{resume} &\mapsto& \Pipe\,\Record{resume; \lambda \Unit. c\, y} \\
|
|
\ea \\
|
|
\el \\
|
|
\el
|
|
\]
|
|
%
|
|
A $\Pipe$ takes two suspended computations, a producer $p$ and a
|
|
consumer $c$.
|
|
%
|
|
Each of the computations returns a value of type $\alpha$.
|
|
%
|
|
The producer can perform the $\Yield$ operation, which yields a value
|
|
of type $\beta$ and the consumer can perform the $\Await$ operation,
|
|
which correspondingly awaits a value of type $\beta$. The $\Yield$
|
|
operation corresponds to writing to standard out, whilst $\Await$
|
|
corresponds to reading from standard in.
|
|
%
|
|
The shallow handler $\Pipe$ runs the consumer first. If the consumer
|
|
terminates with a value, then the $\Return$ clause is executed and
|
|
returns that value as is. If the consumer performs the $\Await$
|
|
operation, then the $\Copipe$ handler is invoked with the resumption
|
|
of the consumer ($resume$) and the producer ($p$) as arguments. This
|
|
models the effect of blocking the consumer process until the producer
|
|
process provides some data.
|
|
|
|
The $\Copipe$ function runs the producer to get a value to feed to the
|
|
waiting consumer.
|
|
% The arguments are swapped and the consumer component
|
|
% now expects a value.
|
|
If the producer performs the $\Yield$ operation, then $\Pipe$ is
|
|
invoked with the resumption of the producer along with a thunk that
|
|
applies the consumer's resumption to the yielded value.
|
|
%
|
|
For aesthetics, we define a right-associative infix alias for pipe:
|
|
$p \mid c \defas \lambda\Unit.\Pipe\,\Record{p;c}$.
|
|
|
|
Let us put the pipe operator to use by performing a simple string
|
|
frequency analysis on a file. We will implement the analysis as a
|
|
collection of small single-purpose utilities which we connect by way
|
|
of pipes. We will build a collection of small utilities. We will make
|
|
use of two standard list iteration functions.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}c@{~}l}
|
|
\map &:& \Record{\alpha \to \beta;\List~\alpha} \to \List~\beta\\
|
|
\iter &:& \Record{\alpha \to \beta; \List~\alpha} \to \UnitType
|
|
\ea
|
|
\]
|
|
%
|
|
The function $\map$ applies its function argument to each element of
|
|
the provided list in left-to-right order and returns the resulting
|
|
list. The function $\iter$ is simply $\map$ where the resulting list
|
|
is ignored. Our first utility is a simplified version of the GNU
|
|
coreutil utility \emph{cat}, which copies the contents of files to
|
|
standard out~\cite[Section~3.1]{MacKenzieMPPBYS20}. Our version will
|
|
open a single file and stream its contents one character at a time.
|
|
%
|
|
\[
|
|
\bl
|
|
\cat : \String \to \UnitType \eff \{\FileIO;\Yield : \Char \opto \UnitType;\Exit : \Int \opto \ZeroType\}\\
|
|
\cat~fname \defas
|
|
\bl
|
|
\Case\;\Do\;\UOpen~fname~\{\\
|
|
~\ba[t]{@{~}l@{~}c@{~}l}
|
|
\None &\mapsto& \exit\,1\\
|
|
\Some~ino &\mapsto& \bl \Case\;\Do\;\URead~ino~\{\\
|
|
~\ba[t]{@{~}l@{~}c@{~}l}
|
|
\None &\mapsto& \exit\,1\\
|
|
\Some~cs &\mapsto& \iter\,\Record{\lambda c.\Do\;\Yield~c;cs}; \Do\;\Yield~\charlit{\textnil} \}\}
|
|
\ea
|
|
\el
|
|
\ea
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The last line is the interesting line of code. The contents of the
|
|
file gets bound to $cs$, which is supplied as an argument to the list
|
|
iteration function $\iter$. The function argument yields each
|
|
character. Each invocation of $\Yield$ effectively suspends the
|
|
iteration until the next character is awaited.
|
|
%
|
|
This is an example of inversion of control as the iterator $\iter$ has
|
|
been turned into a generator.
|
|
%
|
|
We use the character $\textnil$ to identify the end of a stream. It is
|
|
essentially a character interpretation of the empty list (file)
|
|
$\nil$.
|
|
|
|
The $\cat$ utility processes the entire contents of a given
|
|
file. However, we may only be interested in some parts. The GNU
|
|
coreutil \emph{head} provides a way to process only a fixed amount of
|
|
lines and ignore subsequent
|
|
lines~\cite[Section~5.1]{MacKenzieMPPBYS20}.
|
|
%
|
|
We will implement a simplified version of this utility which lets us
|
|
keep the first $n$ lines of a stream and discard the remainder. This
|
|
process will act as a \emph{filter}, which is an intermediary process
|
|
in a pipeline that both awaits and yields data.
|
|
%
|
|
\[
|
|
\bl
|
|
\head : \Int \to \UnitType \eff \{\Await : \UnitType \opto \Char;\Yield : \Char \opto \UnitType\}\\
|
|
\head~n \defas
|
|
\bl
|
|
\If\;n = 0\;\Then\;\Do\;\Yield~\charlit{\textnil}\\
|
|
\Else\;
|
|
\bl
|
|
\Let\;c \revto \Do\;\Await~\Unit\;\In\\
|
|
\Do\;\Yield~c;\\
|
|
\If\;c = \charlit{\textnil}\;\Then\;\Unit\\
|
|
\Else\;\If\;c = \charlit{\nl}\;\Then\;\head~(n-1)\\
|
|
\Else\;\head~n
|
|
\el
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The function first checks whether more lines need to be processed. If
|
|
$n$ is zero, then it yields the nil character to signify the end of
|
|
stream. This has the effect of ignoring any future instances of
|
|
$\Yield$ in the input stream. Otherwise it awaits a character. Once a
|
|
character has been received the function yields the character in order
|
|
to include it in the output stream. After the yield, it checks whether
|
|
the character was nil in which case the process
|
|
terminates. Alternatively, if the character was a newline the function
|
|
applies itself recursively with $n$ decremented by one. Otherwise it
|
|
applies itself recursively with the original $n$.
|
|
|
|
The $\head$ filter does not transform the shape of its data stream. It
|
|
both awaits and yields a character. However, the awaits and yields
|
|
need not operate on the same type within the same filter, meaning we
|
|
can implement a filter that transforms the shape of the data. Let us
|
|
implement a variation of the GNU coreutil \emph{paste} which merges
|
|
lines of files~\cite[Section~8.2]{MacKenzieMPPBYS20}. Our
|
|
implementation will join characters in its input stream into strings
|
|
separated by spaces and newlines such that the string frequency
|
|
analysis utility need not operate on the low level of characters.
|
|
%
|
|
\[
|
|
\bl
|
|
\paste : \UnitType \to \UnitType \eff \{\Await : \UnitType \opto \Char;\Yield : \String \opto \UnitType\}\\
|
|
\paste\,\Unit \defas
|
|
\bl
|
|
paste'\,\Record{\Do\;\Await~\Unit;\strlit{}}\\
|
|
\where
|
|
\ba[t]{@{~}l@{~}c@{~}l}
|
|
paste'\,\Record{\charlit{\textnil};str} &\defas& \Do\;\Yield~str;\Do\;\Yield~\strlit{\textnil}\\
|
|
paste'\,\Record{\charlit{\nl};str} &\defas& \Do\;\Yield~str;\Do\;\Yield~\strlit{\nl};paste'\,\Record{\Do\;\Await~\Unit;\strlit{}}\\
|
|
paste'\,\Record{\charlit{~};str} &\defas& \Do\;\Yield~str;paste'\,\Record{\Do\;\Await~\Unit;\strlit{}}\\
|
|
paste'\,\Record{c;str} &\defas& paste'\,\Record{\Do\;\Await~\Unit;str \concat [c]}
|
|
|
|
\ea
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The heavy-lifting is delegated to the recursive function $paste'$
|
|
which accepts two parameters: 1) the next character in the input
|
|
stream, and 2) a string buffer for building the output string. The
|
|
function is initially applied to the first character from the stream
|
|
(returned by the invocation of $\Await$) and the empty string
|
|
buffer. The function $paste'$ is defined by pattern matching on the
|
|
character parameter. The first three definitions handle the special
|
|
cases when the received character is nil, newline, and space,
|
|
respectively. If the character is nil, then the function yields the
|
|
contents of the string buffer followed by a string with containing
|
|
only the nil character. If the character is a newline, then the
|
|
function yields the string buffer followed by a string containing the
|
|
newline character. Afterwards the function applies itself recursively
|
|
with the next character from the input stream and an empty string
|
|
buffer. The case when the character is a space is similar to the
|
|
previous case except that it does not yield a newline string. The
|
|
final definition simply concatenates the character onto the string
|
|
buffer and recurses.
|
|
|
|
Another useful filter is the GNU stream editor abbreviated
|
|
\emph{sed}~\cite{PizziniBMG20}. It is an advanced text processing
|
|
editor, whose complete functionality we will not attempt to replicate
|
|
here. We will just implement the ability to replace a string by
|
|
another. This will be useful for normalising the input stream to the
|
|
frequency analysis utility, e.g. decapitalise words, remove unwanted
|
|
characters, etc.
|
|
%
|
|
\[
|
|
\bl
|
|
\sed : \Record{\String;\String} \to \UnitType \eff \{\Await : \UnitType \opto \String;\Yield : \String \opto \UnitType\}\\
|
|
\sed\,\Record{target;str'} \defas
|
|
\bl
|
|
\Let\;str \revto \Do\;\Await~\Unit\;\In\\
|
|
\If\;str = target\;\Then\;\Do\;\Yield~str';\sed\,\Record{target;str'}\\
|
|
\Else\;\Do\;\Yield~str;\sed\,\Record{target;str'}
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The function $\sed$ takes two string arguments. The first argument is
|
|
the string to be replaced in the input stream, and the second argument
|
|
is the replacement. The function first awaits the next string from the
|
|
input stream, then it checks whether the received string is the same
|
|
as $target$ in which case it yields the replacement $str'$ and
|
|
recurses. Otherwise it yields the received string and recurses.
|
|
|
|
Now let us implement the string frequency analysis utility. It work on
|
|
strings and count the occurrences of each string in the input stream.
|
|
%
|
|
\[
|
|
\bl
|
|
\freq : \UnitType \to \UnitType \eff \{\Await : \UnitType \opto \String;\Yield : \List\,\Record{\String;\Int} \opto \UnitType\}\\
|
|
\freq\,\Unit \defas
|
|
\bl
|
|
freq'\,\Record{\Do\;\Await~\Unit;\nil}\\
|
|
\where
|
|
\ba[t]{@{~}l@{~}c@{~}l}
|
|
freq'\,\Record{\strlit{\textnil};tbl} &\defas& \Do\;\Yield~tbl\\
|
|
freq'\,\Record{str;tbl} &\defas&
|
|
\bl
|
|
\Let\;tbl' \revto \faild\,\Record{
|
|
\bl
|
|
\Record{str;1} \cons tbl; \lambda\Unit.\\
|
|
\Let\; sum \revto \lookup\,\Record{str;tbl}\;\In\\
|
|
\modify\,\Record{str;sum+1;tbl}}
|
|
\el\\
|
|
\In\;freq'\,\Record{\Do\;\Await~\Unit;tbl'}
|
|
\el
|
|
\ea
|
|
\el
|
|
\el
|
|
\]
|
|
%
|
|
The auxiliary recursive function $freq'$ implements the analysis. It
|
|
takes two arguments: 1) the next string from the input stream, and 2)
|
|
a table to keep track of how many times each string has occurred. The
|
|
table is implemented as an association list indexed by strings. The
|
|
function is initially applied to the first string from the input
|
|
stream and the empty list. The function is defined by pattern matching
|
|
on the string argument. The first definition handles the case when the
|
|
input stream has been exhausted in which case the function yields the
|
|
table. The other case is responsible for updating the entry associated
|
|
with the string $str$ in the table $tbl$. There are two subcases to
|
|
consider: 1) the string has not been seen before, thus a new entry
|
|
will have to created; or 2) the string already has an entry in the
|
|
table, thus the entry will have to be updated. We handle both cases
|
|
simultaneously by making use of the handler $\faild$, where the
|
|
default value accounts for the first subcase, and the computation
|
|
accounts for the second. The computation attempts to lookup the entry
|
|
associated with $str$ in $tbl$, if the lookup fails then $\faild$
|
|
returns the default value, which is the original table augmented with
|
|
an entry for $str$. If an entry already exists it gets incremented by
|
|
one. The resulting table $tbl'$ is supplied to a recursive application
|
|
of $freq'$.
|
|
|
|
We need one more building block to complete the pipeline. The utility
|
|
$\freq$ returns a value of type $\List~\Record{\String;\Int}$, we need
|
|
a utility to render the value as a string in order to write it to a
|
|
file.
|
|
%
|
|
\[
|
|
\bl
|
|
\printTable : \UnitType \to \UnitType \eff \{\Await : \UnitType \opto \List\,\Record{\String;\Int}\}\\
|
|
\printTable\,\Unit \defas
|
|
\map\,\Record{\lambda\Record{s;i}.s \concat \strlit{:} \concat \intToString~i \concat \strlit{;};\Do\;\Await~\Unit}
|
|
\el
|
|
\]
|
|
%
|
|
The function performs one invocation of $\Await$ to receive the table,
|
|
and then performs a $\map$ over the table. The function argument to
|
|
$\map$ builds a string from the provided string-integer pair.
|
|
%
|
|
Here we make use of an auxiliary function,
|
|
$\intToString : \Int \to \String$, that turns an integer into a
|
|
string. The definition of this function is omitted here for brevity.
|
|
%
|
|
%
|
|
% \[
|
|
% \bl
|
|
% \wc : \UnitType \to \UnitType \eff \{\Await : \UnitType \opto \Char;\Yield : \Int \opto \UnitType\}\\
|
|
% \wc\,\Unit \defas
|
|
% \bl
|
|
% \Do\;\Yield~(wc'\,\Unit)\\
|
|
% \where~
|
|
% \bl
|
|
% wc' \Unit \defas
|
|
% \bl
|
|
% \Let\;c \revto \Do\;\Await~\Unit\;\In\\
|
|
% \If\;c = \charlit{\textnil}\;\Then\;0\\
|
|
% \Else\; 1 + wc'~\Unit
|
|
% \el
|
|
% \el
|
|
% \el
|
|
% \el
|
|
% \]
|
|
%
|
|
|
|
We now have all the building blocks to construct a pipeline for
|
|
performing string frequency analysis on a file. The following performs
|
|
the analysis on the two first lines of Hamlet quote.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\bl
|
|
\runState\,\Record{\dec{fs}_0;\fileIO\,(\lambda\Unit.\\
|
|
\quad\timeshare\,(\lambda\Unit.\\
|
|
\qquad\dec{interruptWrite}\,(\lambda\Unit.\\
|
|
\qquad\quad\sessionmgr\,\Record{\Root;\lambda\Unit.\\
|
|
\qquad\qquad\status\,(\lambda\Unit.
|
|
\ba[t]{@{}l}
|
|
\quoteHamlet~\redirect~\strlit{hamlet};\\
|
|
\Let\;p \revto
|
|
\bl
|
|
~~(\lambda\Unit.\cat~\strlit{hamlet}) \mid (\lambda\Unit.\head~2) \mid \paste\\
|
|
\mid (\lambda\Unit.\sed\,\Record{\strlit{be,};\strlit{be}}) \mid (\lambda\Unit.\sed\,\Record{\strlit{To};\strlit{to}})\\
|
|
\mid (\lambda\Unit.\sed\,\Record{\strlit{question:};\strlit{question}})\\
|
|
\mid \freq \mid \printTable
|
|
\el\\
|
|
\In\;(\lambda\Unit.\echo~(p\,\Unit))~\redirect~\strlit{analysis})})))}
|
|
\ea
|
|
\el \smallskip\\
|
|
\reducesto^+&
|
|
\bl
|
|
\Record{
|
|
\ba[t]{@{}l}
|
|
[0];\\
|
|
\Record{
|
|
\ba[t]{@{}l}
|
|
dir=[\Record{\strlit{analysis};2},\Record{\strlit{hamlet};1},
|
|
\Record{\strlit{stdout};0}];\\
|
|
ilist=[\Record{2;\Record{lno=1;loc=2}},
|
|
\Record{1;\Record{lno=1;loc=1}},
|
|
\Record{0;\Record{lno=1;loc=0}}];\\
|
|
dreg=[
|
|
\ba[t]{@{}l}
|
|
\Record{2;
|
|
\ba[t]{@{}l@{}l}
|
|
\texttt{"}&\texttt{to:2;be:2;or:1;not:1;\nl:2;that:1;is:1}\\
|
|
&\texttt{the:1;question:1;"}},
|
|
\ea\\
|
|
\Record{1;
|
|
\ba[t]{@{}l@{}l}
|
|
\texttt{"}&\texttt{To be, or not to be,\nl{}that is the question:\nl{}}\\
|
|
&\texttt{Whether 'tis nobler in the mind to suffer\nl{}"}},
|
|
\ea\\
|
|
\Record{0; \strlit{}}]; lnext=3; inext=3}}\\
|
|
\ea
|
|
\ea
|
|
\ea\\
|
|
: \Record{\List~\Int; \FileSystem}
|
|
\el
|
|
\ea
|
|
\]
|
|
%
|
|
The pipeline gets bound to the variable $p$. The pipeline starts with
|
|
call to $\cat$ which streams the contents of the file
|
|
$\strlit{hamlet}$ to the process $\head$ applied to $2$, meaning it
|
|
will only forward the first two lines of the file to its
|
|
successor. The third process $\paste$ receives the first two lines one
|
|
character at a time and joins the characters into strings delimited by
|
|
whitespace. The next three instances of $\sed$ perform some string
|
|
normalisation. The first instance removes the trailing comma from the
|
|
string $\strlit{be,}$; the second normalises the capitalisation of the
|
|
word ``to''; and the third removes the trailing colon from the string
|
|
$\strlit{question:}$. The seventh process performs the frequency
|
|
analysis and outputs a table, which is being rendered as a string by
|
|
the eighth process. The output of the pipeline is supplied to the
|
|
$\echo$ utility whose output is being redirected to a file named
|
|
$\strlit{analysis}$. Contents of the file reside in location $2$ in
|
|
the data region. Here we can see that the analysis has found that the
|
|
words ``to'', ``be'', and the newline character ``$\nl$'' appear two
|
|
times each, whilst the other words appear once each.
|
|
|
|
\section{Parameterised handlers}
|
|
\label{sec:unary-parameterised-handlers}
|
|
|
|
Parameterised handlers are a variation of ordinary deep handlers with
|
|
an embedded functional state cell. This state cell is only accessible
|
|
locally within the handler. The use of state within the handler is
|
|
opaque to both the ambient context and the context of the computation
|
|
being handled. Semantically, parameterised handlers are defined as
|
|
folds with state threading over computation trees.
|
|
|
|
We take the deep handler calculus $\HCalc$ as our starting point and
|
|
extend it with parameterised handlers to yield the calculus $\HPCalc$.
|
|
|
|
\subsection{Syntax and static semantics}
|
|
In addition to a computation, a parameterised handler also take a
|
|
value as argument. This argument is the initial value of the state
|
|
cell embedded inside the handler.
|
|
%
|
|
\begin{syntax}
|
|
\slab{Handler\textrm{ }types} & F &::=& \cdots \mid \Record{C; A} \Rightarrow^\param D\\
|
|
\slab{Computations} & M,N &::=& \cdots \mid \ParamHandle\; M \;\With\; H^\param(W)\\
|
|
\slab{Parameterised\textrm{ }definitions} & H^\param &::=& q^A.~H
|
|
\end{syntax}
|
|
%
|
|
Figure~\ref{fig:param-syntax} extends the syntax of
|
|
$\HCalc$ with parameterised handlers. Syntactically a parameterised
|
|
handler is new binding form $(q^A.~H)$, where $q$ is the name of the
|
|
parameter, whose type is $A$. The name is bound in the ordinary
|
|
handler definition $H$. The elimination form
|
|
($\ParamHandle\; M\;\With\;H^\param(W)$) is similar to the form for
|
|
ordinary deep handlers, except that the parameterised handler
|
|
definition is applied to a value $W$, which is the initial value of
|
|
the parameter $q$.
|
|
|
|
%
|
|
\begin{mathpar}
|
|
% Handle
|
|
\inferrule*[Lab=\tylab{Handle^\param}]
|
|
{
|
|
% \typ{\Gamma}{V : A} \\
|
|
\typ{\Gamma}{M : C} \\
|
|
\typ{\Gamma}{W : A} \\
|
|
\typ{\Gamma}{H^\param : \Record{C; A} \Harrow^\param D}
|
|
}
|
|
{\Gamma \vdash \ParamHandle \; M \; \With\; H^\param(W) : D}
|
|
|
|
% Parameterised handler
|
|
\inferrule*[Lab=\tylab{Handler^\param}]
|
|
{{\bl
|
|
C = A \eff \{(\ell_i : A_i \to B_i)_i; R\} \\
|
|
D = B \eff \{(\ell_i : P)_i; R\} \\
|
|
H = \{\Return\;x \mapsto M\} \uplus \{ \OpCase{\ell_i}{p_i}{r_i} \mapsto N_i \}_i
|
|
\el}\\\\
|
|
\typ{\Delta;\Gamma, q : A', x : A}{M : D}\\\\
|
|
[\typ{\Delta;\Gamma,q : A', p_i : A_i, r_i : \Record{B_i;A'} \to D}{N_i : D}]_i
|
|
}
|
|
{\typ{\Delta;\Gamma}{(q^{A'} . H) : \Record{C;A'} \Harrow^\param D}}
|
|
\end{mathpar}
|
|
%%
|
|
We require two additional rules to type parameterised handlers. The
|
|
rules are given in Figure~\ref{fig:param-static-semantics}. The main
|
|
differences between the \tylab{Handler} and \tylab{Handler^\param} are
|
|
that in the latter the return and operation cases are typed with
|
|
respect to the parameter $q$, and that resumptions $r$ have type
|
|
$\Record{B_\ell;A'} \to D$, that is they accept a pair as
|
|
input.
|
|
|
|
\subsection{Dynamic semantics}
|
|
Operationally, a parameterised resumption uses the first component as
|
|
the return value of the operation, and the second component as the
|
|
updated value of the handler parameter $q$.
|
|
%
|
|
This operational behaviour is formalised by following reduction rule
|
|
$\semlab{Op^\param}$.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\ParamHandle \; \EC[\Do \; \ell \; V] \; \With \; (q.~H)(W)\\
|
|
\reducesto&
|
|
N[V/p,W/q,\lambda \Record{y;q'}.\Handle \; \EC[\Return \; y] \; \With \; (q.~H)(q')/r]\\
|
|
& \text{ where } \ell \notin BL(\EC) \text{ and } \hell = \{ \OpCase{\ell}{p}{r} \mapsto N \}
|
|
\ea
|
|
\]
|
|
%
|
|
The parameter value $W$ is substituted for the parameter name $q$ into
|
|
the operation case body $N$. As with ordinary deep handlers, the
|
|
resumption rewraps its handler, but with the slight twist that the
|
|
parameterised handler definition is applied to the updated parameter
|
|
value $q'$ rather than the original value $W$. The reduction rule for
|
|
handling the return of a computation is as follows.
|
|
%
|
|
\[
|
|
\ParamHandle \, (\Return \; V) \; \With \; (q.~H)(W) \reducesto N[V/x,W/q], \text{where } \hret = \{ \Return \; x \mapsto N \}
|
|
\]
|
|
%
|
|
Both the return value $V$ and the parameter value $W$ are substituted
|
|
into the return case body $N$ for their respective binders.
|
|
|
|
\subsection{Lightweight concurrency}
|
|
|
|
\begin{example}[Green threads]
|
|
\dhil{Example: Lightweight threads}
|
|
\end{example}
|
|
|
|
% \section{Default handlers}
|
|
% \label{sec:unary-default-handlers}
|
|
|
|
% \chapter{N-ary handlers}
|
|
% \label{ch:multi-handlers}
|
|
|
|
% \section{Syntax and Static Semantics}
|
|
% \section{Dynamic Semantics}
|
|
% \section{Unifying deep and shallow handlers}
|
|
|
|
\section{Related work}
|
|
\label{sec:unix-related-work}
|
|
|
|
\subsection{Interleaving computation}
|
|
|
|
\paragraph{The resumption monad} \citet{Milner75},
|
|
\citet{Plotkin76}, \citet{Moggi90}, \citet{Papaspyrou01}, \citet{Harrison06}, \citet{AtkeyJ15}
|
|
|
|
\paragraph{Continuation-based interleaving}
|
|
First implementation of `threads' is due to \citet{Burstall69}. \citet{Wand80} \citet{HaynesF84} \citet{GanzFW99} \citet{HiebD90}
|
|
|
|
\subsection{Effect-driven concurrency}
|
|
\citet{BauerP15}, \citet{DolanWSYM15}, \citet{Hillerstrom16}, \citet{DolanEHMSW17}, \citet{Convent17}, \citet{Poulson20}
|
|
|
|
\part{Implementation}
|
|
|
|
\chapter{Continuation-passing style}
|
|
\label{ch:cps}
|
|
|
|
Continuation-passing style (CPS) is a \emph{canonical} program
|
|
notation that makes every facet of control flow and data flow
|
|
explicit. In CPS every function takes an additional function-argument
|
|
called the \emph{continuation}, which represents the next computation
|
|
in evaluation position. CPS is canonical in the sense that it is
|
|
definable in pure $\lambda$-calculus without any further
|
|
primitives. As an informal illustration of CPS consider again the
|
|
rudimentary factorial function from Section~\ref{sec:tracking-div}.
|
|
%
|
|
\[
|
|
\bl
|
|
\dec{fac} : \Int \to \Int\\
|
|
\dec{fac} \defas \lambda n.
|
|
\ba[t]{@{}l}
|
|
\Let\;is\_zero \revto n = 0\;\In\\
|
|
\If\;is\_zero\;\Then\; \Return\;1\\
|
|
\Else\;\ba[t]{@{~}l}
|
|
\Let\; n' \revto n - 1 \;\In\\
|
|
\Let\; m \revto f~n' \;\In\\
|
|
n * m
|
|
\ea
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
The above implementation of the function $\dec{fac}$ is given in
|
|
direct-style fine-grain call-by-value. In CPS notation the
|
|
implementation of this function changes as follows.
|
|
%
|
|
\[
|
|
\bl
|
|
\dec{fac}_{\dec{cps}} : \Int \to (\Int \to \alpha) \to \alpha\\
|
|
\dec{fac}_{\dec{cps}} \defas \lambda n.\lambda k.
|
|
(=_{\dec{cps}})~n~0~
|
|
(\lambda is\_zero.
|
|
\ba[t]{@{~}l}
|
|
\If\;is\_zero\;\Then\; k~1\\
|
|
\Else\;
|
|
(-_{\dec{cps}})~n~1~
|
|
(\lambda n'.
|
|
\dec{fac}_{\dec{cps}}~n'~
|
|
(\lambda m. (*_{\dec{cps}})~n~m~k)))
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
There are several worthwhile observations to make about the
|
|
differences between the two implementations $\dec{fac}$ and
|
|
$\dec{fac}_{\dec{cps}}$.
|
|
%
|
|
Firstly note that their type signatures differ. The CPS version has an
|
|
additional formal parameter of type $\Int \to \alpha$ which is the
|
|
continuation. By convention the continuation parameter is named $k$ in
|
|
the implementation. The continuation captures the remainder of
|
|
computation that ultimately produces a result of type $\alpha$, or put
|
|
differently: it determines what to do with the result returned by an
|
|
invocation of $\dec{fac}_{\dec{cps}}$. Semantically the continuation corresponds
|
|
to the surrounding evaluation
|
|
context.
|
|
%
|
|
Secondly note that every $\Let$-binding in $\dec{fac}$ has become a
|
|
function application in $\dec{fac}_{\dec{cps}}$. The functions
|
|
$=_{\dec{cps}}$, $-_{\dec{cps}}$, and $*_{\dec{cps}}$ denote the CPS
|
|
versions of equality testing, subtraction, and multiplication
|
|
respectively. Moreover, the explicit $\Return~1$ in the true branch
|
|
has been turned into an application of continuation $k$, and the
|
|
implicit return $n*m$ in the $\Else$-branch has been turned into an
|
|
explicit application of the continuation.
|
|
%
|
|
Thirdly note every function application occurs in tail position. This
|
|
is a characteristic property of CPS that makes CPS feasible as a
|
|
practical implementation strategy since programs in CPS notation do
|
|
not consume stack space.
|
|
%
|
|
\dhil{The focus of the introduction should arguably not be to explain CPS.}
|
|
\dhil{Justify CPS as an implementation technique}
|
|
\dhil{Give a side-by-side reduction example of $\dec{fac}$ and $\dec{fac}_{\dec{cps}}$.}
|
|
\dhil{Define desirable properties of a CPS translation: properly tail-recursive, no static administrative redexes}
|
|
%
|
|
\begin{definition}[Properly tail-recursive~\cite{Danvy06}]
|
|
%
|
|
A CPS translation $\cps{-}$ is properly tail-recursive if the
|
|
continuation of every CPS transformed tail call $\cps{V\,W}$ within
|
|
$\cps{\lambda x.M}$ is $k$, where
|
|
\begin{equations}
|
|
\cps{\lambda x.M} &=& \lambda x.\lambda k.\cps{M}\\
|
|
\cps{V\,W} &=& \cps{V}\,\cps{W}\,k.
|
|
\end{equations}
|
|
\end{definition}
|
|
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
\pcps{(\lambda x.(\lambda y.\Return\;y)\,x)\,\Unit} &= (\lambda x.(\lambda y.\lambda k.k\,y)\,x)\,\Unit\,(\lambda x.x)\\
|
|
&\reducesto ((\lambda y.\lambda k.k\,y)\,\Unit)\,(\lambda x.x)\\
|
|
&\reducesto (\lambda k.k\,\Unit)\,(\lambda x.x)\\
|
|
&\reducesto (\lambda x.x)\,\Unit\\
|
|
&\reducesto \Unit
|
|
\ea
|
|
\]
|
|
|
|
\section{Initial target calculus}
|
|
\label{sec:target-cps}
|
|
|
|
The syntax, semantics, and syntactic sugar for the target calculus
|
|
$\UCalc$ is given in Figure~\ref{fig:cps-cbv-target}. The calculus
|
|
largely amounts to an untyped variation of $\BCalc$, specifically
|
|
we retain the syntactic distinction between values ($V$) and
|
|
computations ($M$).
|
|
%
|
|
The values ($V$) comprise lambda abstractions ($\lambda x.M$),
|
|
% recursive functions ($\Rec\,g\,x.M$),
|
|
empty tuples ($\Record{}$), pairs ($\Record{V,W}$), and first-class
|
|
labels ($\ell$).
|
|
%
|
|
Computations ($M$) comprise values ($V$), applications ($M~V$), pair
|
|
elimination ($\Let\; \Record{x, y} = V \;\In\; N$), label elimination
|
|
($\Case\; V \;\{\ell \mapsto M; x \mapsto N\}$), and explicit marking
|
|
of unreachable code ($\Absurd$). A key difference from $\BCalcRec$ is
|
|
that the function position of an application is allowed to be a
|
|
computation (i.e., the application form is $M~W$ rather than
|
|
$V~W$). Later, when we refine the initial CPS translation we will be
|
|
able to rule out this relaxation.
|
|
|
|
We give a standard small-step evaluation context-based reduction
|
|
semantics. Evaluation contexts comprise the empty context and function
|
|
application.
|
|
|
|
To make the notation more lightweight, we define syntactic sugar for
|
|
variant values, record values, list values, let binding, variant
|
|
eliminators, and record eliminators. We use pattern matching syntax
|
|
for deconstructing variants, records, and lists. For desugaring
|
|
records, we assume a failure constant $\ell_\bot$ (e.g. a divergent
|
|
term) to cope with the case of pattern matching failure.
|
|
|
|
\begin{figure}
|
|
\flushleft
|
|
\textbf{Syntax}
|
|
\begin{syntax}
|
|
\slab{Values} &U, V, W \in \UValCat &::= & x \mid \lambda x.M \mid % \Rec\,g\,x.M
|
|
\mid \Record{} \mid \Record{V, W} \mid \ell
|
|
\smallskip \\
|
|
\slab{Computations} &M,N \in \UCompCat &::= & V \mid M\,W \mid \Let\; \Record{x,y} = V \; \In \; N\\
|
|
& &\mid& \Case\; V\, \{\ell \mapsto M; y \mapsto N\} \mid \Absurd\,V
|
|
\smallskip \\
|
|
\slab{Evaluation contexts} &\EC \in \UEvalCat &::= & [~] \mid \EC\;W \\
|
|
\end{syntax}
|
|
|
|
\textbf{Reductions}
|
|
\begin{reductions}
|
|
\usemlab{App} & (\lambda x . \, M) V &\reducesto& M[V/x] \\
|
|
% \usemlab{Rec} & (\Rec\,g\,x.M) V &\reducesto& M[\Rec\,g\,x.M/g,V/x]\\
|
|
\usemlab{Split} & \Let \; \Record{x,y} = \Record{V,W} \; \In \; N &\reducesto& N[V/x,W/y] \\
|
|
\usemlab{Case_1} &
|
|
\Case \; \ell \; \{ \ell \mapsto M; y \mapsto N\} &\reducesto& M \\
|
|
\usemlab{Case_2} &
|
|
\Case \; \ell \; \{ \ell' \mapsto M; y \mapsto N\} &\reducesto& N[\ell/y], \hfill\quad \text{if } \ell \neq \ell' \\
|
|
\usemlab{Lift} &
|
|
\EC[M] &\reducesto& \EC[N], \hfill \text{if } M \reducesto N \\
|
|
\end{reductions}
|
|
|
|
\textbf{Syntactic sugar}
|
|
\[
|
|
\begin{eqs}
|
|
\Let\;x=V\;\In\;N &\equiv & N[V/x]\\
|
|
\ell \; V & \equiv & \Record{\ell; V}\\
|
|
\Record{} & \equiv & \ell_{\Record{}} \\
|
|
\Record{\ell = V; W} & \equiv & \Record{\ell, \Record{V, W}}\\
|
|
\nil &\equiv & \ell_{\nil} \\
|
|
V \cons W & \equiv & \Record{\ell_{\cons}, \Record{V, W}}\\
|
|
\Case\;V\;\{\ell\;x \mapsto M; y \mapsto N \} &\equiv&
|
|
\ba[t]{@{~}l}
|
|
\Let\;y = V\;\In\; \Let\;\Record{z,x} = y\;\In \\
|
|
\Case\; z\;\{ \ell \mapsto M; z' \mapsto N \}
|
|
\ea\\
|
|
\Let\; \Record{\ell=x;y} = V\;\In\;N &\equiv&
|
|
\ba[t]{@{~}l}
|
|
\Let\; \Record{z,z'} = V\;\In\;\Let\; \Record{x,y} = z'\;\In \\
|
|
\Case\;z\;\{\ell \mapsto N; z'' \mapsto \ell_\bot \}
|
|
\ea
|
|
\end{eqs}
|
|
\]
|
|
|
|
\caption{Untyped target calculus for the CPS translations.}
|
|
\label{fig:cps-cbv-target}
|
|
\end{figure}
|
|
|
|
\dhil{Most of the primitives are Church encodable. Discuss the value
|
|
of treating them as primitive rather than syntactic sugar (target
|
|
languages such as JavaScript has similar primitives).}
|
|
|
|
\section{CPS transform for fine-grain call-by-value}
|
|
\label{sec:cps-cbv}
|
|
|
|
We start by giving a CPS translation of $\BCalc$ in
|
|
Figure~\ref{fig:cps-cbv}. Fine-grain call-by-value admits a
|
|
particularly simple CPS translation due to the separation of values
|
|
and computations. All constructs from the source language are
|
|
translated homomorphically into the target language $\UCalc$, except
|
|
for $\Return$ and $\Let$ (and type abstraction because the translation
|
|
performs type erasure). Lifting a value $V$ to a computation
|
|
$\Return~V$ is interpreted by passing the value to the current
|
|
continuation $k$. Sequencing computations with $\Let$ is translated by
|
|
applying the translation of $M$ to the translation of the continuation
|
|
$N$, which is ultimately applied to the current continuation $k$. In
|
|
addition, we explicitly $\eta$-expand the translation of a type
|
|
abstraction in order to ensure that value terms in the source calculus
|
|
translate to value terms in the target.
|
|
|
|
\begin{figure}
|
|
\flushleft
|
|
\textbf{Values} \\
|
|
\[
|
|
\bl
|
|
|
|
\begin{eqs}
|
|
\cps{-} &:& \ValCat \to \UValCat\\
|
|
\cps{x} &=& x \\
|
|
\cps{\lambda x.M} &=& \lambda x.\cps{M} \\
|
|
\cps{\Lambda \alpha.M} &=& \lambda k.\cps{M}~k \\
|
|
% \cps{\Rec\,g\,x.M} &=& \Rec\,g\,x.\cps{M}\\
|
|
\cps{\Record{}} &=& \Record{} \\
|
|
\cps{\Record{\ell = V; W}} &=& \Record{\ell = \cps{V}; \cps{W}} \\
|
|
\cps{\ell~V} &=& \ell~\cps{V} \\
|
|
\end{eqs}
|
|
\el
|
|
\]
|
|
\textbf{Computations}
|
|
\[
|
|
\bl
|
|
\begin{eqs}
|
|
\cps{-} &:& \CompCat \to \UCompCat\\
|
|
\cps{V\,W} &=& \cps{V}\,\cps{W} \\
|
|
\cps{V\,T} &=& \cps{V} \\
|
|
\cps{\Let\; \Record{\ell=x;y} = V \; \In \; N} &=& \Let\; \Record{\ell=x;y} = \cps{V} \; \In \; \cps{N} \\
|
|
\cps{\Case~V~\{\ell~x \mapsto M; y \mapsto N\}} &=&
|
|
\Case~\cps{V}~\{\ell~x \mapsto \cps{M}; y \mapsto \cps{N}\} \\
|
|
\cps{\Absurd~V} &=& \Absurd~\cps{V} \\
|
|
\cps{\Return~V} &=& \lambda k.k\,\cps{V} \\
|
|
\cps{\Let~x \revto M~\In~N} &=& \lambda k.\cps{M}(\lambda x.\cps{N}\,k) \\
|
|
\end{eqs}
|
|
\el
|
|
\]
|
|
\caption{First-order CPS translation of $\BCalc$.}
|
|
\label{fig:cps-cbv}
|
|
\end{figure}
|
|
|
|
\section{CPS transforming deep effect handlers}
|
|
\label{sec:fo-cps}
|
|
|
|
The translation of a computation term by the basic CPS translation in
|
|
Section~\ref{sec:cps-cbv} takes a single continuation parameter that
|
|
represents the context.
|
|
%
|
|
In the presence of effect handlers in the source language, it becomes
|
|
necessary to keep track of two kinds of contexts in which each
|
|
computation executes: a \emph{pure context} that tracks the state of
|
|
pure computation in the scope of the current handler, and an
|
|
\emph{effect context} that describes how to handle operations in the
|
|
scope of the current handler.
|
|
%
|
|
Correspondingly, we have both \emph{pure continuations} ($k$) and
|
|
\emph{effect continuations} ($h$).
|
|
%
|
|
As handlers can be nested, each computation executes in the context of
|
|
a \emph{stack} of pairs of pure and effect continuations.
|
|
|
|
On entry into a handler, the pure continuation is initialised to a
|
|
representation of the return clause and the effect continuation to a
|
|
representation of the operation clauses. As pure computation proceeds,
|
|
the pure continuation may grow, for example when executing a
|
|
$\Let$. If an operation is encountered then the effect continuation is
|
|
invoked.
|
|
%
|
|
The current continuation pair ($k$, $h$) is packaged up as a
|
|
\emph{resumption} and passed to the current handler along with the
|
|
operation and its argument. The effect continuation then either
|
|
handles the operation, invoking the resumption as appropriate, or
|
|
forwards the operation to an outer handler. In the latter case, the
|
|
resumption is modified to ensure that the context of the original
|
|
operation invocation can be reinstated when the resumption is invoked.
|
|
%
|
|
|
|
\subsection{Curried translation}
|
|
\label{sec:first-order-curried-cps}
|
|
|
|
We first consider a curried CPS translation that extends the
|
|
translation of Figure~\ref{fig:cps-cbv}. The extension to operations
|
|
and handlers is localised to the additional features because currying
|
|
conveniently lets us get away with a shift in interpretation: rather
|
|
than accepting a single continuation, translated computation terms now
|
|
accept an arbitrary even number of arguments representing the stack of
|
|
pure and effect continuations. Thus, we can conservatively extend the
|
|
translation in Figure~\ref{fig:cps-cbv} to cover $\HCalc$, where we
|
|
imagine there being some number of extra continuation arguments that
|
|
have been $\eta$-reduced. The translation of operations and handlers
|
|
is as follows.
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \CompCat \to \UCompCat\\
|
|
\cps{\Do\;\ell\;V} &\defas& \lambda k.\lambda h.h~\Record{\ell,\Record{\cps{V}, \lambda x.k~x~h}} \\
|
|
\cps{\Handle \; M \; \With \; H} &\defas& \cps{M}~\cps{\hret}~\cps{\hops} \medskip\\
|
|
\cps{-} &:& \HandlerCat \to \UCompCat\\
|
|
\cps{\{ \Return \; x \mapsto N \}} &\defas& \lambda x . \lambda h . \cps{N} \\
|
|
\cps{\{ \ell~p~r \mapsto N_\ell \}_{\ell \in \mathcal{L}}}
|
|
&\defas&
|
|
\lambda \Record{z,\Record{p,r}}. \Case~z~
|
|
\{ (\ell \mapsto \cps{N_\ell})_{\ell \in \mathcal{L}}; y \mapsto \hforward(y,p,r) \} \\
|
|
\hforward(y,p,r) &\defas& \lambda k. \lambda h. h\,\Record{y,\Record{p, \lambda x.\,r\,x\,k\,h}}
|
|
\end{equations}
|
|
%
|
|
The translation of $\Do\;\ell\;V$ abstracts over the current pure
|
|
($k$) and effect ($h$) continuations passing an encoding of the
|
|
operation into the latter. The operation is encoded as a triple
|
|
consisting of the name $\ell$, parameter $\cps{V}$, and resumption
|
|
$\lambda x.k~x~h$, which passes the same effect continuation $h$ to
|
|
ensure deep handler semantics.
|
|
|
|
The translation of $\Handle~M~\With~H$ invokes the translation of $M$
|
|
with new pure and effect continuations for the return and operation
|
|
clauses of $H$.
|
|
%
|
|
The translation of a return clause is a term which garbage collects
|
|
the current effect continuation $h$.
|
|
%
|
|
The translation of a set of operation clauses is a function which
|
|
dispatches on encoded operations, and in the default case forwards to
|
|
an outer handler.
|
|
%
|
|
In the forwarding case, the resumption is extended by the parent
|
|
continuation pair to ensure that an eventual invocation of the
|
|
resumption reinstates the handler stack.
|
|
|
|
The translation of complete programs feeds the translated term the
|
|
identity pure continuation (which discards its handler argument), and
|
|
an effect continuation that is never intended to be called.
|
|
%
|
|
\begin{equations}
|
|
\pcps{-} &:& \CompCat \to \UCompCat\\
|
|
\pcps{M} &\defas& \cps{M}~(\lambda x.\lambda h.x)~(\lambda \Record{z,\_}.\Absurd~z) \\
|
|
\end{equations}
|
|
%
|
|
Conceptually, this translation encloses the translated program in a
|
|
top-level handler with an empty collection of operation clauses and an
|
|
identity return clause.
|
|
|
|
A pleasing property of this particular CPS translation is that it is a
|
|
conservative extension to the CPS translation for $\BCalc$. Alas, this
|
|
translation also suffers two displeasing properties which makes it
|
|
unviable in practice.
|
|
|
|
\begin{enumerate}
|
|
\item The image of the translation is not \emph{properly
|
|
tail-recursive}~\citep{DanvyF92,Steele78}, and as a result the
|
|
image is not stackless, meaning it cannot readily be used as the
|
|
basis for an implementation. This deficiency is essentially due to
|
|
the curried representation of the continuation stack.
|
|
|
|
\item The image of the translation yields static administrative
|
|
redexes, i.e. redexes that could be reduced statically. This is a
|
|
classic problem with CPS translations. This problem can be dealt
|
|
with by introducing a second pass to clean up the
|
|
image~\cite{Plotkin75}. By clever means the clean up pass and the
|
|
translation pass can be fused together to make an one-pass
|
|
translation~\cite{DanvyF92,DanvyN03}.
|
|
\end{enumerate}
|
|
|
|
The following minimal example readily illustrates both issues.
|
|
%
|
|
\begin{align*}
|
|
\pcps{\Return\;\Record{}}
|
|
= & (\lambda k.k\,\Record{})\,(\lambda x.\lambda h.x)\,(\lambda \Record{z,\_}.\Absurd\,z) \\
|
|
\reducesto& ((\lambda x.\lambda h.x)\,\Record{})\,(\lambda \Record{z,\_}.\Absurd\,z) \numberthis\label{eq:cps-admin-reduct-1}\\
|
|
\reducesto& (\lambda h.\Record{})\,(\lambda \Record{z,\_}.\Absurd\,z) \numberthis\label{eq:cps-admin-reduct-2}\\
|
|
\reducesto& \Record{}
|
|
\end{align*}
|
|
%
|
|
The second and third reductions simulate handling $\Return\;\Record{}$
|
|
at the top level. The second reduction partially applies the curried
|
|
function term $\lambda x.\lambda h.x$ to $\Record{}$, which must
|
|
return a value such that the third reduction can be
|
|
applied. Consequently, evaluation is not tail-recursive.
|
|
%
|
|
The lack of tail-recursion is also apparent in our relaxation of
|
|
fine-grain call-by-value in Figure~\ref{fig:cps-cbv-target} as the
|
|
function position of an application can be a computation.
|
|
%
|
|
In Section~\ref{sec:first-order-uncurried-cps} we will refine this
|
|
translation to be properly tail-recursive.
|
|
%
|
|
As for administrative redexes, observe that the first reduction is
|
|
administrative. It is an artefact introduced by the translation, and
|
|
thus it has nothing to do with the dynamic semantics of the original
|
|
term. We can eliminate such redexes statically. We will address this
|
|
issue in Section~\ref{sec:higher-order-uncurried-deep-handlers-cps}.
|
|
|
|
Nevertheless, we can show that the image of this CPS translation
|
|
simulates the preimage. Due to the presence of administrative
|
|
reductions, the simulation is not on the nose, but instead up to
|
|
congruence.
|
|
%
|
|
For reduction in the untyped target calculus we write
|
|
$\reducesto_{\textrm{cong}}$ for the smallest relation containing
|
|
$\reducesto$ that is closed under the term formation constructs.
|
|
%
|
|
\begin{theorem}[Simulation]
|
|
\label{thm:fo-simulation}
|
|
If $M \reducesto N$ then $\pcps{M} \reducesto_{\textrm{cong}}^+
|
|
\pcps{N}$.
|
|
\end{theorem}
|
|
|
|
\begin{proof}
|
|
The result follows by composing a call-by-value variant of
|
|
\citeauthor{ForsterKLP19}'s translation from effect handlers to
|
|
delimited continuations~\citeyearpar{ForsterKLP19} with
|
|
\citeauthor{MaterzokB12}'s CPS translation for delimited
|
|
continuations~\citeyearpar{MaterzokB12}.
|
|
\end{proof}
|
|
|
|
% \paragraph*{Remark}
|
|
% We originally derived this curried CPS translation for effect handlers
|
|
% by composing \citeauthor{ForsterKLP17}'s translation from effect
|
|
% handlers to delimited continuations~\citeyearpar{ForsterKLP17} with
|
|
% \citeauthor{MaterzokB12}'s CPS translation for delimited
|
|
% continuations~\citeyearpar{MaterzokB12}.
|
|
|
|
\subsection{Uncurried translation}
|
|
\label{sec:first-order-uncurried-cps}
|
|
%
|
|
%
|
|
\begin{figure}
|
|
\flushleft
|
|
\textbf{Syntax}
|
|
\begin{syntax}
|
|
\slab{Computations} &M,N \in \UCompCat &::= & \cdots \mid \XCancel{M\,W} \mid V\,W \mid U\,V\,W \smallskip \\
|
|
\XCancel{\slab{Evaluation contexts}} &\XCancel{\EC \in \UEvalCat} &::= & \XCancel{[~] \mid \EC\;W} \\
|
|
\end{syntax}
|
|
|
|
\textbf{Reductions}
|
|
\begin{reductions}
|
|
\usemlab{App_1} & (\lambda x . M) V &\reducesto& M[V/x] \\
|
|
\usemlab{App_2} & (\lambda x . \lambda y. \, M) V\, W &\reducesto& M[V/x,W/y] \\
|
|
\XCancel{\usemlab{Lift}} & \XCancel{\EC[M]} &\reducesto& \XCancel{\EC[N], \hfill \text{if } M \reducesto N}
|
|
\end{reductions}
|
|
\caption{Adjustments to the syntax and semantics of $\UCalc$.}
|
|
\label{fig:refined-cps-cbv-target}
|
|
\end{figure}
|
|
%
|
|
In this section we will refine the CPS translation for deep handlers
|
|
to make it properly tail-recursive. As remarked in the previous
|
|
section, the lack of tail-recursion is apparent in the syntax of the
|
|
target calculus $\UCalc$ as it permits an arbitrary computation term
|
|
in the function position of an application term.
|
|
%
|
|
|
|
As a first step we may restrict the syntax of the target calculus such
|
|
that the term in function position must be a value. With this
|
|
restriction the syntax of $\UCalc$ implements the property that any
|
|
term constructor features at most one computation term, and this
|
|
computation term always appears in tail position. Thus this
|
|
restriction suffices to ensure that every function application will be
|
|
in tail position.
|
|
%
|
|
Figure~\ref{fig:refined-cps-cbv-target} contains the adjustments to
|
|
syntax and semantics of $\UCalc$. The target calculus now supports
|
|
both unary and binary application forms. As we shall see shortly,
|
|
binary application turns out be convenient when we enrich the notion
|
|
of continuation. Both application forms are comprised only of value
|
|
terms. As a result the dynamic semantics of $\UCalc$ no longer makes
|
|
use of evaluation contexts, hence we remove them altogether. The
|
|
reduction rule $\usemlab{App_1}$ applies to unary application and it
|
|
is the same as the $\usemlab{App}$-rule in
|
|
Figure~\ref{fig:cps-cbv-target}. The new $\usemlab{App_2}$-rule
|
|
applies to binary application: it performs a simultaneous substitution
|
|
of the arguments $V$ and $W$ for the parameters $x$ and $y$,
|
|
respectively, in the function body $M$.
|
|
%
|
|
|
|
These changes to $\UCalc$ immediately invalidate the curried
|
|
translation from the previous section as the image of the translation
|
|
is no longer well-formed.
|
|
%
|
|
The crux of the problem is that the curried interpretation of
|
|
continuations causes the CPS translation to produce `large'
|
|
application terms, e.g. the translation rule for effect forwarding
|
|
produces a three-argument application term.
|
|
%
|
|
To rectify this problem we can adapt the technique of
|
|
\citet{MaterzokB12} to uncurry our CPS translation. Uncurrying
|
|
necessitates a change of representation for continuations: a
|
|
continuation is now an alternating list of pure continuation functions
|
|
and effect continuation functions. Thus, we move to an explicit
|
|
representation of the runtime handler stack.
|
|
%
|
|
The change of continuation representation means the CPS translation
|
|
for effect handlers is no longer a conservative extension. The
|
|
translation is adjusted as follows to account for the new
|
|
representation of continuations.
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \CompCat \to \UCompCat\\
|
|
\cps{\Return~V} &\defas& \lambda (k \cons ks).k\,\cps{V}\,ks \\
|
|
\cps{\Let~x \revto M~\In~N} &\defas& \lambda (k \cons ks).\cps{M}((\lambda x.\lambda ks'.\cps{N}(k \cons ks')) \cons ks)
|
|
\smallskip \\
|
|
\cps{\Do\;\ell\;V} &\defas& \lambda (k \cons h \cons ks).h\,\Record{\ell,\Record{\cps{V}, \lambda x.\lambda ks'.k\,x\,(h \cons ks')}}\,ks
|
|
\smallskip \\
|
|
\cps{\Handle \; M \; \With \; H} &\defas& \lambda ks . \cps{M} (\cps{\hret} \cons \cps{\hops} \cons ks) \medskip\\
|
|
\cps{-} &:& \HandlerCat \to \UCompCat\\
|
|
\cps{\{\Return \; x \mapsto N\}} &\defas& \lambda x.\lambda ks.\Let\; (h \cons ks') = ks \;\In\; \cps{N}\,ks'
|
|
\\
|
|
\cps{\{\ell \; p \; r \mapsto N_\ell\}_{\ell \in \mathcal{L}}}
|
|
&\defas&
|
|
\bl
|
|
\lambda \Record{z,\Record{p,r}}. \lambda ks. \Case \; z \;
|
|
\{( \bl\ell \mapsto \cps{N_\ell}\,ks)_{\ell \in \mathcal{L}};\,\\
|
|
y \mapsto \hforward((y,p,r),ks) \}\el \\
|
|
\el \\
|
|
\hforward((y,p,r),ks) &\defas& \bl
|
|
\Let\; (k' \cons h' \cons ks') = ks \;\In\; \\
|
|
h'\,\Record{y, \Record{p, \lambda x.\lambda ks''.\,r\,x\,(k' \cons h' \cons ks'')}}\,ks'\\
|
|
\el \medskip\\
|
|
\pcps{-} &:& \CompCat \to \UCompCat\\
|
|
\pcps{M} &\defas& \cps{M}~((\lambda x.\lambda ks.x) \cons (\lambda \Record{z,\Record{p,r}}. \lambda ks.\,\Absurd~z) \cons \nil)
|
|
\end{equations}
|
|
%
|
|
The other cases are as in the original CPS translation in
|
|
Figure~\ref{fig:cps-cbv}.
|
|
%
|
|
Since we now use a list representation for the stacks of
|
|
continuations, we have had to modify the translations of all the
|
|
constructs that manipulate continuations. For $\Return$ and $\Let$, we
|
|
extract the top continuation $k$ and manipulate it analogously to the
|
|
original translation in Figure~\ref{fig:cps-cbv}. For $\Do$, we
|
|
extract the top pure continuation $k$ and effect continuation $h$ and
|
|
invoke $h$ in the same way as the curried translation, except that we
|
|
explicitly maintain the stack $ks$ of additional continuations. The
|
|
translation of $\Handle$, however, pushes a continuation pair onto the
|
|
stack instead of supplying them as arguments. Handling of operations
|
|
is the same as before, except for explicit passing of the
|
|
$ks$. Forwarding now pattern matches on the stack to extract the next
|
|
continuation pair, rather than accepting them as arguments.
|
|
%
|
|
% Proper tail recursion coincides with a refinement of the target
|
|
% syntax. Now applications are either of the form $V\,W$ or of the form
|
|
% $U\,V\,W$. We could also add a rule for applying a two argument lambda
|
|
% abstraction to two arguments at once and eliminate the
|
|
% $\usemlab{Lift}$ rule, but we defer this until our higher order
|
|
% translation in Section~\ref{sec:higher-order-uncurried-cps}.
|
|
|
|
Let us revisit the example from
|
|
Section~\ref{sec:first-order-curried-cps} to see first hand that our
|
|
refined translation makes the example properly tail-recursive.
|
|
%
|
|
\begin{equations}
|
|
\pcps{\Return\;\Record{}}
|
|
&= & (\lambda (k \cons ks).k\,\Record{}\,ks)\,((\lambda x.\lambda ks.x) \cons (\lambda \Record{z, \_}.\lambda ks.\Absurd\,z) \cons \nil) \\
|
|
&\reducesto& (\lambda x.\lambda ks.x)\,\Record{}\,((\lambda \Record{z,\_}.\lambda ks.\Absurd\,z) \cons \nil)\\
|
|
&\reducesto& \Record{}
|
|
\end{equations}
|
|
%
|
|
The reduction sequence in the image of this uncurried translation has
|
|
one fewer steps (disregarding the administrative steps induced by
|
|
pattern matching) than in the image of the curried translation. The
|
|
`missing' step is precisely the reduction marked
|
|
\eqref{eq:cps-admin-reduct-2}, which was a partial application of the
|
|
initial pure continuation function that was not in tail
|
|
position. Note, however, that the first reduction (corresponding to
|
|
\eqref{eq:cps-admin-reduct-1}) remains administrative, the reduction
|
|
is entirely static, and as such, it can be dealt with as part of the
|
|
translation.
|
|
%
|
|
|
|
\paragraph{Administrative redexes}
|
|
|
|
We can determine whether a redex is administrative in the image by
|
|
determining whether it corresponds to a redex in the preimage. If
|
|
there is no corresponding redex, then the redex is said to be
|
|
administrative. We can further classify an administrative redex as to
|
|
whether it is \emph{static} or \emph{dynamic}.
|
|
|
|
A static administrative redex is a by-product of the translation that
|
|
does not contribute to the implementation of the dynamic behaviour of
|
|
the preimage.
|
|
%
|
|
The separation between value and computation terms in fine-grain
|
|
call-by-value makes it evident where static administrative redexes can
|
|
arise. They arise from computation terms, which can clearly be seen
|
|
from the translation where each computation term induces a
|
|
$\lambda$-abstraction. Each induced $\lambda$-abstraction must
|
|
necessarily be eliminated by a unary application. These unary
|
|
applications are administrative; they do not correspond to reductions
|
|
in the preimage. The applications that do correspond to reductions in
|
|
the preimage are the binary (continuation) applications.
|
|
|
|
A dynamic administrative redex is a genuine implementation detail that
|
|
supports some part of the dynamic behaviour of the preimage. An
|
|
example of such a detail is the implementation of effect
|
|
forwarding. In $\HCalc$ effect forwarding involves no auxiliary
|
|
reductions, any operation invocation is instantaneously dispatched to
|
|
a suitable handler (if such one exists).
|
|
%
|
|
The translation presented above realises effect forwarding by
|
|
explicitly applying the next effect continuation. This application is
|
|
an example of a dynamic administrative reduction. Not every dynamic
|
|
administrative reduction is necessary, though. For instance, the
|
|
implementation of resumptions as a composition of
|
|
$\lambda$-abstractions gives rise to administrative reductions upon
|
|
invocation. As we shall see in
|
|
Section~\ref{sec:first-order-explicit-resump} administrative
|
|
reductions due to resumption invocation can be dealt with by choosing
|
|
a more clever implementation of resumptions.
|
|
|
|
\subsection{Resumptions as explicit reversed stacks}
|
|
\label{sec:first-order-explicit-resump}
|
|
%
|
|
\dhil{Show an example involving administrative redexes produced by resumptions}
|
|
%
|
|
Thus far resumptions have been represented as functions, and
|
|
forwarding has been implemented using function composition. The
|
|
composition of resumption gives rise to unnecessary dynamic
|
|
administrative redexes as function composition necessitates the
|
|
introduction of an additional lambda abstraction.
|
|
%
|
|
|
|
We can avoid generating these administrative redexes by applying a
|
|
variation of the technique that we used in the previous section to
|
|
uncurry the curried CPS translation.
|
|
%
|
|
Rather than representing resumptions as functions, we move to an
|
|
explicit representation of resumptions as \emph{reversed} stacks of
|
|
pure and effect continuations. By choosing to reverse the order of
|
|
pure and effect continuations, we can construct resumptions
|
|
efficiently using regular cons-lists. We augment the syntax and
|
|
semantics of $\UCalc$ with a computation term
|
|
$\Let\;r=\Res\,V\;\In\;N$ which allow us to convert these reversed
|
|
stacks to actual functions on demand.
|
|
%
|
|
\begin{reductions}
|
|
\usemlab{Res}
|
|
& \Let\;r=\Res\,(V_n \cons \dots \cons V_1 \cons \nil)\;\In\;N
|
|
& \reducesto
|
|
& N[\lambda x\,k.V_1\,x\,(V_2 \cons \dots \cons V_n \cons k)/r]
|
|
\end{reductions}
|
|
%
|
|
This reduction rule reverses the stack, extracts the top continuation
|
|
$V_1$, and prepends the remainder onto the current stack $W$. The
|
|
stack representing a resumption and the remaining stack $W$ are
|
|
reminiscent of the zipper data structure for representing cursors in
|
|
lists~\cite{Huet97}. Thus we may think of resumptions as representing
|
|
pointers into the stack of handlers.
|
|
%
|
|
The translations of $\Do$, handling, and forwarding need to be
|
|
modified to account for the change in representation of
|
|
resumptions.
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \CompCat \to \UCompCat\\
|
|
\cps{\Do\;\ell\;V}
|
|
&\defas& \lambda k \cons h \cons ks.\,h\, \Record{\ell,\Record{\cps{V}, h \cons k \cons \nil}}\, ks
|
|
\medskip\\
|
|
%
|
|
\cps{-} &:& \HandlerCat \to \UCompCat\\
|
|
\cps{\{(\ell \; p \; r \mapsto N_\ell)_{\ell \in \mathcal{L}}\}}
|
|
&\defas& \bl
|
|
\lambda \Record{z,\Record{p,rs}}.\lambda ks.\Case \;z\; \{
|
|
\bl
|
|
(\ell \mapsto \Let\;r=\Res\;rs \;\In\; \cps{N_{\ell}}\, ks)_{\ell \in \mathcal{L}};\,\\
|
|
y \mapsto \hforward((y,p,rs),ks) \} \\
|
|
\el \\
|
|
\el \\
|
|
\hforward((y,p,rs),ks)
|
|
&\defas&\Let\; (k' \cons h' \cons ks') = ks \;\In\; h'\,\Record{y,\Record{p,h' \cons k' \cons rs}} \,ks'
|
|
\end{equations}
|
|
%
|
|
The translation of $\Do$ constructs an initial resumption stack,
|
|
operation clauses extract and convert the current resumption stack
|
|
into a function using the $\Res$ construct, and $\hforward$ augments
|
|
the current resumption stack with the current continuation pair.
|
|
%
|
|
|
|
\subsection{Higher-order translation for deep effect handlers}
|
|
\label{sec:higher-order-uncurried-deep-handlers-cps}
|
|
%
|
|
\begin{figure}
|
|
%
|
|
\textbf{Values}
|
|
%
|
|
\begin{displaymath}
|
|
\begin{eqs}
|
|
\cps{-} &:& \ValCat \to \UValCat\\
|
|
\cps{x} &\defas& x \\
|
|
\cps{\lambda x.M} &\defas& \dlam x\,ks.\Let\;(k \dcons h \dcons ks') = ks \;\In\;\cps{M} \sapp (\reflect k \scons \reflect h \scons \reflect ks') \\
|
|
% \cps{\Rec\,g\,x.M} &\defas& \Rec\;f\,x\,ks.\cps{M} \sapp \reflect ks\\
|
|
\cps{\Lambda \alpha.M} &\defas& \dlam \Unit\,ks.\Let\;(k \dcons h \dcons ks') = ks \;\In\;\cps{M} \sapp (\reflect k \scons \reflect h \scons \reflect ks') \\
|
|
\cps{\Record{}} &\defas& \Record{} \\
|
|
\cps{\Record{\ell = V; W}} &\defas& \Record{\ell = \cps{V}; \cps{W}} \\
|
|
\cps{\ell~V} &\defas& \ell~\cps{V} \\
|
|
\end{eqs}
|
|
\end{displaymath}
|
|
%
|
|
\textbf{Computations}
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \CompCat \to \SValCat^\ast \to \UCompCat\\
|
|
\cps{V\,W} &\defas& \slam \sks.\cps{V} \dapp \cps{W} \dapp \reify \sks \\
|
|
\cps{V\,T} &\defas& \slam \sks.\cps{V} \dapp \Record{} \dapp \reify \sks \\
|
|
\cps{\Let\; \Record{\ell=x;y} = V \; \In \; N} &\defas& \slam \sks.\Let\; \Record{\ell=x;y} = \cps{V} \; \In \; \cps{N} \sapp \sks \\
|
|
\cps{\Case~V~\{\ell~x \mapsto M; y \mapsto N\}} &\defas&
|
|
\slam \sks.\Case~\cps{V}~\{\ell~x \mapsto \cps{M} \sapp \sks; y \mapsto \cps{N} \sapp \sks\} \\
|
|
\cps{\Absurd~V} &\defas& \slam \sks.\Absurd~\cps{V} \\
|
|
\cps{\Return~V} &\defas& \slam \sk \scons \sks.\reify \sk \dapp \cps{V} \dapp \reify \sks \\
|
|
\cps{\Let~x \revto M~\In~N} &\defas& \slam \sk \scons \sks.\cps{M} \sapp
|
|
(\reflect (\dlam x\,\dhk.
|
|
\ba[t]{@{}l}
|
|
\Let\;(h \dcons \dhk') = \dhk\;\In\\
|
|
\cps{N} \sapp (\sk \scons \reflect h \scons \reflect \dhk')) \scons \sks)
|
|
\ea\\
|
|
\cps{\Do\;\ell\;V}
|
|
&\defas& \slam \sk \scons \sh \scons \sks.\reify \sh \dapp \Record{\ell,\Record{\cps{V}, \reify \sh \dcons \reify \sk \dcons \dnil}} \dapp \reify \sks\\
|
|
\cps{\Handle \; M \; \With \; H} &\defas& \slam \sks . \cps{M} \sapp (\reflect \cps{\hret} \scons \reflect \cps{\hops} \scons \sks)
|
|
%
|
|
\end{equations}
|
|
%
|
|
\textbf{Handler definitions}
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \HandlerCat \to \UValCat\\
|
|
\cps{\{\Return \; x \mapsto N\}} &\defas& \dlam x\, \dhk.
|
|
\ba[t]{@{~}l}
|
|
\Let\; (h \dcons \dk \dcons h' \dcons \dhk') = \dhk \;\In\\
|
|
\cps{N} \sapp (\reflect \dk \scons \reflect h' \scons \reflect \dhk')
|
|
\ea
|
|
\\
|
|
\cps{\{(\ell \; p \; r \mapsto N_\ell)_{\ell \in \mathcal{L}}\}}
|
|
&\defas& \bl
|
|
\dlam \Record{z,\Record{p,\dhkr}}\,\dhk.\Case \;z\; \{
|
|
\ba[t]{@{}l@{}c@{~}l}
|
|
&(\ell \mapsto&
|
|
\ba[t]{@{}l}
|
|
\Let\;r=\Res\;\dhkr \;\In\\
|
|
\Let\;(\dk \dcons h \dcons \dhk') = \dhk \;\In\\
|
|
\cps{N_{\ell}} \sapp (\reflect \dk \scons \reflect h \scons \reflect \dhk'))_{\ell \in \mathcal{L}};
|
|
\ea\\
|
|
&y \mapsto& \hforward((y,p,\dhkr),\dhk) \} \\
|
|
\ea \\
|
|
\el \\
|
|
\hforward((y,p,\dhkr),\dhk)
|
|
&\defas&\Let\; (\dk' \dcons h' \dcons \dhk') = \dhk \;\In\; h' \dapp \Record{y,\Record{p,h' \dcons \dk' \dcons \dhkr}} \dapp \dhk'
|
|
\end{equations}
|
|
%
|
|
\textbf{Top level program}
|
|
%
|
|
\begin{equations}
|
|
\pcps{-} &:& \CompCat \to \UCompCat\\
|
|
\pcps{M} &=& \cps{M} \sapp (\reflect (\dlam x\,\dhk.x) \scons \reflect (\dlam z\,\dhk.\Absurd~z) \scons \snil) \\
|
|
\end{equations}
|
|
|
|
\caption{Higher-order uncurried CPS translation of $\HCalc$.}
|
|
\label{fig:cps-higher-order-uncurried}
|
|
\end{figure}
|
|
%
|
|
In the previous sections, we have seen step-wise refinements of the
|
|
initial curried CPS translation for deep effect handlers
|
|
(Section~\ref{sec:first-order-curried-cps}) to be properly
|
|
tail-recursive (Section~\ref{sec:first-order-uncurried-cps}) and to
|
|
avoid yielding unnecessary dynamic administrative redexes for
|
|
resumptions (Section~\ref{sec:first-order-explicit-resump}).
|
|
%
|
|
There is still one outstanding issue, namely, that the translation
|
|
yields static administrative redexes. In this section we will further
|
|
refine the CPS translation to eliminate all static administrative
|
|
redexes at translation time.
|
|
%
|
|
Specifically, the translation will be adapted to a higher-order
|
|
one-pass CPS translation~\citep{DanvyF90} that partially evaluates
|
|
administrative redexes at translation time.
|
|
%
|
|
Following \citet{DanvyN03}, I will use a two-level lambda calculus
|
|
notation to distinguish between \emph{static} lambda abstraction and
|
|
application in the meta language and \emph{dynamic} lambda abstraction
|
|
and application in the target language. To disambiguate syntax
|
|
constructors in the respective calculi I will mark static constructors
|
|
with a {\color{blue}$\overline{\text{blue overline}}$}, whilst dynamic
|
|
constructors are marked with a
|
|
{\color{red}$\underline{\text{red underline}}$}. The principal idea is
|
|
that redexes marked as static are reduced as part of the translation,
|
|
whereas those marked as dynamic are reduced at runtime. To facilitate
|
|
this notation I will write application explicitly using an infix
|
|
``at'' symbol ($@$) in both calculi.
|
|
|
|
\paragraph{Static terms}
|
|
%
|
|
As in the dynamic target language, continuations are represented as
|
|
alternating lists of pure continuation functions and effect
|
|
continuation functions. To ease notation I will make use of pattern
|
|
matching notation. The static meta language is generated by the
|
|
following productions.
|
|
%
|
|
\begin{syntax}
|
|
\slab{Static patterns} &\sP \in \SPatCat &::=& \sks \mid \sk \scons \sP\\
|
|
\slab{Static values} & \sV, \sW \in \SValCat &::=& \reflect V \mid \sV \scons \sW \mid \slam \sP. \sM\\
|
|
\slab{Static computations} & \sM \in \SCompCat &::=& \sV \mid \sV \sapp \sW \mid \sV \dapp V \dapp W
|
|
\end{syntax}
|
|
%
|
|
The patterns comprise only static list deconstructing. We let $\sP$
|
|
range over static patterns.
|
|
%
|
|
The static values comprise reflected dynamic values, static lists, and
|
|
static lambda abstractions. We let $\sV, \sW$ range over meta language
|
|
values; by convention we shall use variables $\sk$ to denote
|
|
statically known pure continuations, $\sh$ to denote statically known
|
|
effect continuations, and $\sks$ to denote statically known
|
|
continuations.
|
|
%
|
|
I shall use $\sM$ to range over static computations, which comprise
|
|
static values, static application and binary dynamic application of a
|
|
static value to two dynamic values.
|
|
%
|
|
Static computations are subject to the following equational axioms.
|
|
%
|
|
\begin{equations}
|
|
(\slam \sks. \sM) \sapp \sV &\defas& \sM[\sV/\sks]\\
|
|
(\slam \sk \scons \sks. \sM) \sapp (\sV \scons \sW) &\defas& (\slam \sks. \sM[\sV/\sk]) \sapp \sW\\
|
|
\end{equations}
|
|
%
|
|
The first equation is static $\beta$-equivalence, it states that
|
|
applying a static lambda abstraction with binder $\sks$ and body $\sM$
|
|
to a static value $\sV$ is equal to substituting $\sV$ for $\sks$ in
|
|
$\sM$. The second equation provides a means for applying a static
|
|
lambda abstraction to a static list component-wise.
|
|
%
|
|
|
|
Reflected static values are reified as dynamic language values
|
|
$\reify \sV$ by induction on their structure.
|
|
%
|
|
\[
|
|
\ba{@{}l@{\qquad}c}
|
|
\reify \reflect V \defas V
|
|
&\reify (\sV \scons \sW) \defas \reify \sV \dcons \reify \sW
|
|
\ea
|
|
\]
|
|
%
|
|
|
|
\paragraph{Higher-order translation}
|
|
%
|
|
As we shall see this translation manipulates the continuation
|
|
intricate ways; and since we maintain the interpretation of the
|
|
continuation as an alternating list of pure continuation functions and
|
|
effect continuation functions it is useful to define the `parity' of a
|
|
continuation as follows:
|
|
%
|
|
a continuation is said to be \emph{odd} if the top element is an
|
|
effect continuation function, otherwise it is said to \emph{even}.
|
|
|
|
%
|
|
|
|
The complete CPS translation is given in
|
|
Figure~\ref{fig:cps-higher-order-uncurried}. In essence, it is the
|
|
same as the refined first-order uncurried CPS translation, although
|
|
the notation is slightly more involved due to the separation of static
|
|
and dynamic parts.
|
|
|
|
As before, the translation comprises three translation functions, one
|
|
for each syntactic category: values, computations, and handler
|
|
definitions. Amongst the three functions, the translation function for
|
|
computations stands out, because it is the only one that operates on
|
|
static continuations. Its type signature,
|
|
$\cps{-} : \CompCat \to \SValCat^\ast \to \UCompCat$, signifies that
|
|
it is a binary function, taking a $\HCalc$-computation term as its
|
|
first argument and a static continuation (a list of static values) as
|
|
its second argument, and ultimately produces a $\UCalc$-computation
|
|
term. Thus the computation translation function is able to manipulate
|
|
the continuation. In fact, the translation is said to be higher-order
|
|
because the continuation parameter is a higher-order: it is a list of
|
|
functions.
|
|
|
|
To ensure that static continuation manipulation is well-defined the
|
|
translation maintains the invariant that the statically known
|
|
continuation stack ($\sk$) always contains at least two continuation
|
|
functions, i.e. a complete continuation pair consisting of a pure
|
|
continuation function and an effect continuation function.
|
|
%
|
|
This invariant guarantees that all translations are uniform in whether
|
|
they appear statically within the scope of a handler or not, and this
|
|
also simplifies the correctness proof
|
|
(Theorem~\ref{thm:ho-simulation}).
|
|
%
|
|
Maintaining this invariant has a cosmetic effect on the presentation
|
|
of the translation. This effect manifests in any place where a
|
|
dynamically known continuation stack is passed in (as a continuation
|
|
parameter $\dhk$), as it must be deconstructed using a dynamic
|
|
language $\Let$ to expose the continuation structure and subsequently
|
|
reconstructed as a static value with reflected variable names.
|
|
|
|
The translation of $\lambda$-abstractions provides an example of this
|
|
deconstruction and reconstruction in action. The dynamic continuation
|
|
$\dhk$ is deconstructed to expose to the next pure continuation
|
|
function $\dk$ and effect continuation $h$, and the remainder of the
|
|
continuation $\dhk'$; these names are immediately reflected and put
|
|
back together to form a static continuation that is provided to the
|
|
translation of the body computation $M$.
|
|
|
|
The only translation rule that consumes a complete reflected
|
|
continuation pair is the translation of $\Do$. The effect continuation
|
|
function, $\sh$, is dynamically applied to an operation package and
|
|
the reified remainder of the continuation $\sks$. As usual, the
|
|
operation package contains the payload and the resumption, which is
|
|
represented as a reversed continuation slice.
|
|
%
|
|
The only other translation rules that manipulate the continuation are
|
|
$\Return$ and $\Let$, which only consume the pure continuation
|
|
function $\sk$. For example, the translation of $\Return$ is a dynamic
|
|
application of $\sk$ to the translation of the value $V$ and the
|
|
remainder of the continuation $\sks$.
|
|
%
|
|
The shape of $\sks$ is odd, meaning that the top element is an effect
|
|
continuation function. Thus the pure continuation $\sk$ has to account
|
|
for this odd shape. Fortunately, the possible instantiations of the
|
|
pure continuation are few. We can derive the all possible
|
|
instantiations systematically by using the operational semantics of
|
|
$\HCalc$. According to the operational semantics the continuation of a
|
|
$\Return$-computation is either the continuation of a
|
|
$\Let$-expression or a $\Return$-clause (a bare top-level
|
|
$\Return$-computation is handled by the $\pcps{-}$ translation).
|
|
%
|
|
The translations of $\Let$-expressions and $\Return$-clauses each
|
|
account for odd continuations. For example, the translation of $\Let$
|
|
consumes the current pure continuation function and generates a
|
|
replacement: a pure continuation function which expects an odd dynamic
|
|
continuation $\dhk$, which it deconstructs to expose the effect
|
|
continuation $h$ along with the current pure continuation function in
|
|
the translation of $N$. The modified continuation is passed to the
|
|
translation of $M$.
|
|
%
|
|
To provide a flavour of how this continuation manipulation functions
|
|
in practice, consider the following example term.
|
|
%
|
|
\begin{derivation}
|
|
&\pcps{\Let\;x \revto \Return\;V\;\In\;N}\\
|
|
=& \reason{definition of $\pcps{-}$}\\
|
|
&\ba[t]{@{}l}(\slam \sk \scons \sks.\cps{\Return\;V} \sapp
|
|
(\reflect(\dlam x\,ks.
|
|
\ba[t]{@{}l}
|
|
\Let\;(h \dcons ks') = ks \;\In\\
|
|
\cps{N} \sapp (\sk \scons \reflect h \scons \reflect ks')) \scons \sks)
|
|
\ea\\
|
|
\sapp (\reflect (\dlam x\,ks.x) \scons \reflect (\dlam z\,ks.\Absurd~z) \scons \snil))
|
|
\ea\\
|
|
=& \reason{definition of $\cps{-}$}\\
|
|
&\ba[t]{@{}l}(\slam \sk \scons \sks.(\slam \sk \scons \sks. \reify \sk \dapp \cps{V} \dapp \reify \sks) \sapp
|
|
(\reflect(\dlam x\,ks.
|
|
\ba[t]{@{}l}
|
|
\Let\;(h \dcons ks') = ks \;\In\\
|
|
\cps{N} \sapp (\sk \scons \reflect h \scons \reflect ks')) \scons \sks)
|
|
\ea\\
|
|
\sapp (\reflect (\dlam x\,ks.x) \scons \reflect (\dlam z\,ks.\Absurd~z) \scons \snil))
|
|
\ea\\
|
|
=& \reason{static $\beta$-reduction}\\
|
|
&(\slam \sk \scons \sks. \reify \sk \dapp \cps{V} \dapp \reify \sks)
|
|
\sapp
|
|
(\reflect(\dlam x\,\dhk.
|
|
\ba[t]{@{}l}
|
|
\Let\;(h \dcons \dhk') = \dhk \;\In\\
|
|
\cps{N} \sapp
|
|
\ba[t]{@{}l}
|
|
(\reflect (\dlam x\,\dhk.x) \scons \reflect h \scons \reflect \dhk'))\\
|
|
~~\scons \reflect (\dlam z\,\dhk.\Absurd~z) \scons \snil))
|
|
\ea
|
|
\ea\\
|
|
=& \reason{static $\beta$-reduction}\\
|
|
&\ba[t]{@{}l@{~}l}
|
|
&(\dlam x\,\dhk.
|
|
\Let\;(h \dcons \dhk') = \dhk \;\In\;
|
|
\cps{N} \sapp
|
|
(\reflect (\dlam x\,\dhk.x) \scons \reflect h \scons \reflect \dhk'))\\
|
|
\dapp& \cps{V} \dapp ((\dlam z\,\dhk.\Absurd~z) \dcons \dnil)\\
|
|
\ea\\
|
|
\reducesto& \reason{\usemlab{App_2}}\\
|
|
&\Let\;(h \dcons \dhk') = (\dlam z\,\dhk.\Absurd~z) \dcons \dnil \;\In\;
|
|
\cps{N[V/x]} \sapp
|
|
(\reflect (\dlam x\,\dhk.x) \scons \reflect h \scons \reflect \dhk'))\\
|
|
\reducesto^+& \reason{dynamic pattern matching and substitution}\\
|
|
&\cps{N[V/x]} \sapp
|
|
(\reflect (\dlam x\,\dhk.x) \scons \reflect (\dlam z\,\dhk.\Absurd~z) \scons \reflect \dnil)
|
|
\end{derivation}
|
|
%
|
|
The translation of $\Return$ provides the generated dynamic pure
|
|
continuation function with the odd continuation
|
|
$((\dlam z\,ks.\Absurd~z) \dcons \dnil)$. After the \usemlab{App_2}
|
|
reduction, the pure continuation function deconstructs the odd
|
|
continuation in order to bind the current effect continuation function
|
|
to the name $h$, which would have been used during the translation of
|
|
$N$.
|
|
|
|
The translation of $\Handle$ applies the translation of $M$ to the
|
|
current continuation extended with the translation of the
|
|
$\Return$-clause, acting as a pure continuation function, and the
|
|
translation of operation-clauses, acting as an effect continuation
|
|
function.
|
|
%
|
|
The translation of a $\Return$-clause discards the effect continuation
|
|
$h$ and in addition exposes the next pure continuation $\dk$ and
|
|
effect continuation $h'$ which are reflected to form a static
|
|
continuation for the translation of $N$.
|
|
%
|
|
The translation of operation clauses unpacks the provided operation
|
|
package to perform a case-split on the operation label $z$. The branch
|
|
for $\ell$ deconstructs the continuation $\dhk$ in order to expose the
|
|
continuation structure. The forwarding branch also deconstructs the
|
|
continuation, but for a different purpose; it augments the resumption
|
|
$\dhkr$ with the next pure and effect continuation functions.
|
|
|
|
Let us revisit the example from
|
|
Section~\ref{sec:first-order-curried-cps} to see that the higher-order
|
|
translation eliminates the static redex at translation time.
|
|
%
|
|
\begin{equations}
|
|
\pcps{\Return\;\Record{}}
|
|
&=& (\slam \sk \scons \sks. \sk \dapp \Record{} \dapp \reify \sks) \sapp (\reflect (\dlam x\,\dhk.x) \scons \reflect (\dlam z\,\dhk.\Absurd\;z) \scons \snil)\\
|
|
&=& (\dlam x\,\dhk.x) \dapp \Record{} \dapp (\reflect (\dlam z\,\dhk.\Absurd\;z) \dcons \dnil)\\
|
|
&\reducesto& \Record{}
|
|
\end{equations}
|
|
%
|
|
In contrast with the previous translations, the reduction sequence in
|
|
the image of this translation contains only a single dynamic reduction
|
|
(disregarding the dynamic administrative reductions arising from
|
|
continuation construction and deconstruction); both
|
|
\eqref{eq:cps-admin-reduct-1} and \eqref{eq:cps-admin-reduct-2}
|
|
reductions have been eliminated as part of the translation.
|
|
|
|
The elimination of static redexes coincides with a refinements of the
|
|
target calculus. Unary application is no longer a necessary
|
|
primitive. Every unary application dealt with by the metalanguage,
|
|
i.e. all unary applications are static.
|
|
|
|
\paragraph{Implicit lazy continuation deconstruction}
|
|
%
|
|
An alternative to the explicit deconstruction of continuations is to
|
|
implicitly deconstruct continuations on demand when static pattern
|
|
matching fails. This was the approach taken by
|
|
\citet*{HillerstromLAS17}. On one hand this approach leads to a
|
|
slightly slicker presentation. On the other hand it complicates the
|
|
proof of correctness as one must account for static pattern matching
|
|
failure.
|
|
%
|
|
A practical argument in favour of the explicit eager continuation
|
|
deconstruction is that it is more accessible from an implementation
|
|
point of view. No implementation details are hidden away in side
|
|
conditions.
|
|
%
|
|
Furthermore, it is not clear that lazy deconstruction has any
|
|
advantage over eager deconstruction, as the translation must reify the
|
|
continuation when it transitions from computations to values and
|
|
reflect the continuation when it transitions from values to
|
|
computations, in which case static pattern matching would fail.
|
|
|
|
\subsubsection{Correctness}
|
|
\label{sec:higher-order-cps-deep-handlers-correctness}
|
|
|
|
We establish the correctness of the higher-order uncurried CPS
|
|
translation via a simulation result in the style of
|
|
Plotkin~\cite{Plotkin75} (Theorem~\ref{thm:ho-simulation}). However,
|
|
before we can state and prove this result, we first several auxiliary
|
|
lemmas describing how translated terms behave. First, the higher-order
|
|
CPS translation commutes with substitution.
|
|
%
|
|
\begin{lemma}[Substitution]\label{lem:ho-cps-subst}
|
|
%
|
|
The higher-order uncurried CPS translation commutes with
|
|
substitution in value terms
|
|
%
|
|
\[
|
|
\cps{W}[\cps{V}/x] = \cps{W[V/x]},
|
|
\]
|
|
%
|
|
and with substitution in computation terms
|
|
\[
|
|
(\cps{M} \sapp (\sk \scons \sh \scons \sks))[\cps{V}/x]
|
|
= \cps{M[V/x]} \sapp (\sk \scons \sh \scons \sks)[\cps{V}/x],
|
|
\]
|
|
%
|
|
and with substitution in handler definitions
|
|
%
|
|
\begin{equations}
|
|
\cps{\hret}[\cps{V}/x]
|
|
&=& \cps{\hret[V/x]},\\
|
|
\cps{\hops}[\cps{V}/x]
|
|
&=& \cps{\hops[V/x]}.
|
|
\end{equations}
|
|
\end{lemma}
|
|
%
|
|
\begin{proof}
|
|
By mutual induction on the structure of $W$, $M$, $\hret$, and
|
|
$\hops$.
|
|
\end{proof}
|
|
%
|
|
It follows as a corollary that top-level substitution is well-behaved.
|
|
%
|
|
\begin{corollary}[Top-level substitution]
|
|
\[
|
|
\pcps{M}[\cps{V}/x] = \pcps{M[V/x]}.
|
|
\]
|
|
\end{corollary}
|
|
%
|
|
\begin{proof}
|
|
Follows immediately by the definitions of $\pcps{-}$ and
|
|
Lemma~\ref{lem:ho-cps-subst}.
|
|
\end{proof}
|
|
%
|
|
In order to reason about the behaviour of the \semlab{Op} rule, which
|
|
is defined in terms of an evaluation context, we need to extend the
|
|
CPS translation to evaluation contexts.
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \EvalCat \to \SValCat\\
|
|
\cps{[~]} &\defas& \slam \sks.\sks \\
|
|
\cps{\Let\; x \revto \EC \;\In\; N} &\defas& \slam \sk \scons \sks.\cps{\EC} \sapp
|
|
(\reflect(\dlam x\,ks.
|
|
\ba[t]{@{}l}
|
|
\Let\;(h \dcons ks') = ks\;\In\;\\
|
|
\cps{N} \sapp (\sk \scons \reflect h \scons \reflect ks')) \scons \sks)
|
|
\ea\\
|
|
\cps{\Handle\; \EC \;\With\; H} &\defas& \slam \sks. \cps{\EC} \sapp (\cps{\hret} \scons \cps{\hops} \scons \sks)
|
|
\end{equations}
|
|
%
|
|
The following lemma is the characteristic property of the CPS
|
|
translation on evaluation contexts.
|
|
%
|
|
It provides a means for decomposing an evaluation context, such that
|
|
we can focus on the computation contained within the evaluation
|
|
context.
|
|
%
|
|
\begin{lemma}[Decomposition]
|
|
\label{lem:decomposition}
|
|
%
|
|
\begin{equations}
|
|
\cps{\EC[M]} \sapp (\sV \scons \sW) &=& \cps{M} \sapp (\cps{\EC} \sapp (\sV \scons \sW)) \\
|
|
\end{equations}
|
|
%
|
|
\end{lemma}
|
|
%
|
|
\begin{proof}
|
|
By structural induction on the evaluation context $\EC$.
|
|
\end{proof}
|
|
%
|
|
Even though we have eliminated the static administrative redexes, we
|
|
still need to account for the dynamic administrative redexes that
|
|
arise from pattern matching against a reified continuation. To
|
|
properly account for these administrative redexes it is convenient to
|
|
treat list pattern matching as a primitive in $\UCalc$, therefore we
|
|
introduce a new reduction rule $\usemlab{SplitList}$ in $\UCalc$.
|
|
%
|
|
\begin{reductions}
|
|
\usemlab{SplitList} & \Let\; (k \dcons ks) = V \dcons W \;\In\; M &\reducesto& M[V/k, W/ks] \\
|
|
\end{reductions}
|
|
%
|
|
Note this rule is isomorphic to the \usemlab{Split} rule with lists
|
|
encoded as right nested pairs using unit to denote nil.
|
|
%
|
|
We write $\areducesto$ for the compatible closure of
|
|
\usemlab{SplitList}.
|
|
|
|
We also need to be able to reason about the computational content of
|
|
reflection after reification. By definition we have that
|
|
$\reify \reflect V = V$, the following lemma lets us reason about the
|
|
inverse composition.
|
|
%
|
|
\begin{lemma}[Reflect after reify]
|
|
\label{lem:reflect-after-reify}
|
|
%
|
|
Reflection after reification may give rise to dynamic administrative
|
|
reductions, i.e.
|
|
%
|
|
\[
|
|
\cps{M} \sapp (\sV_1 \scons \dots \sV_n \scons \reflect \reify \sW)
|
|
\areducesto^\ast \cps{M} \sapp (\sV_1 \scons \dots \sV_n \scons \sW)
|
|
\]
|
|
\end{lemma}
|
|
%
|
|
\begin{proof}
|
|
By induction on the structure of $M$.
|
|
\end{proof}
|
|
%
|
|
We next observe that the CPS translation simulates forwarding.
|
|
%
|
|
\begin{lemma}[Forwarding]
|
|
\label{lem:forwarding}
|
|
If $\ell \notin dom(H_1)$ then
|
|
%
|
|
\[
|
|
\cps{\hops_1} \dapp \Record{\ell,\Record{U, V}} \dapp (V_2 \dcons \cps{\hops_2} \dcons W)
|
|
\reducesto^+
|
|
\cps{\hops_2} \dapp \Record{\ell,\Record{U, \cps{\hops_2} \dcons V_2 \dcons V}} \dapp W
|
|
\]
|
|
%
|
|
\end{lemma}
|
|
%
|
|
\begin{proof}
|
|
By direct calculation.
|
|
\end{proof}
|
|
%
|
|
Now we show that the translation simulates the \semlab{Op}
|
|
rule.
|
|
%
|
|
\begin{lemma}[Handling]
|
|
\label{lem:handle-op}
|
|
If $\ell \notin BL(\EC)$ and $\hell = \{\ell\,p\,r \mapsto N_\ell\}$ then
|
|
%
|
|
\[
|
|
\bl
|
|
\cps{\Do\;\ell\;V} \sapp (\cps{\EC} \sapp (\reflect\cps{\hret} \scons \reflect\cps{\hops} \scons \sV)) \reducesto^+\areducesto^\ast \\
|
|
\quad
|
|
(\cps{N_\ell} \sapp \sV)[\cps{V}/p, (\lambda y\,ks.\cps{\Return\;y} \sapp (\cps{\EC} \sapp (\reflect\cps{\hret} \scons \reflect\cps{\hops} \scons \reflect ks)))/]
|
|
\el
|
|
\]
|
|
%
|
|
\end{lemma}
|
|
%
|
|
\begin{proof}
|
|
Follows from Lemmas~\ref{lem:decomposition},
|
|
\ref{lem:reflect-after-reify}, and \ref{lem:forwarding}.
|
|
\end{proof}
|
|
%
|
|
Finally, we have the ingredients to state and prove the simulation
|
|
result. The following theorem shows that the only extra behaviour
|
|
exhibited by a translated term is the bureaucracy of deconstructing
|
|
the continuation stack.
|
|
%
|
|
\begin{theorem}[Simulation]
|
|
\label{thm:ho-simulation}
|
|
If $M \reducesto N$ then $\pcps{M} \reducesto^+ \areducesto^* \pcps{N}$.
|
|
\end{theorem}
|
|
%
|
|
\begin{proof}
|
|
By case analysis on the reduction relation using Lemmas
|
|
\ref{lem:decomposition}--\ref{lem:handle-op}. The \semlab{Op} case
|
|
follows from Lemma~\ref{lem:handle-op}.
|
|
\end{proof}
|
|
%
|
|
% In common with most CPS translations, full abstraction does not
|
|
% hold. However, as our semantics is deterministic it is straightforward
|
|
% to show a backward simulation result.
|
|
% %
|
|
% \begin{corollary}[Backwards simulation]
|
|
% If $\pcps{M} \reducesto^+ \areducesto^* V$ then there exists $W$ such that
|
|
% $M \reducesto^* W$ and $\pcps{W} = V$.
|
|
% \end{corollary}
|
|
% %
|
|
% \begin{proof}
|
|
% TODO\dots
|
|
% \end{proof}
|
|
%
|
|
|
|
\section{CPS transforming shallow effect handlers}
|
|
\label{sec:cps-shallow}
|
|
|
|
In this section we will continue to build upon the higher-order
|
|
uncurried CPS translation
|
|
(Section~\ref{sec:higher-order-uncurried-deep-handlers-cps}) in order
|
|
to add support for shallow handlers. The dynamic nature of shallow
|
|
handlers pose an interesting challenge, because unlike deep resumption
|
|
capture, a shallow resumption capture discards the handler leaving
|
|
behind a dangling pure continuation. The dangling pure continuation
|
|
must be `adopted' by whichever handler the resumption invocation occur
|
|
under. This handler is determined dynamically by the context, meaning
|
|
the CPS translation must be able to modify continuation pairs.
|
|
|
|
In Section~\ref{sec:cps-shallow-flawed} I will discuss an attempt at a
|
|
`natural' extension of the higher-order uncurried CPS translation for
|
|
deep handlers, but for various reasons this extension is
|
|
flawed. However, the insights gained by attempting this extension
|
|
leads to yet another change of the continuation representation
|
|
(Section~\ref{sec:generalised-continuations}) resulting in the notion
|
|
of a \emph{generalised continuation}.
|
|
%
|
|
In Section~\ref{sec:cps-gen-conts} we will see how generalised
|
|
continuations provide a basis for implementing deep and shallow effect
|
|
handlers simultaneously, solving all of the problems encountered thus
|
|
far uniformly.
|
|
|
|
\subsection{A specious attempt}
|
|
\label{sec:cps-shallow-flawed}
|
|
%
|
|
Initially it is tempting to try to extend the interpretation of the
|
|
continuation representation in the higher-order uncurried CPS
|
|
translation for deep handlers to squeeze in shallow handlers. The main
|
|
obstacle one encounters is how to decouple a pure continuation from
|
|
its handler such that a it can later be picked up by another handler.
|
|
|
|
To fully uninstall a handler, we must uninstall both the pure
|
|
continuation function corresponding to its return clause and the
|
|
effect continuation function corresponding to its operation clauses.
|
|
%
|
|
In the current setup it is impossible to reliably uninstall the former
|
|
as due to the translation of $\Let$-expressions it may be embedded
|
|
arbitrarily deep within the current pure continuation and the
|
|
extensional representation of pure continuations means that we cannot
|
|
decompose them.
|
|
|
|
A quick fix to this problem is to treat pure continuation functions
|
|
arising from return clauses separately from pure continuation
|
|
functions arising from $\Let$-expressions.
|
|
%
|
|
Thus we can interpret the continuation as a sequence of triples
|
|
consisting of two pure continuation functions followed by an effect
|
|
continuation function, where the first pure continuation function
|
|
corresponds the continuation induced by some $\Let$-expression and the
|
|
second corresponds to the return clause of the current handler.
|
|
%
|
|
To distinguish between the two kinds of pure continuations, we shall
|
|
write $\svhret$ for statically known pure continuations arising from
|
|
return clauses, and $\vhret$ for dynamically known ones. Similarly, we
|
|
write $\svhops$ and $\vhops$, respectively, for statically and
|
|
dynamically, known effect continuations. With this notation in mind,
|
|
we may translate operation invocation and handler installation using
|
|
the new interpretation of the continuation representation as follows.
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \CompCat \to \SValCat^\ast \to \UCompCat \smallskip\\
|
|
\cps{\Do\;\ell\;V} &\defas& \slam \sk \scons \svhret \scons \svhops \scons \sks.
|
|
\reify\svhops \ba[t]{@{}l}
|
|
\dapp \Record{\ell, \Record{\cps{V}, \reify\svhops \dcons \reify\svhret \dcons \reify\sk \dcons \dnil}}\\
|
|
\dapp \reify \sks
|
|
\ea\smallskip\\
|
|
\cps{\ShallowHandle \; M \; \With \; H} &\defas&
|
|
\slam \sks . \cps{M} \sapp (\reflect\kid \scons \reflect\cps{\hret} \scons \reflect\cps{\hops}^\dagger \scons \sks) \medskip\\
|
|
\kid &\defas& \dlam x\, \dhk.\Let\; (\vhret \dcons \dhk') = \dhk \;\In\; \vhret \dapp x \dapp \dhk'
|
|
\end{equations}
|
|
%
|
|
The only change to the translation of operation invocation is the
|
|
extra bureaucracy induced by the additional pure continuation.
|
|
%
|
|
The translation of handler installation is a little more interesting
|
|
as it must make up an initial pure continuation in order to maintain
|
|
the sequence of triples interpretation of the continuation
|
|
structure. As the initial pure continuation we use the administrative
|
|
function $\kid$, which amounts to a dynamic variation of the
|
|
translation rule for the trivial computation term $\Return$: it
|
|
invokes the next pure continuation with whatever value it was
|
|
provided.
|
|
%
|
|
|
|
Although, I will not demonstrate it here, the translation rules for
|
|
$\lambda$-abstractions, $\Lambda$-abstractions, and $\Let$-expressions
|
|
must also be adjusted accordingly to account for the extra
|
|
bureaucracy. The same is true for the translation of $\Return$-clause,
|
|
thus it is rather straightforward to adapt it to the new continuation
|
|
interpretation.
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \HandlerCat \to \UValCat\\
|
|
\cps{\{\Return \; x \mapsto N\}} &\defas& \dlam x\, \dhk.
|
|
\ba[t]{@{}l}
|
|
\Let\; (\_ \dcons \dk \dcons \vhret \dcons \vhops \dcons \dhk') = \dhk \;\In\\
|
|
\cps{N} \sapp (\reflect \dk \scons \reflect \vhret \scons \reflect \vhops \scons \reflect \dhk')
|
|
\ea
|
|
\end{equations}
|
|
%
|
|
As before, the translation ensures that the associated effect
|
|
continuation is discarded (the first element of the dynamic
|
|
continuation $ks$). In addition the next continuation triple is
|
|
extracted and reified as a static continuation triple.
|
|
%
|
|
The interesting rule is the translation of operation clauses.
|
|
%
|
|
\begin{equations}
|
|
\cps{\{(\ell \; p \; r \mapsto N_\ell)_{\ell \in \mathcal{L}}\}}^\dagger
|
|
&\defas&
|
|
\bl
|
|
\dlam \Record{z,\Record{p,\dhkr}}\,\dhk.\\
|
|
\qquad\Case \;z\; \{
|
|
\ba[t]{@{}l@{}c@{~}l}
|
|
(&\ell &\mapsto
|
|
\ba[t]{@{}l}
|
|
\Let\;(\dk \dcons \vhret \dcons \vhops \dcons \dhk') = \dhk\;\In\\
|
|
\Let\;(\_ \dcons \_ \dcons \dhkr') = \dhkr \;\In\\
|
|
\Let\;r = \Res\,(\hid \dcons \rid \dcons \dhkr') \;\In \\
|
|
\cps{N_{\ell}} \sapp (\reflect\dk \scons \reflect\vhret \scons \reflect\vhops \scons \reflect \dhk'))_{\ell \in \mathcal{L}} \\
|
|
\ea \\
|
|
&y &\mapsto \hforward((y,p,\dhkr),\dhk) \} \\
|
|
\ea
|
|
\el \medskip\\
|
|
\hforward((y, p, \dhkr), \dhk) &\defas& \bl
|
|
\Let\; (\dk \dcons \vhret \dcons \vhops \dcons \dhk') = \dhk \;\In \\
|
|
\vhops \dapp \Record{y, \Record{p, \vhops \dcons \vhret \dcons \dk \dcons \dhkr}} \dapp \dhk' \\
|
|
\el \smallskip\\
|
|
\hid &\defas& \dlam\,\Record{z,\Record{p,\dhkr}}\,\dhk.\hforward((z,p,\dhkr),\dhk) \smallskip\\
|
|
\rid &\defas& \dlam x\, \dhk.\Let\; (\vhops \dcons \dk \dcons \dhk') = \dhk \;\In\; \dk \dapp x \dapp \dhk'
|
|
% \pcps{-} &:& \CompCat \to \UCompCat\\
|
|
% \pcps{M} &\defas& \cps{M} \sapp (\reflect \kid \scons \reflect (\dlam x\,\dhk.x) \scons \reflect (\dlam z\,ks.\Absurd~z) \scons \snil) \\
|
|
\end{equations}
|
|
%
|
|
The main difference between this translation rule and the translation
|
|
rule for deep handler operation clauses is the realisation of
|
|
resumptions.
|
|
%
|
|
Recall that a resumption is represented as a reversed slice of a
|
|
continuation. Thus the deconstruction of the resumption $\dhkr$
|
|
effectively ensures that the current handler gets properly
|
|
uninstalled. However, it presents a new problem as the remainder
|
|
$\dhkr'$ is not a well-formed continuation slice, because the top
|
|
element is a pure continuation without a handler.
|
|
%
|
|
|
|
To rectify this problem, we can insert a dummy identity handler
|
|
composed from $\hid$ and $\rid$. The effect continuation $\hid$
|
|
forwards every operation, and the pure continuation $\rid$ is an
|
|
identity clause. Thus every operation and the return value will
|
|
effectively be handled by the next handler.
|
|
%
|
|
Unfortunately, inserting such dummy handlers lead to memory
|
|
leaks.
|
|
%
|
|
\dhil{Give the counting example}
|
|
%
|
|
|
|
The use of dummy handlers is symptomatic for the need of a more
|
|
general notion of resumptions. Upon resumption invocation the dangling
|
|
pure continuation should be composed with the current pure
|
|
continuation which suggests the need for a shallow variation of the
|
|
resumption construction primitive $\Res$ that behaves along the
|
|
following lines.
|
|
%
|
|
\[
|
|
\bl
|
|
\Let\; r = \Res^\dagger (\_ \dcons \_ \dcons \dk \dcons h_n^{\mathrm{ops}} \dcons h_n^{\mathrm{ret}} \dcons \dk_n \dcons \cdots \dcons h_1^{\mathrm{ops}} \dcons h_1^{\mathrm{ret}} \dcons \dk_1 \dcons \dnil)\;\In\;N \reducesto\\
|
|
\quad N[(\dlam x\,\dhk.
|
|
\ba[t]{@{}l}
|
|
\Let\; (\dk' \dcons \dhk') = \dhk\;\In\\
|
|
\dk_1 \dapp x \dapp (h_1^{\mathrm{ret}} \dcons h_1^{\mathrm{ops}} \cdots \dcons \dk_n \dcons h_n^{\mathrm{ret}} \dcons h_n^{\mathrm{ops}} \dcons (\dk' \circ \dk) \dcons \dhk'))/r]
|
|
\ea
|
|
\el
|
|
\]
|
|
%
|
|
where $\circ$ is defined to be function composition in continuation
|
|
passing style.
|
|
%
|
|
\[
|
|
g \circ f \defas \lambda x\,\dhk.
|
|
\ba[t]{@{}l}
|
|
\Let\;(\dk \dcons \dhk') = \dhk\; \In\\
|
|
f \dapp x \dapp ((\lambda x\,\dhk. g \dapp x \dapp (\dk \dcons \dhk)) \dcons \dhk')
|
|
\ea
|
|
\]
|
|
%
|
|
The idea is that $\Res^\dagger$ uninstalls the appropriate handler and
|
|
composes the dangling pure continuation $\dk$ with the next
|
|
\emph{dynamically determined} pure continuation $\dk'$, and reverses
|
|
the remainder of the resumption and composes it with the modified
|
|
dynamic continuation ($(\dk' \circ \dk) \dcons ks'$).
|
|
%
|
|
|
|
While the underlying idea is correct, this particular realisation of
|
|
the idea is problematic as the use of function composition
|
|
reintroduces a variation of the dynamic administrative redexes that we
|
|
dealt with in Section~\ref{sec:first-order-explicit-resump}.
|
|
%
|
|
In order to avoid generating these administrative redexes we need a
|
|
more intensional continuation representation.
|
|
%
|
|
Another telltale sign that we require a more intensional continuation
|
|
representation is the necessary use of the administrative function
|
|
$\kid$ in the translation of $\Handle$ as a placeholder for the empty
|
|
pure continuation.
|
|
%
|
|
In terms of aesthetics, the non-uniform continuation deconstructions
|
|
also suggest that we could benefit from a more structured
|
|
interpretation of continuations.
|
|
%
|
|
Although it is seductive to program with lists, it quickly gets
|
|
unwieldy.
|
|
|
|
\subsection{Generalised continuations}
|
|
\label{sec:generalised-continuations}
|
|
|
|
One problem is that the continuation representation used by the
|
|
higher-order uncurried translation for deep handlers is too
|
|
extensional to support shallow handlers efficiently. Specifically, the
|
|
representation of pure continuations needs to be more intensional to
|
|
enable composition of pure continuations without having to materialise
|
|
administrative continuation functions.
|
|
%
|
|
|
|
Another problem is that the continuation representation integrates the
|
|
return clause into the pure continuations, but the semantics of
|
|
shallow handlers demands that this return clause is discarded when any
|
|
of the operations is invoked.
|
|
|
|
The solution to the first problem is to reuse the key idea of
|
|
Section~\ref{sec:first-order-explicit-resump} to avoid administrative
|
|
continuation functions by representing a pure continuation as an
|
|
explicit list consisting of pure continuation functions. As a result
|
|
the composition of pure continuation functions can be realised as a
|
|
simple cons-operation.
|
|
%
|
|
|
|
The solution to the second problem is to pair the continuation
|
|
functions corresponding to the $\Return$-clause and operation clauses
|
|
in order to distinguish the pure continuation function induced by a
|
|
$\Return$-clause from those induced by $\Let$-expressions.
|
|
%
|
|
|
|
Plugging these two solutions yields the notion of \emph{generalised
|
|
continuations}. A generalised continuation is a list of
|
|
\emph{continuation frames}. A continuation frame is a triple
|
|
$\Record{fs, \Record{\vhret, \vhops}}$, where $fs$ is list of stack
|
|
frames representing the pure continuation for the computation
|
|
occurring between the current execution and the handler, $\vhret$ is
|
|
the (translation of the) return clause of the enclosing handler, and
|
|
$\vhops$ is the (translation of the) operation clauses.
|
|
%
|
|
|
|
The change of representation of pure continuations does mean that we
|
|
can no longer invoke them by simple function application. Instead, we
|
|
must inspect the structure of the pure continuation $fs$ and act
|
|
appropriately. To ease notation it is convenient introduce a new
|
|
computation form for pure continuation application $\kapp\;V\;W$ that
|
|
feeds a value $W$ into the continuation represented by $V$. There are
|
|
two reduction rules.
|
|
%
|
|
\begin{reductions}
|
|
\usemlab{KAppNil}
|
|
& \kapp\;(\dRecord{\dnil, \dRecord{\vhret, \vhops}} \dcons \dhk)\,W
|
|
& \reducesto
|
|
& \vhret\,W\,\dhk
|
|
\\
|
|
\usemlab{KAppCons}
|
|
& \kapp\;(\dRecord{f \cons fs, h} \dcons \dhk)\,W
|
|
& \reducesto
|
|
& f\,W\,(\dRecord{fs, h} \dcons \dhk)
|
|
\end{reductions}
|
|
%
|
|
\dhil{Say something about skip frames?}
|
|
%
|
|
The first rule describes what happens when the pure continuation is
|
|
exhausted and the return clause of the enclosing handler is
|
|
invoked. The second rule describes the case when the pure continuation
|
|
has at least one element: this pure continuation function is invoked
|
|
and the remainder of the continuation is passed in as the new
|
|
continuation.
|
|
|
|
We must also change how resumptions (i.e. reversed continuations) are
|
|
converted into functions that can be applied. Resumptions for deep
|
|
handlers ($\Res\,V$) are similar to
|
|
Section~\ref{sec:first-order-explicit-resump}, except that we now use
|
|
$\kapp$ to invoke the continuation. Resumptions for shallow handlers
|
|
($\Res^\dagger\,V$) are more complex. Instead of taking all the frames
|
|
and reverse appending them to the current stack, we remove the current
|
|
handler $h$ and move the pure continuation
|
|
($f_1 \dcons \dots \dcons f_m \dcons \dnil$) into the next frame. This
|
|
captures the intended behaviour of shallow handlers: they are removed
|
|
from the stack once they have been invoked. The following two
|
|
reduction rules describe their behaviour.
|
|
%
|
|
\[
|
|
\ba{@{}l@{\quad}l}
|
|
\usemlab{Res}
|
|
& \Let\;r=\Res\,(V_n \dcons \dots \dcons V_1 \dcons \dnil)\;\In\;N
|
|
\reducesto N[\dlam x\, \dhk.\kapp\;(V_1 \dcons \dots V_n \dcons \dhk)\,x/r] \\
|
|
\usemlab{Res^\dagger}
|
|
& \Let\;r=\Res^\dagger\,(\dRecord{f_1 \dcons \dots \dcons f_m \dcons \nil, h} \dcons V_n \dcons \dots \dcons V_1 \dcons \dnil)\;\In\;N \reducesto \\
|
|
& \qquad N[\dlam x\,\dhk.\bl
|
|
\Let\,\dRecord{fs',h'} \dcons \dhk' = \dhk\;\In\;\\
|
|
\kapp\,(V_1 \dcons \dots \dcons V_n \dcons \dRecord{f_1 \dcons \dots \dcons f_m \dcons fs', h'} \dcons \dhk')\,x/r]
|
|
\el
|
|
\ea
|
|
\]
|
|
%
|
|
These constructs along with their reduction rules are
|
|
macro-expressible in terms of the existing constructs.
|
|
%
|
|
I choose here to treat them as primitives in order to keep the
|
|
presentation relatively concise.
|
|
|
|
\dhil{Remark that a `generalised continuation' is a defunctionalised continuation.}
|
|
|
|
\subsection{Dynamic terms: the target calculus revisited}
|
|
\label{sec:target-calculus-revisited}
|
|
|
|
\begin{figure}[t]
|
|
\textbf{Syntax}
|
|
\begin{syntax}
|
|
\slab{Values} &V, W \in \UValCat &::= & x \mid \dlam x\,\dhk.M \mid \Rec\,g\,x\,\dhk.M \mid \ell \mid \dRecord{V, W}
|
|
\smallskip \\
|
|
\slab{Computations} &M,N \in \UCompCat &::= & V \mid U \dapp V \dapp W \mid \Let\; \dRecord{x, y} = V \; \In \; N \\
|
|
& &\mid& \Case\; V\, \{\ell \mapsto M; x \mapsto N\} \mid \Absurd\;V\\
|
|
& &\mid& \kapp\,V\,W \mid \Let\;r=\Res^\depth\;V\;\In\;M
|
|
\end{syntax}
|
|
\textbf{Syntactic sugar}
|
|
\begin{displaymath}
|
|
\bl
|
|
\begin{eqs}
|
|
\Let\; x = V \;\In\; N &\equiv& N[V/x] \\
|
|
\ell\;V &\equiv& \dRecord{\ell, V} \\
|
|
\end{eqs}
|
|
\qquad
|
|
\begin{eqs}
|
|
\Record{} &\equiv& \ell_{\Record{}} \\
|
|
\Record{\ell=V; W} &\equiv& \ell\;\dRecord{V, W} \\
|
|
\end{eqs}
|
|
\qquad
|
|
\begin{eqs}
|
|
\dnil &\equiv& \ell_{\dnil} \\
|
|
V \dcons W &\equiv& \ell_{\dcons}\;\dRecord{V, W} \\
|
|
\end{eqs}
|
|
\smallskip \\
|
|
\ba{@{}c@{\quad}c@{}}
|
|
\Case\;V\;\{\ell\,x \mapsto M; y \mapsto N\} \equiv \\
|
|
\qquad \bl
|
|
\Let\; y=V \;\In\;
|
|
\Let\; \dRecord{z, x} = y \;\In \\
|
|
\Case\;z\;\{\ell \mapsto M; z \mapsto N\} \\
|
|
\el \\
|
|
\ea
|
|
\qquad
|
|
\ba{@{}l@{\quad}l@{}}
|
|
\Let\;\Record{\ell=x; y} = V \;\In\; N \equiv \\
|
|
\qquad \bl
|
|
\Let\; \dRecord{z, z'} = V \;\In\;
|
|
\Let\; \dRecord{x, y} = z' \;\In \\
|
|
\Case\; z \;\{\ell \mapsto N; z \mapsto \ell_{\bot}\} \\
|
|
\el \\
|
|
\ea \\
|
|
\el
|
|
\end{displaymath}
|
|
%
|
|
\textbf{Standard reductions}
|
|
%
|
|
\begin{reductions}
|
|
%% Standard reductions
|
|
\usemlab{App} & (\dlam x\,\dhk.M) \dapp V \dapp W &\reducesto& M[V/x, W/\dhk] \\
|
|
\usemlab{Rec} & (\Rec\,g\,x\,\dhk.M) \dapp V \dapp W &\reducesto& M[\Rec\,g\,x\,\dhk.M/g, V/x, W/\dhk] \smallskip\\
|
|
\usemlab{Split} & \Let \; \dRecord{x, y} = \dRecord{V, W} \; \In \; N &\reducesto& N[V/x, W/y] \\
|
|
\usemlab{Case_1} &
|
|
\Case \; \ell \,\{ \ell \; \mapsto M; x \mapsto N\} &\reducesto& M \\
|
|
\usemlab{Case_2} &
|
|
\Case \; \ell \,\{ \ell' \; \mapsto M; x \mapsto N\} &\reducesto& N[\ell/x], \hfill\quad \text{if } \ell \neq \ell' \smallskip\\
|
|
\end{reductions}
|
|
%
|
|
\textbf{Continuation reductions}
|
|
%
|
|
\begin{reductions}
|
|
\usemlab{KAppNil} &
|
|
\kapp \; (\dRecord{\dnil, \dRecord{v, e}} \dcons \dhk) \, V &\reducesto& v \dapp V \dapp \dhk \\
|
|
\usemlab{KAppCons} &
|
|
\kapp \; (\dRecord{\dlf \dcons \dlk, h} \dcons \dhk) \, V &\reducesto& \dlf \dapp V \dapp (\dRecord{\dlk, h} \dcons \dhk) \\
|
|
\end{reductions}
|
|
%
|
|
\textbf{Resumption reductions}
|
|
%
|
|
\[
|
|
\ba{@{}l@{\quad}l@{}}
|
|
\usemlab{Res} &
|
|
\Let\;r=\Res(V_n \dcons \dots \dcons V_1 \dcons \dnil)\;\In\;N \reducesto \\
|
|
&\quad N[\dlam x\,\dhk. \bl\Let\;\dRecord{fs, \dRecord{\vhret, \vhops}}\dcons \dhk' = \dhk\;\In\\
|
|
\kapp\;(V_1 \dcons \dots \dcons V_n \dcons \dRecord{fs, \dRecord{\vhret, \vhops}} \dcons \dhk')\;x/r]\el
|
|
\\
|
|
\usemlab{Res^\dagger} &
|
|
\Let\;r=\Res^\dagger(\dRecord{\dlf_1 \dcons \dots \dcons \dlf_m \dcons \dnil, h} \dcons V_n \dcons \dots \dcons V_1 \dcons \dnil)\;\In\;N \reducesto\\
|
|
& \quad N[\dlam x\,k. \bl
|
|
\Let\;\dRecord{\dlk', h'} \dcons \dhk' = \dhk \;\In \\
|
|
\kapp\;(V_1 \dcons \dots \dcons V_n \dcons \dRecord{\dlf_1 \dcons \dots \dcons \dlf_m \dcons \dlk', h'} \dcons \dhk')\;x/r] \\
|
|
\el
|
|
\ea
|
|
\]
|
|
%
|
|
\caption{Untyped target calculus supporting generalised continuations.}
|
|
\label{fig:cps-target-gen-conts}
|
|
\end{figure}
|
|
|
|
Let us revisit the target
|
|
calculus. Figure~\ref{fig:cps-target-gen-conts} depicts the untyped
|
|
target calculus with support for generalised continuations.
|
|
%
|
|
This is essentially the same as the target calculus used for the
|
|
higher-order uncurried CPS translation for deep effect handlers in
|
|
Section~\ref{sec:higher-order-uncurried-deep-handlers-cps}, except for
|
|
the addition of recursive functions. The calculus also includes the
|
|
$\kapp$ and $\Let\;r=\Res^\depth\;V\;\In\;N$ constructs described in
|
|
Section~\ref{sec:generalised-continuations}. There is a small
|
|
difference in the reduction rules for the resumption constructs: for
|
|
deep resumptions we do an additional pattern match on the current
|
|
continuation ($\dhk$). This is required to make the simulation proof
|
|
for the CPS translation with generalised continuations
|
|
(Section~\ref{sec:cps-gen-conts}) go through, because it makes the
|
|
functions that resumptions get converted to have the same shape as the
|
|
translation of source level functions -- this is required because the
|
|
operational semantics does not treat resumptions as distinct
|
|
first-class objects, but rather as a special kinds of functions.
|
|
|
|
\subsection{Translation with generalised continuations}
|
|
\label{sec:cps-gen-conts}
|
|
%
|
|
\begin{figure}
|
|
%
|
|
\textbf{Values}
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \ValCat \to \UValCat\\
|
|
\cps{x} &\defas& x\\
|
|
\cps{\lambda x.M} &\defas& \dlam x\,\dhk.\Let\;(\dk \dcons \dhk') = \dhk\;\In\;\cps{M} \sapp (\reflect\dk \scons \reflect \dhk') \\
|
|
\cps{\Lambda \alpha.M} &\defas& \dlam \Unit\,\dhk.\Let\;(\dk \dcons \dhk') = \dhk\;\In\;\cps{M} \sapp (\reflect\dk \scons \reflect \dhk') \\
|
|
\cps{\Rec\,g\,x.M} &\defas& \Rec\,g\,x\,\dhk.\Let\;(\dk \dcons \dhk') = \dhk\;\In\;\cps{M} \sapp (\reflect\dk \scons \reflect \dhk') \\
|
|
\multicolumn{3}{c}{
|
|
\cps{\Record{}} \defas \Record{}
|
|
\qquad
|
|
\cps{\Record{\ell = \!\!V; W}} \defas \Record{\ell = \!\cps{V}; \cps{W}}
|
|
\qquad
|
|
\cps{\ell\,V} \defas \ell\,\cps{V}
|
|
}
|
|
\end{equations}
|
|
%
|
|
\textbf{Computations}
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \CompCat \to \SValCat^\ast \to \UCompCat\\
|
|
\cps{V\,W} &\defas& \slam \shk.\cps{V} \dapp \cps{W} \dapp \reify \shk \\
|
|
\cps{V\,T} &\defas& \slam \shk.\cps{V} \dapp \Record{} \dapp \reify \shk \\
|
|
\cps{\Let\; \Record{\ell=x;y} = V \; \In \; N} &\defas& \slam \shk.\Let\; \Record{\ell=x;y} = \cps{V} \; \In \; \cps{N} \sapp \shk \\
|
|
\cps{\Case~V~\{\ell~x \mapsto M; y \mapsto N\}} &\defas&
|
|
\slam \shk.\Case~\cps{V}~\{\ell~x \mapsto \cps{M} \sapp \shk; y \mapsto \cps{N} \sapp \shk\} \\
|
|
\cps{\Absurd~V} &\defas& \slam \shk.\Absurd~\cps{V} \\
|
|
\end{equations}
|
|
\begin{equations}
|
|
\cps{\Return\,V} &\defas& \slam \shk.\kapp\;(\reify \shk)\;\cps{V} \\
|
|
\cps{\Let~x \revto M~\In~N} &\defas&
|
|
\bl\slam \sRecord{\shf, \sRecord{\svhret, \svhops}} \scons \shk.
|
|
\ba[t]{@{}l}
|
|
\cps{M} \sapp (\sRecord{\bl\reflect((\dlam x\,\dhk.\bl\Let\;(\dk \dcons \dhk') = \dhk\;\In\\
|
|
\cps{N} \sapp (\reflect\dk \scons \reflect \dhk')) \el\\
|
|
\dcons \reify\shf), \sRecord{\svhret, \svhops}} \scons \shk)\el
|
|
\ea
|
|
\el\\
|
|
\cps{\Do\;\ell\;V} &\defas&
|
|
\slam \sRecord{\shf, \sRecord{\svhret, \svhops}} \scons \shk.\,
|
|
\reify\svhops \bl\dapp \dRecord{\ell,\dRecord{\cps{V}, \dRecord{\reify \shf, \dRecord{\reify\svhret, \reify\svhops}} \dcons \dnil}}\\
|
|
\dapp \reify \shk\el \\
|
|
\cps{\Handle^\depth \, M \; \With \; H} &\defas&
|
|
\slam \shk . \cps{M} \sapp (\sRecord{\snil, \sRecord{\reflect \cps{\hret}, \reflect \cps{\hops}^\depth}} \scons \shk) \\
|
|
\end{equations}
|
|
%
|
|
\textbf{Handler definitions}
|
|
%
|
|
\begin{equations}
|
|
\cps{-} &:& \HandlerCat \to \UValCat\\
|
|
% \cps{H}^\depth &=& \sRecord{\reflect \cps{\hret}, \reflect \cps{\hops}^\depth}\\
|
|
\cps{\{\Return \; x \mapsto N\}} &\defas& \dlam x\,\dhk.\Let\;(\dk \dcons \dhk') = \dhk\;\In\;\cps{N} \sapp (\reflect\dk \scons \reflect \dhk') \\
|
|
\cps{\{(\ell \; p \; r \mapsto N_\ell)_{\ell \in \mathcal{L}}\}}^\depth
|
|
&\defas&
|
|
\dlam \dRecord{z,\dRecord{p,\dhkr}}\,\dhk.
|
|
\Case \;z\; \{
|
|
\ba[t]{@{}l@{}c@{~}l}
|
|
(&\ell &\mapsto
|
|
\ba[t]{@{}l}
|
|
\Let\;r=\Res^\depth\,\dhkr\;\In\; \\
|
|
\Let\;(\dk \dcons \dhk') = \dhk\;\In\\
|
|
\cps{N_{\ell}} \sapp (\reflect\dk \scons \reflect \dhk'))_{\ell \in \mathcal{L}}
|
|
\ea\\
|
|
&y &\mapsto \hforward((y, p, \dhkr), \dhk) \} \\
|
|
\ea \\
|
|
\hforward((y, p, \dhkr), \dhk) &\defas& \bl
|
|
\Let\; \dRecord{fs, \dRecord{\vhret, \vhops}} \dcons \dhk' = \dhk \;\In \\
|
|
\vhops \dapp \dRecord{y,\dRecord{p, \dRecord{fs, \dRecord{\vhret, \vhops}} \dcons \dhkr}} \dapp \dhk' \\
|
|
\el
|
|
\end{equations}
|
|
|
|
\textbf{Top-level program}
|
|
%
|
|
\begin{equations}
|
|
\pcps{-} &:& \CompCat \to \UCompCat\\
|
|
\pcps{M} &\defas& \cps{M} \sapp (\sRecord{\snil, \sRecord{\reflect \dlam x\,\dhk. x, \reflect \dlam \dRecord{z,\dRecord{p,\dhkr}}\,\dhk.\Absurd~z}} \scons \snil) \\
|
|
\end{equations}
|
|
%
|
|
\caption{Higher-order uncurried CPS translation for effect handlers.}
|
|
\label{fig:cps-higher-order-uncurried-simul}
|
|
\end{figure}
|
|
%
|
|
|
|
The CPS translation is given in
|
|
Figure~\ref{fig:cps-higher-order-uncurried-simul}. In essence, it is
|
|
the same as the CPS translation for deep effect handlers as described
|
|
in Section~\ref{sec:higher-order-uncurried-deep-handlers-cps}, though
|
|
it is adjusted to account for generalised continuation representation.
|
|
%
|
|
The translation of $\Return$ invokes the continuation $\shk$ using the
|
|
continuation application primitive $\kapp$.
|
|
%
|
|
The translations of deep and shallow handlers differ only in their use
|
|
of the resumption construction primitive.
|
|
|
|
A major aesthetic improvement due to the generalised continuation
|
|
representation is that continuation construction and deconstruction is
|
|
now uniform: only a single continuation frame is inspected at a time.
|
|
|
|
\subsubsection{Correctness}
|
|
\label{sec:cps-gen-cont-correctness}
|
|
%
|
|
The correctness of this CPS translation
|
|
(Theorem~\ref{thm:ho-simulation-gen-cont}) follows closely the
|
|
correctness result for the higher-order uncurried CPS translation for
|
|
deep handlers (Theorem~\ref{thm:ho-simulation}). Save for the
|
|
syntactic difference, the most notable difference is the extension of
|
|
the operation handling lemma (Lemma~\ref{lem:handle-op-gen-cont}) to
|
|
cover shallow handling in addition to deep handling. Each lemma is
|
|
stated in terms of static continuations, where the shape of the top
|
|
element is always known statically, i.e., it is of the form
|
|
$\sRecord{\sV_{fs}, \sRecord{\sV_{\mret},\sV_{\mops}}} \scons
|
|
\sW$. Moreover, the static values $\sV_{fs}$, $\sV_{\mret}$, and
|
|
$\sV_{\mops}$ are all reflected dynamic terms (i.e., of the form
|
|
$\reflect V$). This fact is used implicitly in the proofs.
|
|
|
|
%
|
|
\begin{lemma}[Substitution]\label{lem:subst-gen-cont}
|
|
%
|
|
The CPS translation commutes with substitution in value terms
|
|
%
|
|
\[
|
|
\cps{W}[\cps{V}/x] = \cps{W[V/x]},
|
|
\]
|
|
%
|
|
and with substitution in computation terms
|
|
\[
|
|
\ba{@{}l@{~}l}
|
|
&(\cps{M} \sapp (\sRecord{\sV_{fs},\sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW))[\cps{V}/x]\\
|
|
= &\cps{M[V/x]} \sapp (\sRecord{\sV_{fs},\sRecord{\sV_{\mret},\sV_{\mops}}} \scons\sW)[\cps{V}/x],
|
|
\ea
|
|
\]
|
|
%
|
|
and with substitution in handler definitions
|
|
%
|
|
\begin{equations}
|
|
\cps{\hret}[\cps{V}/x]
|
|
&=& \cps{\hret[V/x]},\\
|
|
\cps{\hops}[\cps{V}/x]
|
|
&=& \cps{\hops[V/x]}.
|
|
\end{equations}
|
|
\end{lemma}
|
|
%
|
|
In order to reason about the behaviour of the \semlab{Op} and
|
|
\semlab{Op^\dagger} rules, which are defined in terms of evaluation
|
|
contexts, we extend the CPS translation to evaluation contexts, using
|
|
the same translations as for the corresponding constructs in $\SCalc$.
|
|
%
|
|
\begin{equations}
|
|
\cps{[~]}
|
|
&=& \slam \shk. \shk \\
|
|
\cps{\Let\; x \revto \EC \;\In\; N}
|
|
&=&
|
|
\begin{array}[t]{@{}l}
|
|
\slam \sRecord{\shf, \sRecord{\svhret, \svhops}} \scons \shk.\\
|
|
\quad \cps{\EC} \sapp (\bl\sRecord{\reflect((\dlam x\,\dhk.\bl\Let\;\dRecord{fs,\dRecord{\vhret,\vhops}}\dcons \dhk'=\dhk\;\In\\
|
|
\cps{N} \sapp (\sRecord{\reflect fs, \sRecord{\reflect \vhret, \reflect \vhops}} \scons \reflect \dhk')) \dcons \reify\shf),\el\\
|
|
\sRecord{\svhret,\svhops}} \scons \shk)\el
|
|
\end{array}
|
|
\\
|
|
\cps{\Handle^\depth\; \EC \;\With\; H}
|
|
&=& \slam \shk.\cps{\EC} \sapp (\sRecord{[], \cps{H}^\depth} \scons \shk)
|
|
\end{equations}
|
|
%
|
|
The following lemma is the characteristic property of the CPS
|
|
translation on evaluation contexts.
|
|
%
|
|
This allows us to focus on the computation within an evaluation
|
|
context.
|
|
%
|
|
\begin{lemma}[Evaluation context decomposition]
|
|
\label{lem:decomposition-gen-cont}
|
|
\[
|
|
\cps{\EC[M]} \sapp (\sRecord{\sV_{fs}, \sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW)
|
|
=
|
|
\cps{M} \sapp (\cps{\EC} \sapp (\sRecord{\sV_{fs}, \sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW))
|
|
\]
|
|
\end{lemma}
|
|
%
|
|
By definition, reifying a reflected dynamic value is the identity
|
|
($\reify \reflect V = V$), but we also need to reason about the
|
|
inverse composition. As a result of the invariant that the translation
|
|
always has static access to the top of the handler stack, the
|
|
translated terms are insensitive to whether the remainder of the stack
|
|
is statically known or is a reflected version of a reified stack. This
|
|
is captured by the following lemma. The proof is by induction on the
|
|
structure of $M$ (after generalising the statement to stacks of
|
|
arbitrary depth), and relies on the observation that translated terms
|
|
either access the top of the handler stack, or reify the stack to use
|
|
dynamically, whereupon the distinction between reflected and reified
|
|
becomes void. Again, this lemma holds when the top of the static
|
|
continuation is known.
|
|
%
|
|
\begin{lemma}[Reflect after reify]
|
|
\label{lem:reflect-after-reify-gen-cont}
|
|
|
|
\[
|
|
\cps{M} \sapp (\sRecord{\sV_{fs}, \sRecord{\sV_{\mret},\sV_{\mops}}} \scons \reflect \reify \sW)
|
|
=
|
|
\cps{M} \sapp (\sRecord{\sV_{fs}, \sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW).
|
|
\]
|
|
\end{lemma}
|
|
|
|
The next lemma states that the CPS translation correctly simulates
|
|
forwarding. The proof is by inspection of how the translation of
|
|
operation clauses treats non-handled operations.
|
|
%
|
|
\begin{lemma}[Forwarding]\label{lem:forwarding-gen-cont}
|
|
If $\ell \notin dom(H_1)$ then:
|
|
%
|
|
\[
|
|
\bl
|
|
\cps{\hops_1}^\delta \dapp \dRecord{\ell, \dRecord{V_p, V_{\dhkr}}} \dapp (\dRecord{V_{fs}, \cps{H_2}^\delta} \dcons W)
|
|
\reducesto^+ \qquad \\
|
|
\hfill
|
|
\cps{\hops_2}^\delta \dapp \dRecord{\ell, \dRecord{V_p, \dRecord{V_{fs}, \cps{H_2}^\delta} \dcons V_{\dhkr}}} \dapp W. \\
|
|
\el
|
|
\]
|
|
%
|
|
\end{lemma}
|
|
|
|
The following lemma is central to our simulation theorem. It
|
|
characterises the sense in which the translation respects the handling
|
|
of operations. Note how the values substituted for the resumption
|
|
variable $r$ in both cases are in the image of the translation of
|
|
$\lambda$-terms in the CPS translation. This is thanks to the precise
|
|
way that the reductions rules for resumption construction works in our
|
|
dynamic language, as described above.
|
|
%
|
|
\begin{lemma}[Handling]\label{lem:handle-op-gen-cont}
|
|
Suppose $\ell \notin BL(\EC)$ and $\hell = \{\ell\,p\,r \mapsto N_\ell\}$. If $H$ is deep then
|
|
%
|
|
\[
|
|
\bl
|
|
\cps{\Do\;\ell\;V} \sapp (\cps{\EC} \sapp (\sRecord{\snil, \cps{H}} \scons \sRecord{\sV_{fs},\sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW)) \reducesto^+ \\
|
|
\quad (\cps{N_\ell} \sapp \sRecord{\sV_{fs},\sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW)\\
|
|
\qquad \quad [\cps{V}/p,
|
|
\dlam x\,\dhk.\bl
|
|
\Let\;\dRecord{fs, \dRecord{\vhret, \vhops}} \dcons \dhk' = \dhk\;\In\;\\
|
|
\cps{\Return\;x} \sapp (\cps{\EC} \sapp (\sRecord{\snil, \cps{H}} \scons \sRecord{\reflect \dlk, \sRecord{\reflect \vhret, \reflect \vhops}} \scons \reflect\dhk'))/r]. \\
|
|
\el\\
|
|
\el
|
|
\]
|
|
%
|
|
Otherwise if $H$ is shallow then
|
|
%
|
|
\[
|
|
\bl
|
|
\cps{\Do\;\ell\;V} \sapp (\cps{\EC} \sapp (\sRecord{\snil, \cps{H}^\dagger} \scons \sRecord{\sV_{fs},\sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW)) \reducesto^+ \\
|
|
\quad (\cps{N_\ell} \sapp \sRecord{\sV_{fs},\sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW)\\
|
|
\qquad [\cps{V}/p, \dlam x\,\dhk. \bl
|
|
\Let\;\dRecord{\dlk, \dRecord{\vhret, \vhops}} \dcons \dhk' = \dhk \;\In \\
|
|
\cps{\Return\;x} \sapp (\cps{\EC} \sapp (\sRecord{\reflect \dlk, \sRecord{\reflect \vhret, \reflect \vhops}} \scons \reflect\dhk'))/r]. \\
|
|
\el \\
|
|
\el
|
|
\]
|
|
%
|
|
\end{lemma}
|
|
|
|
\medskip
|
|
|
|
Now the main result for the translation: a simulation result in the
|
|
style of \citet{Plotkin75}.
|
|
%
|
|
\begin{theorem}[Simulation]
|
|
\label{thm:ho-simulation-gen-cont}
|
|
If $M \reducesto N$ then
|
|
\[
|
|
\cps{M} \sapp (\sRecord{\sV_{fs}, \sRecord{\sV_{\mret},\sV_{\mops}}}
|
|
\scons \sW) \reducesto^+ \cps{N} \sapp (\sRecord{\sV_{fs},
|
|
\sRecord{\sV_{\mret},\sV_{\mops}}} \scons \sW).
|
|
\]
|
|
\end{theorem}
|
|
|
|
\begin{proof}
|
|
The proof is by case analysis on the reduction relation using Lemmas
|
|
\ref{lem:decomposition-gen-cont}--\ref{lem:handle-op-gen-cont}. In
|
|
particular, the \semlab{Op} and \semlab{Op^\dagger} cases follow
|
|
from Lemma~\ref{lem:handle-op-gen-cont}.
|
|
\end{proof}
|
|
|
|
In common with most CPS translations, full abstraction does not hold
|
|
(a function could count the number of handlers it is invoked within by
|
|
examining the continuation, for example). However, as the semantics is
|
|
deterministic it is straightforward to show a backward simulation
|
|
result.
|
|
%
|
|
\begin{lemma}[Backwards simulation]
|
|
If $\pcps{M} \reducesto^+ V$ then there exists $W$
|
|
such that $M \reducesto^* W$ and $\pcps{W} = V$.
|
|
\end{lemma}
|
|
%
|
|
\begin{corollary}
|
|
$M \reducesto^\ast V$ if and only if $\pcps{M} \reducesto^\ast \pcps{V}$.
|
|
\end{corollary}
|
|
|
|
\section{Related work}
|
|
\label{sec:cps-related-work}
|
|
|
|
\paragraph{Plotkin's colon translation}
|
|
|
|
The original method for proving the correctness of a CPS
|
|
translation is by way of a simulation result. Simulation states that
|
|
every reduction sequence in a given source program is mimicked by its
|
|
CPS transformation.
|
|
%
|
|
Static administrative redexes in the image of a CPS translation
|
|
provide hurdles for proving simulation, since these redexes do not
|
|
arise in the source program.
|
|
%
|
|
\citet{Plotkin75} uses the so-called \emph{colon translation} to
|
|
overcome static administrative reductions.
|
|
%
|
|
Informally, it is defined such that given some source term $M$ and
|
|
some continuation $k$, then the term $M : k$ is the result of
|
|
performing all static administrative reductions on $\cps{M}\,k$, that
|
|
is to say $\cps{M}\,k \areducesto^* M : k$.
|
|
%
|
|
Thus this translation makes it possible to bypass administrative
|
|
reductions and instead focus on the reductions inherited from the
|
|
source program.
|
|
%
|
|
The colon translation captures precisely the intuition that drives CPS
|
|
transforms, namely, that if in the source $M \reducesto^\ast \Return\;V$
|
|
then in the image $\cps{M}\,k \reducesto^\ast k\,\cps{V}$.
|
|
|
|
\dhil{Check whether the first pass marks administrative redexes}
|
|
|
|
|
|
% CPS The colon translation captures the
|
|
% intuition tThe colon translation is itself a CPS translation which
|
|
% yields
|
|
|
|
|
|
% In his seminal work, \citet{Plotkin75} devises CPS translations for
|
|
% call-by-value lambda calculus into call-by-name lambda calculus and
|
|
% vice versa. \citeauthor{Plotkin75} establishes the correctness of his
|
|
% translations by way of simulations, which is to say that every
|
|
% reduction sequence in a given source program is mimicked by the
|
|
% transformed program.
|
|
% %
|
|
% His translations generate static administrative redexes, and as argued
|
|
% previously in this chapter from a practical view point this is an
|
|
% undesirable property in practice. However, it is also an undesirable
|
|
% property from a theoretical view point as the presence of
|
|
% administrative redexes interferes with the simulation proofs.
|
|
|
|
% To handle the static administrative redexes, \citeauthor{Plotkin75}
|
|
% introduced the so-called \emph{colon translation} to bypass static
|
|
% administrative reductions, thus providing a means for focusing on
|
|
% reductions induced by abstractions inherited from the source program.
|
|
% %
|
|
% The colon translation is itself a CPS translation, that given a source
|
|
% expression, $e$, and some continuation, $K$, produces a CPS term such
|
|
% that $\cps{e}K \reducesto e : K$.
|
|
|
|
% \citet{DanvyN03} used this insight to devise a one-pass CPS
|
|
% translation that contracts all administrative redexes at translation
|
|
% time.
|
|
|
|
\paragraph{Iterated CPS transform}
|
|
|
|
\paragraph{Partial evaluation}
|
|
|
|
\chapter{Abstract machine semantics}
|
|
\label{ch:abstract-machine}
|
|
\dhil{The text is this chapter needs to be reworked}
|
|
|
|
In this chapter we develop an abstract machine that supports deep and
|
|
shallow handlers \emph{simultaneously}, using the generalised
|
|
continuation structure we identified in the previous section for the
|
|
CPS translation. We also build upon prior work~\citep{HillerstromL16}
|
|
that developed an abstract machine for deep handlers by generalising
|
|
the continuation structure of a CEK machine (Control, Environment,
|
|
Kontinuation)~\citep{FelleisenF86}.
|
|
%
|
|
% \citet{HillerstromL16} sketched an adaptation for shallow handlers. It
|
|
% turns out that this adaptation had a subtle flaw, similar to the flaw
|
|
% in the sketched implementation of a CPS translation for shallow
|
|
% handlers given by \citet{HillerstromLAS17}. We fix the flaw here with
|
|
% a full development of shallow handlers along with a statement of the
|
|
% correctness property.
|
|
|
|
\section{Syntax and semantics}
|
|
The abstract machine syntax is given in
|
|
Figure~\ref{fig:abstract-machine-syntax}.
|
|
% A machine continuation is a list of handler frames. A handler frame is
|
|
% a pair of a \emph{handler closure} (handler definition) and a
|
|
% \emph{pure continuation} (a sequence of let bindings), analogous to
|
|
% the structured frames used in the CPS translation in
|
|
% \Sec\ref{sec:higher-order-uncurried-cps}.
|
|
% %
|
|
% Handling an operation amounts to searching through the continuation
|
|
% for a matching handler.
|
|
% %
|
|
% The resumption is constructed during the search by reifying each
|
|
% handler frame. As in the CPS translation, the resumption is assembled
|
|
% in one of two ways depending on whether the matching handler is deep
|
|
% or shallow.
|
|
% %
|
|
% For a deep handler, the current handler closure is included, and a deep
|
|
% resumption is a reified continuation.
|
|
% %
|
|
% An invocation of a deep resumption amounts to concatenating it with
|
|
% the current machine continuation.
|
|
% %
|
|
% For a shallow handler, the current handler closure must be discarded
|
|
% leaving behind a dangling pure continuation, and a shallow resumption
|
|
% is a pair of this pure continuation and the remaining reified
|
|
% continuation.
|
|
% %
|
|
% (By contrast, the prior flawed adaptation prematurely precomposed the
|
|
% pure continuation with the outer handler in the current resumption.)
|
|
% %
|
|
% An invocation of a shallow resumption again amounts to concatenating
|
|
% it with the current machine continuation, but taking care to
|
|
% concatenate the dangling pure continuation with that of the next
|
|
% frame.
|
|
%
|
|
\begin{figure}[t]
|
|
\flushleft
|
|
\begin{syntax}
|
|
\slab{Configurations} & \conf &::= & \cek{M \mid \env \mid \shk \circ \shk'} \\
|
|
\slab{Value environments} &\env &::= & \emptyset \mid \env[x \mapsto v] \\
|
|
\slab{Values} &v, w &::= & (\env, \lambda x^A . M) \mid (\env, \Lambda \alpha^K . M) \\
|
|
& &\mid& \Record{} \mid \Record{\ell = v; w} \mid (\ell\, v)^R \mid \shk^A \mid (\shk, \slk)^A \medskip\\
|
|
% \end{syntax}
|
|
% \begin{displaymath}
|
|
% \ba{@{}l@{~~}r@{~}c@{~}l@{\quad}l@{~~}r@{~}c@{~}l@{}}
|
|
% \slab{Continuations} &\shk &::= & \nil \mid \shf \cons \shk & \slab{Continuation frames} &\shf &::= & (\slk, \chi) \\
|
|
% & & & & \slab{Handler closures} &\chi &::= & (\env, H)^\depth \smallskip \\
|
|
% \slab{Pure continuations} &\slk &::= & \nil \mid \slf \cons \slk & \slab{Pure continuation frames} &\slf &::= & (\env, x, N) \\
|
|
% \ea
|
|
% \end{displaymath}
|
|
% \begin{syntax}
|
|
\slab{Continuations} &\shk &::= & \nil \mid \shf \cons \shk \\
|
|
\slab{Continuation frames} &\shf &::= & (\slk, \chi) \\
|
|
\slab{Pure continuations} &\slk &::= & \nil \mid \slf \cons \slk \\
|
|
\slab{Pure continuation frames} &\slf &::= & (\env, x, N) \\
|
|
\slab{Handler closures} &\chi &::= & (\env, H) \mid (\env, H)^\dagger \medskip \\
|
|
\end{syntax}
|
|
|
|
\caption{Abstract machine syntax.}
|
|
\label{fig:abstract-machine-syntax}
|
|
\end{figure}
|
|
|
|
%% A CEK machine~\citep{FelleisenF86} operates on configurations, which
|
|
%% are (Control, Environment, Continuation) triples.
|
|
%% %
|
|
% Our machine, like Hillerström and Lindley's, generalises the usual
|
|
% notion of continuation to accommodate handlers.
|
|
%
|
|
%
|
|
\begin{figure}[p]
|
|
\dhil{Fix figure formatting}
|
|
\begin{minipage}{0.90\textheight}%
|
|
%% Identity continuation
|
|
%% \[
|
|
%% \shk_0 = [(\nil, (\emptyset, \{\Return\;x \mapsto x\}))]
|
|
%% \]
|
|
|
|
\textbf{Transition function}
|
|
\begin{displaymath}
|
|
\bl
|
|
\ba{@{}l@{~}r@{~}c@{~}l@{\quad}l@{}}
|
|
\mlab{Init} & \multicolumn{4}{@{}c@{}}{M \stepsto \cek{M \mid \emptyset \mid [(\nil, (\emptyset, \{\Return\;x \mapsto \Return\;x\}))]}} \\[1ex]
|
|
% App
|
|
\mlab{AppClosure} & \cek{ V\;W \mid \env \mid \shk}
|
|
&\stepsto& \cek{ M \mid \env'[x \mapsto \val{W}{\env}] \mid \shk},
|
|
&\text{if }\val{V}{\env} = (\env', \lambda x^A.M) \\
|
|
|
|
\mlab{AppRec} & \cek{ V\;W \mid \env \mid \shk}
|
|
&\stepsto& \cek{ M \mid \env'[g \mapsto (\env', \Rec\,g^{A \to C}\,x.M), x \mapsto \val{W}{\env}] \mid \shk},
|
|
&\text{if }\val{V}{\env} = (\env', \Rec\,g^{A \to C}\,x.M) \\
|
|
|
|
% App - continuation
|
|
\mlab{AppCont} & \cek{ V\;W \mid \env \mid \shk}
|
|
&\stepsto& \cek{ \Return \; W \mid \env \mid \shk' \concat \shk},
|
|
&\text{if }\val{V}{\env} = (\shk')^A \\
|
|
|
|
\mlab{AppCont^\dagger} & \cek{ V\,W \mid \env \mid (\slk, \chi) \cons \shk}
|
|
&\stepsto&
|
|
\cek{\Return\; W \mid \env \mid \shk' \concat ((\slk' \concat \slk, \chi) \cons \shk)},
|
|
&\text{if } \val{V}{\env} = (\shk', \slk')^A \\
|
|
|
|
% TyApp
|
|
\mlab{AppType} & \cek{ V\,T \mid \env \mid \shk}
|
|
&\stepsto& \cek{ M[T/\alpha] \mid \env' \mid \shk},
|
|
&\text{if }\val{V}{\env} = (\env', \Lambda \alpha^K . \, M) \\[1ex]
|
|
\ea \\
|
|
\ba{@{}l@{}r@{~}c@{~}l@{\quad}l@{}}
|
|
\mlab{Split} & \cek{ \Let \; \Record{\ell = x;y} = V \; \In \; N \mid \env \mid \shk}
|
|
&\stepsto& \cek{ N \mid \env[x \mapsto v, y \mapsto w] \mid \shk},
|
|
& \text {if }\val{V}{\env} = \Record{\ell=v; w} \\
|
|
|
|
% Case
|
|
\mlab{Case} & \cek{ \Case\; V\, \{ \ell~x \mapsto M; y \mapsto N\} \mid \env \mid \shk}
|
|
&\stepsto& \left\{\ba{@{}l@{}}
|
|
\cek{ M \mid \env[x \mapsto v] \mid \shk}, \\
|
|
\cek{ N \mid \env[y \mapsto \ell'\, v] \mid \shk}, \\
|
|
\ea \right.
|
|
&
|
|
\ba{@{}l@{}}
|
|
\text{if }\val{V}{\env} = \ell\, v \\
|
|
\text{if }\val{V}{\env} = \ell'\, v \text{ and } \ell \neq \ell' \\
|
|
\ea \\[2ex]
|
|
|
|
% Let - eval M
|
|
\mlab{Let} & \cek{ \Let \; x \revto M \; \In \; N \mid \env \mid (\slk, \chi) \cons \shk}
|
|
&\stepsto& \cek{ M \mid \env \mid ((\env,x,N) \cons \slk, \chi) \cons \shk} \\
|
|
|
|
% Handle
|
|
\mlab{Handle} & \cek{ \Handle^\depth \, M \; \With \; H \mid \env \mid \shk}
|
|
&\stepsto& \cek{ M \mid \env \mid (\nil, (\env, H)^\depth) \cons \shk} \\[1ex]
|
|
|
|
% Return - let binding
|
|
\mlab{RetCont} &\cek{ \Return \; V \mid \env \mid ((\env',x,N) \cons \slk, \chi) \cons \shk}
|
|
&\stepsto& \cek{ N \mid \env'[x \mapsto \val{V}{\env}] \mid (\slk, \chi) \cons \shk} \\
|
|
|
|
% Return - handler
|
|
\mlab{RetHandler} & \cek{ \Return \; V \mid \env \mid (\nil, (\env',H)) \cons \shk}
|
|
&\stepsto& \cek{ M \mid \env'[x \mapsto \val{V}{\env}] \mid \shk},
|
|
& \text{if } \hret = \{\Return\; x \mapsto M\} \\
|
|
\mlab{RetTop} & \cek{\Return\;V \mid \env \mid \nil} &\stepsto& \val{V}{\env} \\[1ex]
|
|
|
|
% Deep
|
|
\mlab{Do} & \cek{ (\Do \; \ell \; V)^E \mid \env \mid ((\slk, (\env', H)) \cons \shk) \circ \shk'}
|
|
&\stepsto& \multicolumn{2}{@{}l@{}}{\cek{M \mid \env'[x \mapsto \val{V}{\env},
|
|
r \mapsto (\shk' \concat [(\slk, (\env', H))])^B] \mid \shk},} \\
|
|
&&& \multicolumn{2}{@{}r@{}}{\text{if } \ell : A \to B \in E \text{ and } \hell = \{\ell\; x \; r \mapsto M\}} \\
|
|
|
|
% Shallow
|
|
\mlab{Do^\dagger} & \cek{ (\Do \; \ell \; V)^E \mid \env \mid ((\slk, (\gamma', H)^\dagger) \cons \shk) \circ \shk'} &\stepsto&
|
|
\multicolumn{2}{@{}l@{}}{\cek{M \mid \env'[x \mapsto \val{V}{\env}, r \mapsto (\shk', \slk)^B] \mid \shk},}\\
|
|
&&&\multicolumn{2}{@{}r@{}}{\text{if } \ell : A \to B \in E \text{ and } \hell = \{\ell\; x \; r \mapsto M\}} \\
|
|
|
|
% Forward
|
|
\mlab{Forward} & \cek{ (\Do \; \ell \; V)^E \mid \env \mid ((\slk, (\env', H)^\depth) \cons \shk) \circ \shk'}
|
|
&\stepsto& \cek{ (\Do \; \ell \; V)^E \mid \env \mid \shk \circ (\shk' \concat [(\slk, (\env', H)^\depth)])},
|
|
& \text{if } \hell = \emptyset \\
|
|
\ea \\
|
|
\el
|
|
\end{displaymath}
|
|
|
|
\textbf{Value interpretation}
|
|
\begin{displaymath}
|
|
\ba{@{}r@{~}c@{~}l@{}}
|
|
\val{x}{\env} &=& \env(x) \\
|
|
\val{\Record{}}{\env} &=& \Record{} \\
|
|
\ea
|
|
\qquad
|
|
\ba{@{}r@{~}c@{~}l@{}}
|
|
\val{\lambda x^A.M}{\env} &=& (\env, \lambda x^A.M) \\
|
|
\val{\Record{\ell = V; W}}{\env} &=& \Record{\ell = \val{V}{\env}; \val{W}{\env}} \\
|
|
\ea
|
|
\qquad
|
|
\ba{@{}r@{~}c@{~}l@{}}
|
|
\val{\Lambda \alpha^K.M}{\env} &=& (\env, \Lambda \alpha^K.M) \\
|
|
\val{(\ell\, V)^R}{\env} &=& (\ell\; \val{V}{\env})^R \\
|
|
\ea
|
|
\qquad
|
|
\val{\Rec\,g^{A \to C}\,x.M}{\env} = (\env, \Rec\,g^{A \to C}\,x.M) \\
|
|
\end{displaymath}
|
|
|
|
\caption{Abstract machine semantics.}
|
|
\label{fig:abstract-machine-semantics}
|
|
\end{minipage}
|
|
\end{figure}
|
|
%
|
|
%
|
|
A configuration $\conf = \cek{M \mid \env \mid \shk \circ \shk'}$
|
|
of our abstract machine is a quadruple of a computation term ($M$), an
|
|
environment ($\env$) mapping free variables to values, and two
|
|
continuations ($\shk$) and ($\shk'$).
|
|
%
|
|
The latter continuation is always the identity, except when forwarding
|
|
an operation, in which case it is used to keep track of the extent to
|
|
which the operation has been forwarded.
|
|
%
|
|
We write $\cek{M \mid \env \mid \shk}$ as syntactic sugar for $\cek{M
|
|
\mid \env \mid \shk \circ []}$ where $[]$ is the identity
|
|
continuation.
|
|
%
|
|
%% Our continuations differ from the standard machine. On the one hand,
|
|
%% they are somewhat simplified, due to our strict separation between
|
|
%% computations and values. On the other hand, they have considerably
|
|
%% more structure in order to accommodate effects and handlers.
|
|
|
|
Values consist of function closures, type function closures, records,
|
|
variants, and captured continuations.
|
|
%
|
|
A continuation $\shk$ is a stack of frames $[\shf_1, \dots,
|
|
\shf_n]$. We annotate captured continuations with input types in order
|
|
to make the results of Section~\ref{subsec:machine-correctness} easier
|
|
to state. Each frame $\shf = (\slk, \chi)$ represents pure
|
|
continuation $\slk$, corresponding to a sequence of let bindings,
|
|
inside handler closure $\chi$.
|
|
%
|
|
A pure continuation is a stack of pure frames. A pure frame $(\env, x,
|
|
N)$ closes a let-binding $\Let \;x=[~] \;\In\;N$ over environment
|
|
$\env$. A handler closure $(\env, H)$ closes a handler definition $H$
|
|
over environment $\env$.
|
|
%
|
|
We write $\nil$ for an empty stack, $x \cons s$ for the result of
|
|
pushing $x$ on top of stack $s$, and $s \concat s'$ for the
|
|
concatenation of stack $s$ on top of $s'$. We use pattern matching to
|
|
deconstruct stacks.
|
|
|
|
The abstract machine semantics defining the transition function $\stepsto$ is given in
|
|
Fig.~\ref{fig:abstract-machine-semantics}.
|
|
%
|
|
It depends on an interpretation function $\val{-}$ for values.
|
|
%
|
|
The machine is initialised (\mlab{Init}) by placing a term in a
|
|
configuration alongside the empty environment and identity
|
|
continuation.
|
|
%
|
|
The rules (\mlab{AppClosure}), (\mlab{AppRec}), (\mlab{AppCont}),
|
|
(\mlab{AppCont^\dagger}), (\mlab{AppType}), (\mlab{Split}), and
|
|
(\mlab{Case}) enact the elimination of values.
|
|
%
|
|
The rules (\mlab{Let}) and (\mlab{Handle}) extend the current
|
|
continuation with let bindings and handlers respectively.
|
|
%
|
|
The rule (\mlab{RetCont}) binds a returned value if there is a pure
|
|
continuation in the current continuation frame;
|
|
%
|
|
(\mlab{RetHandler}) invokes the return clause of a handler if the pure
|
|
continuation is empty; and (\mlab{RetTop}) returns a final value if
|
|
the continuation is empty.
|
|
%
|
|
%% The rule (\mlab{Op}) switches to a special four place configuration in
|
|
%% order to handle an operation. The fourth component of the
|
|
%% configuration is an auxiliary forwarding continuation, which keeps
|
|
%% track of the continuation frames through which the operation has been
|
|
%% forwarded. It is initialised to be empty.
|
|
%% %
|
|
The rule (\mlab{Do}) applies the current handler to an operation if
|
|
the label matches one of the operation clauses. The captured
|
|
continuation is assigned the forwarding continuation with the current
|
|
frame appended to the end of it.
|
|
%
|
|
The rule (\mlab{Do^\dagger}) is much like (\mlab{Do}), except it
|
|
constructs a shallow resumption, discarding the current handler but
|
|
keeping the current pure continuation.
|
|
%
|
|
The rule (\mlab{Forward}) appends the current continuation
|
|
frame onto the end of the forwarding continuation.
|
|
%
|
|
The (\mlab{Init}) rule provides a canonical way to map a computation
|
|
term onto a configuration.
|
|
|
|
\newcommand{\Chiid}{\ensuremath{\Chi_{\text{id}}}}
|
|
\newcommand{\kappaid}{\ensuremath{\kappa_{\text{id}}}}
|
|
|
|
\paragraph{Example} To make the transition rules in
|
|
Figure~\ref{fig:abstract-machine-semantics} concrete we give an
|
|
example of the abstract machine in action. We reuse the small producer
|
|
and consumer from Section~\ref{sec:shallow-handlers-tutorial}. We
|
|
reproduce their definitions here in ANF.
|
|
%
|
|
\[
|
|
\bl
|
|
\Ones \defas \Rec\;ones~\Unit. \Do\; \Yield~1; ones~\Unit \\
|
|
\AddTwo \defas
|
|
\lambda \Unit.
|
|
\Let\; x \revto \Do\;\Await~\Unit \;\In\;
|
|
\Let\; y \revto \Do\;\Await~\Unit \;\In\;
|
|
x + y \\
|
|
\el
|
|
\]%
|
|
%
|
|
Let $N_x$ denote the term $\Let\;x \revto \Do\;\Await~\Unit\;\In\;N_y$
|
|
and $N_y$ the term $\Let\;y \revto \Do\;\Await~\Unit\;\In\;x+y$.
|
|
%
|
|
%% For clarity, we annotate each bound variable $resume$ with a subscript
|
|
%% $\Await$ or $\Yield$ according to whether it was captured by a
|
|
%% consumer or a producer.
|
|
%
|
|
Suppose $\Ones$, $\AddTwo$, $\Pipe$, and $\Copipe$ are bound in
|
|
$\env_\top$. Furthermore, let $H_\Pipe$ and $H_\Copipe$ denote the
|
|
pipe and copipe handler definitions. The machine begins by applying
|
|
$\Pipe$.
|
|
%
|
|
\begin{derivation}
|
|
&\cek{\Pipe~\Record{\Ones, \AddTwo} \mid \env_\top \mid \kappaid}\\
|
|
\stepsto& \reason{apply $\Pipe$}\\
|
|
&\cek{\ShallowHandle\;c~\Unit\;\With\;H_\Pipe \mid \env_\top[c \mapsto (\emptyset, \AddTwo), p \mapsto (\emptyset, \Ones)] \mid \kappaid}\\
|
|
\stepsto& \reason{install $H_\Pipe$ with $\env_\Pipe = \env_\top[c \mapsto (\emptyset, \AddTwo), p \mapsto (\emptyset, \Ones)]$}\\
|
|
&\cek{c~\Unit \mid \env_\Pipe \mid (\nil, (\env_\Pipe, H_\Pipe)) \cons \kappaid}\\
|
|
\stepsto& \reason{apply $c$ and $\val{c}\env_\Pipe = (\emptyset, \AddTwo)$}\\
|
|
&\cek{N_x \mid \emptyset \mid (\nil, (\env_\Pipe, H_\Pipe)) \cons \kappaid}\\
|
|
\stepsto& \reason{focus on left operand}\\
|
|
&\cek{\Do\;\Await~\Unit \mid \emptyset \mid ([(\emptyset, x, N_y)], (\env_\Pipe, H_\Pipe)) \cons \kappaid}\\
|
|
\stepsto& \reason{shallow continuation capture $v_\Await = (\nil, [(\emptyset, x, N_y)])$}\\
|
|
&\cek{\Copipe~\Record{resume, p} \mid \env_\Pipe[resume \mapsto v_\Await] \mid \kappaid}\\
|
|
\end{derivation}
|
|
%
|
|
The invocation of $\Await$ begins a search through the machine
|
|
continuation to locate a matching handler. In this instance the
|
|
top-most handler $H_\Pipe$ handles $\Await$. The complete shallow
|
|
resumption consists of an empty continuation and a singleton pure
|
|
continuation. The former is empty as $H_\Pipe$ is a shallow handler,
|
|
meaning that it is discarded.
|
|
|
|
Evaluation continues by applying $\Copipe$.
|
|
%
|
|
\begin{derivation}
|
|
\stepsto& \reason{apply $\Copipe$}\\
|
|
&\cek{\ShallowHandle\; p~\Unit \;\With\;H_\Copipe \mid \env_\top[c \mapsto v_\Await, p \mapsto (\emptyset, \Ones)] \mid \kappaid}\\
|
|
\stepsto& \reason{install $H_\Copipe$ with $\env_\Copipe = \env_\top[c \mapsto v_\Await, p \mapsto (\emptyset, \Ones)]$}\\
|
|
&\cek{p~\Unit \mid \env_\Copipe \mid (\emptyset, (\env_\Copipe, H_\Copipe)) \cons \kappaid}\\
|
|
\stepsto^2& \reason{apply $p$, $\val{p}\env_\Copipe = (\emptyset, \Ones)$, and $\env_{\Ones} = \emptyset[ones \mapsto (\emptyset, \Ones)]$}\\
|
|
% &\cek{\Do\;\Yield~1;~ones~\Unit \mid \env_{ones} \mid (\nil, (\env_\Copipe, H_\Copipe)) \cons \kappaid}\\
|
|
% \stepsto^2& \reason{focus on $\Yield$}\\
|
|
&\cek{\Do\;\Yield~1 \mid \env_{\Ones} \mid ([(\env_{\Ones},\_,ones~\Unit)], (\env_\Copipe, H_\Copipe)) \cons \kappaid}\\
|
|
\stepsto& \reason{shallow continuation capture $v_\Yield = (\nil, [(\env_{\Ones}, \_, ones~\Unit)])$}\\
|
|
&\cek{\Pipe~\Record{resume, \lambda\Unit.c~s} \mid \env_\Copipe[s \mapsto 1,resume \mapsto v_\Yield] \mid \kappaid}
|
|
\end{derivation}
|
|
%
|
|
At this point the situation is similar as before: the invocation of
|
|
$\Yield$ causes the continuation to be unwound in order to find an
|
|
appropriate handler, which happens to be $H_\Copipe$. Next $\Pipe$ is
|
|
applied.
|
|
%
|
|
\begin{derivation}
|
|
\stepsto& \reason{apply $\Pipe$ and $\env_\Pipe' = \env_\top[c \mapsto (\env_\Copipe[c \mapsto v_\Await, s\mapsto 1]), p \mapsto v_\Yield])]$}\\
|
|
&\cek{\ShallowHandle\;c~\Unit\;\With\; H_\Pipe \mid \env_\Pipe' \mid \kappaid}\\
|
|
\stepsto& \reason{install $H_\Pipe$}\\
|
|
&\cek{c~\Unit \mid \env_\Pipe' \mid (\nil, (\env_\Pipe', H_\Pipe)) \cons \kappaid}\\
|
|
\stepsto& \reason{apply $c$ and $\val{c}\env_\Pipe' = (\env_\Copipe[c \mapsto v_\Await, s\mapsto 1])$}\\
|
|
&\cek{c~s \mid \env_\Copipe[c \mapsto v_\Await, s\mapsto 1] \mid (\nil, (\env_\Pipe', H_\Pipe)) \cons \kappaid}\\
|
|
\stepsto& \reason{shallow resume with $v_\Await = (\nil, [(\emptyset,x,N_y)])$}\\
|
|
&\cek{\Return\;1 \mid \env_\Pipe' \mid ([(\emptyset,x,N_y)], (\env_\Pipe', H_\Pipe)) \cons \kappaid}
|
|
\end{derivation}
|
|
%
|
|
Applying the resumption concatenates the first component (the
|
|
continuation) with the machine continuation. The second component
|
|
(pure continuation) gets concatenated with the pure continuation of
|
|
the top-most frame of the machine continuation. Thus in this
|
|
particular instance, the machine continuation is manipulated as
|
|
follows.
|
|
%
|
|
\[
|
|
\ba{@{~}l@{~}l}
|
|
&\nil \concat ([(\emptyset,x,N_y)] \concat \nil, (\env_\Pipe', H_\Pipe)) \cons \kappaid\\
|
|
=& ([(\emptyset,x,N_y)], (\env_\Pipe', H_\Pipe)) \cons \kappaid
|
|
\ea
|
|
\]
|
|
%
|
|
Because the control component contains the expression $\Return\;1$ and
|
|
the pure continuation is nonempty, the machine applies the pure
|
|
continuation.
|
|
\begin{derivation}
|
|
\stepsto& \reason{apply pure continuation, $\env_{\AddTwo} = \emptyset[x \mapsto 1]$}\\
|
|
&\cek{N_y \mid \env_{\AddTwo} \mid (\nil, (\env_\Pipe', H_\Pipe)) \cons \kappaid}\\
|
|
\stepsto& \reason{focus on right operand}\\
|
|
&\cek{\Do\;\Await~\Unit \mid \env_{\AddTwo} \mid ([(\env_{\AddTwo}, y, x + y)], (\env_\Pipe', H_\Pipe)) \cons \kappaid}\\
|
|
\stepsto^2& \reason{shallow continuation capture $w_\Await = (\nil, [(\env_{\AddTwo}, y, x + y)])$, apply $\Copipe$}\\
|
|
&\cek{\ShallowHandle\;p~\Unit \;\With\; \env_\Copipe \mid \env_\top[c \mapsto w_\Await, p \mapsto v_\Yield] \mid \kappaid}\\
|
|
\reducesto& \reason{install $H_\Copipe$ with $\env_\Copipe = \env_\top[c \mapsto w_\Await, p \mapsto v_\Yield]$}\\
|
|
&\cek{p~\Unit \mid \env_\Copipe \mid (\nil, (\env_\Copipe, H_\Copipe)) \cons \kappaid}
|
|
\end{derivation}
|
|
%
|
|
The variable $p$ is bound to the shallow resumption $v_\Yield$, thus
|
|
invoking it will transfer control back to the $\Ones$ computation.
|
|
%
|
|
\begin{derivation}
|
|
\stepsto & \reason{shallow resume with $v_\Yield = (\nil, [(\env_{\Ones}, \_, ones~\Unit)])$}\\
|
|
&\cek{\Return\;\Unit \mid \env_\Copipe \mid ([(\env_{\Ones}, \_, ones~\Unit)], (\env_\Copipe, H_\Copipe)) \cons \kappaid}\\
|
|
\stepsto^3& \reason{apply pure continuation, apply $ones$, focus on $\Yield$}\\
|
|
&\cek{\Do\;\Yield~1 \mid \env_{\Ones} \mid ([(\env_{\Ones}, \_, ones~\Unit)], (\env_\Copipe, H_\Copipe)) \cons \kappaid}\\
|
|
\end{derivation}
|
|
%
|
|
At this stage the machine repeats the transitions from before: the
|
|
shallow continuation of $\Do\;\Yield~1$ is captured, control passes to
|
|
the $\Yield$ clause in $H_\Copipe$, which again invokes $\Pipe$ and
|
|
subsequently installs the $H_\Pipe$ handler with an environment
|
|
$\env_\Pipe''$. The handler runs the computation $c~\Unit$, where $c$
|
|
is an abstraction over the resumption $w_\Await$ applied to the
|
|
yielded value $1$.
|
|
%
|
|
\begin{derivation}
|
|
\stepsto^6 & \reason{by the above reasoning, shallow resume with $w_\Await = (\nil, [(\env_{\AddTwo}, y, x + y)])$}\\
|
|
&\cek{x + y \mid \env_{\AddTwo}[y \mapsto 1] \mid (\nil, (\env_\Pipe'', H_\Pipe)) \cons \kappaid}\\
|
|
\stepsto& \reason{$\val{x}\env_{\AddTwo}[y\mapsto 1] = 1$ and $\val{y}\env_{\AddTwo}[y\mapsto 1] = 1$}\\
|
|
&\cek{\Return\;2 \mid \env_{\AddTwo}[y \mapsto 1] \mid (\nil, (\env_\Pipe'', H_\Pipe)) \cons \kappaid}
|
|
\end{derivation}
|
|
%
|
|
Since the pure continuation is empty the $\Return$ clause of $H_\Pipe$
|
|
gets invoked with the value $2$. Afterwards the $\Return$ clause of the
|
|
identity continuation in $\kappaid$ is invoked, ultimately
|
|
transitioning to the following final configuration.
|
|
%
|
|
\begin{derivation}
|
|
\stepsto^2& \reason{by the above reasoning}\\
|
|
&\cek{\Return\;2 \mid \emptyset \mid \nil}
|
|
\end{derivation}
|
|
%
|
|
%\env_\top[c \mapsto (\env_\Copipe, \lambda\Unit.w_\Await~1),p \mapsto (\nil, [(\env_{\Ones}, \_, ones~\Unit)])]
|
|
\begin{figure}[t]
|
|
\flushleft
|
|
\newcommand{\contapp}[2]{#1 #2}
|
|
\newcommand{\contappp}[2]{#1(#2)}
|
|
%% \newcommand{\contapp}[2]{#1[#2]}
|
|
%% \newcommand{\contapp}[2]{#1\mathbin{@}#2}
|
|
%% \newcommand{\contappp}[2]{#1\mathbin{@}(#2)}
|
|
%
|
|
Configurations
|
|
\begin{displaymath}
|
|
\inv{\cek{M \mid \env \mid \shk \circ \shk'}} = \contappp{\inv{\shk' \concat \shk}}{\inv{M}\env}
|
|
= \contappp{\inv{\shk'}}{\contapp{\inv{\shk}}{\inv{M}\env}}
|
|
\end{displaymath}
|
|
|
|
Pure continuations
|
|
\begin{displaymath}
|
|
\contapp{\inv{[]}}{M} = M \qquad \contapp{\inv{((\env, x, N) \cons \slk)}}{M}
|
|
= \contappp{\inv{\slk}}{\Let\; x \revto M \;\In\; \inv{N}(\env \res \{x\})}
|
|
\end{displaymath}
|
|
%% \begin{equations}
|
|
%% \contapp{\inv{[]}}{M}
|
|
%% &=& M \\
|
|
%% \contapp{\inv{((\env, x, N) \cons \slk)}}{M}
|
|
%% &=& \contappp{\inv{\slk}}{\Let\; x \revto M \;\In\; \inv{N}(\env \res \{x\})} \\
|
|
%% \end{equations}
|
|
|
|
Continuations
|
|
\begin{displaymath}
|
|
\contapp{\inv{[]}}{M}
|
|
= M \qquad
|
|
\contapp{\inv{(\slk, \chi) \cons \shk}}{M}
|
|
= \contapp{\inv{\shk}}{(\contappp{\inv{\chi}}{\contappp{\inv{\slk}}{M}})}
|
|
\end{displaymath}
|
|
%% \begin{equations}
|
|
%% \contapp{\inv{[]}}{M}
|
|
%% &=& M \\
|
|
%% \contapp{\inv{(\slk, \chi) \cons \shk}}{M}
|
|
%% &=& \contapp{\inv{\shk}}{(\contappp{\inv{\chi}}{\contappp{\inv{\slk}}{M}})} \\
|
|
%% \end{equations}
|
|
|
|
Handler closures
|
|
\begin{displaymath}
|
|
\contapp{\inv{(\env, H)}^\depth}{M}
|
|
= \Handle^\depth\;M\;\With\;\inv{H}\env
|
|
\end{displaymath}
|
|
%% \begin{equations}
|
|
%% \contapp{\inv{(\env, H)}}{M}
|
|
%% &=& \Handle\;M\;\With\;\inv{H}\env \\
|
|
%% \contapp{\inv{(\env, H)^\dagger}}{M}
|
|
%% &=& \ShallowHandle\;M\;\With\;\inv{H}\env \\
|
|
%% \end{equations}
|
|
|
|
Computation terms
|
|
\begin{equations}
|
|
\inv{V\,W}\env &=& \inv{V}\env\,\inv{W}{\env} \\
|
|
\inv{V\,T}\env &=& \inv{V}\env\,T \\
|
|
\inv{\Let\;\Record{\ell = x; y} = V \;\In\;N}\env
|
|
&=& \Let\;\Record{\ell = x; y} =\inv{V}\env \;\In\; \inv{N}(\env \res \{x, y\}) \\
|
|
\inv{\Case\;V\,\{\ell\;x \mapsto M; y \mapsto N\}}\env
|
|
&=& \Case\;\inv{V}\env \,\{\ell\;x \mapsto \inv{M}(\env \res \{x\}); y \mapsto \inv{N}(\env \res \{y\})\} \\
|
|
\inv{\Return\;V}\env &=& \Return\;\inv{V}\env \\
|
|
\inv{\Let\;x \revto M \;\In\;N}\env
|
|
&=& \Let\;x \revto\inv{M}\env \;\In\; \inv{N}(\env \res \{x\}) \\
|
|
\inv{\Do\;\ell\;V}\env
|
|
&=& \Do\;\ell\;\inv{V}\env \\
|
|
\inv{\Handle^\depth\;M\;\With\;H}\env
|
|
&=& \Handle^\depth\;\inv{M}\env\;\With\;\inv{H}\env \\
|
|
\end{equations}
|
|
|
|
Handler definitions
|
|
\begin{equations}
|
|
\inv{\{\Return\;x \mapsto M\}}\env
|
|
&=& \{\Return\;x \mapsto \inv{M}(\env \res \{x\})\} \\
|
|
\inv{\{\ell\;x\;k \mapsto M\} \uplus H}\env
|
|
&=& \{\ell\;x\;k \mapsto \inv{M}(\env \res \{x, k\}\} \uplus \inv{H}\env \\
|
|
\end{equations}
|
|
|
|
Value terms and values
|
|
\begin{displaymath}
|
|
\ba{@{}c@{}}
|
|
\begin{eqs}
|
|
\inv{x}\env &=& \inv{v}, \quad \text{ if }\env(x) = v \\
|
|
\inv{x}\env &=& x, \quad \text{ if }x \notin dom(\env) \\
|
|
\inv{\lambda x^A.M}\env &=& \lambda x^A.\inv{M}(\env \res \{x\}) \\
|
|
\inv{\Lambda \alpha^K.M}\env &=& \Lambda \alpha^K.\inv{M}\env \\
|
|
\inv{\Record{}}\env &=& \Record{} \\
|
|
\inv{\Record{\ell=V; W}}\env &=& \Record{\ell=\inv{V}\env; \inv{W}\env} \\
|
|
\inv{(\ell\;V)^R}\env &=& (\ell\;\inv{V}\env)^R \\
|
|
\end{eqs}
|
|
\quad
|
|
\begin{eqs}
|
|
\inv{\shk^A} &=& \lambda x^A.\inv{\shk}(\Return\;x) \\
|
|
\inv{(\shk, \slk)^A} &=& \lambda x^A.\inv{\slk}(\inv{\shk}(\Return\;x)) \\
|
|
\inv{(\env, \lambda x^A.M)} &=& \lambda x^A.\inv{M}(\env \res \{x\}) \\
|
|
\inv{(\env, \Lambda \alpha^K.M)} &=& \Lambda \alpha^K.\inv{M}\env \\
|
|
\inv{\Record{}} &=& \Record{} \\
|
|
\inv{\Record{\ell=v; w}} &=& \Record{\ell=\inv{v}; \inv{w}} \\
|
|
\inv{(\ell\;v)^R} &=& (\ell\;\inv{v})^R \\
|
|
\end{eqs} \smallskip\\
|
|
\inv{\Rec\,g^{A \to C}\,x.M}\env = \Rec\,g^{A \to C}\,x.\inv{M}(\env \res \{g, x\})
|
|
= \inv{(\env, \Rec\,g^{A \to C}\,x.M)} \\
|
|
\ea
|
|
\end{displaymath}
|
|
|
|
\caption{Mapping from abstract machine configurations to terms.}
|
|
\label{fig:config-to-term}
|
|
\end{figure}
|
|
|
|
|
|
\paragraph{Remark} If the main continuation is empty then the machine gets
|
|
stuck. This occurs when an operation is unhandled, and the forwarding
|
|
continuation describes the succession of handlers that have failed to
|
|
handle the operation along with any pure continuations that were
|
|
encountered along the way.
|
|
%
|
|
Assuming the input is a well-typed closed computation term $\typc{}{M
|
|
: A}{E}$, the machine will either not terminate, return a value of
|
|
type $A$, or get stuck failing to handle an operation appearing in
|
|
$E$. We now make the correspondence between the operational semantics
|
|
and the abstract machine more precise.
|
|
|
|
\section{Correctness}
|
|
\label{subsec:machine-correctness}
|
|
|
|
Fig.~\ref{fig:config-to-term} defines an inverse mapping $\inv{-}$
|
|
from configurations to computation terms via a collection of mutually
|
|
recursive functions defined on configurations, continuations,
|
|
computation terms, handler definitions, value terms, and values.
|
|
%
|
|
We write $dom(\gamma)$ for the domain of $\gamma$ and $\gamma \res
|
|
\{x_1, \dots, x_n\}$ for the restriction of environment $\gamma$ to
|
|
$dom(\gamma) \res \{x_1, \dots, x_n\}$.
|
|
%
|
|
The $\inv{-}$ function enables us to classify the abstract machine
|
|
reduction rules by how they relate to the operational
|
|
semantics.
|
|
%
|
|
The rules (\mlab{Init}) and (\mlab{RetTop}) concern only initial
|
|
input and final output, neither a feature of the operational
|
|
semantics.
|
|
%
|
|
The rules (\mlab{AppCont^\depth}), (\mlab{Let}), (\mlab{Handle}),
|
|
and (\mlab{Forward}) are administrative in that $\inv{-}$ is invariant
|
|
under them.
|
|
%
|
|
This leaves $\beta$-rules (\mlab{AppClosure}), (\mlab{AppRec}),
|
|
(\mlab{AppType}), (\mlab{Split}), (\mlab{Case}), (\mlab{RetCont}),
|
|
(\mlab{RetHandler}), (\mlab{Do}), and (\mlab{Do^\dagger}),
|
|
each of which corresponds directly to performing a reduction in the
|
|
operational semantics.
|
|
%
|
|
We write $\stepsto_a$ for administrative steps, $\stepsto_\beta$ for
|
|
$\beta$-steps, and $\Stepsto$ for a sequence of steps of the form
|
|
$\stepsto_a^* \stepsto_\beta$.
|
|
|
|
Each reduction in the operational semantics is simulated by a sequence
|
|
of administrative steps followed by a single $\beta$-step in the
|
|
abstract machine. The $Id$ handler (\S\ref{subsec:terms})
|
|
implements the top-level identity continuation.
|
|
\\
|
|
\begin{theorem}[Simulation]
|
|
\label{lem:simulation}
|
|
If $M \reducesto N$, then for any $\conf$ such that $\inv{\conf} =
|
|
Id(M)$ there exists $\conf'$ such that $\conf \Stepsto \conf'$ and
|
|
$\inv{\conf'} = Id(N)$.
|
|
%% If $M \reducesto N$, then for any $\conf$ such that $\inv{\conf} = M$
|
|
%% there exists $\conf'$ such that $\conf \Stepsto \conf'$ and
|
|
%% $\inv{\conf'} = N$.
|
|
\end{theorem}
|
|
|
|
\begin{proof}
|
|
By induction on the derivation of $M \reducesto N$.
|
|
\end{proof}
|
|
|
|
\begin{corollary}
|
|
If $\typc{}{M : A}{E}$ and $M \reducesto^+ N \not\reducesto$, then $M
|
|
\stepsto^+ \conf$ with $\inv{\conf} = N$.
|
|
\end{corollary}
|
|
|
|
|
|
\part{Expressiveness}
|
|
\chapter{Interdefinability of deep and shallow handlers}
|
|
\label{ch:deep-vs-shallow}
|
|
|
|
In this section we show that shallow handlers and general recursion
|
|
can simulate deep handlers up to congruence, and that deep handlers
|
|
can simulate shallow handlers up to administrative reductions. The
|
|
latter construction generalises the example of pipes implemented using
|
|
deep handlers that we gave in
|
|
Section~\ref{sec:pipes}.
|
|
%
|
|
|
|
\section{Deep as shallow}
|
|
\label{sec:deep-as-shallow}
|
|
|
|
\newcommand{\dstrans}[1]{\mathcal{S}\llbracket #1 \rrbracket}
|
|
|
|
The implementation of deep handlers using shallow handlers (and
|
|
recursive functions) is by a direct local translation, similar to how
|
|
one would implement a fold (catamorphism) in terms of general
|
|
recursion. Each handler is wrapped in a recursive function and each
|
|
resumption has its body wrapped in a call to this recursive function.
|
|
%
|
|
Formally, the translation $\dstrans{-}$ is defined as the homomorphic
|
|
extension of the following equations to all terms.
|
|
\begin{equations}
|
|
\dstrans{\Handle \; M \; \With \; H} &=&
|
|
(\Rec~h~f.\ShallowHandle\; f\,\Unit \; \With \; \dstrans{H} h)\,(\lambda \Unit{}.\dstrans{M}) \\
|
|
\dstrans{H}h &=& \dstrans{\hret}h \uplus \dstrans{\hops}h \\
|
|
\dstrans{\{ \Return \; x \mapsto N\}} h &=&
|
|
\{ \Return \; x \mapsto \dstrans{N} \}\\
|
|
\dstrans{\{ \ell \; p \; r \mapsto N_\ell \}_{\ell \in \mathcal{L}}} h &=&
|
|
\{ \ell \; p \; r \mapsto
|
|
\Let \; r \revto \Return \; \lambda x.h\,(\lambda \Unit{}.r\,x) \; \In \;
|
|
\dstrans{N_\ell} \}_{\ell \in \mathcal{L}}
|
|
\end{equations}
|
|
|
|
% \paragraph{Example} We illustrate the translation $\dstrans{-}$ on the
|
|
% EXAMPLE handler from Section~\ref{sec:strategies} (recall that the
|
|
% variable $m$ is bound to the input computation). The example here is
|
|
% reproduced in ANF notation.
|
|
% \[
|
|
% \ba{@{~}l@{~}l@{}l}
|
|
% &\mathcal{S}&\left\llbracket
|
|
% \ba[m]{@{~}l}
|
|
% \Handle\; m~\Unit\; \With\\
|
|
% \quad
|
|
% \ba{@{}l@{~}c@{~}l}
|
|
% \Return~x &\mapsto& \Return\;x\\
|
|
% \Move~\Record{\_;n}~resume &\mapsto& \Let\;y \revto ps~n\;\In\; resume~y
|
|
% \ea
|
|
% \ea\right\rrbracket =\\\\
|
|
% &
|
|
% &\ba[m]{@{}l}
|
|
% \hspace{-1ex}
|
|
% \left(
|
|
% \ba[m]{@{~}l}
|
|
% \Rec~h~f.
|
|
% \ba[t]{@{~}l}
|
|
% \ShallowHandle\; f~\Unit\; \With\\
|
|
% \quad
|
|
% \ba{@{}l@{~}c@{~}l}
|
|
% \Return~x &\mapsto& \Return\; x\\
|
|
% \Move~\Record{\_;n}~resume &\mapsto&\\
|
|
% \quad\ba[t]{@{~}l@{}}
|
|
% \Let\; r \revto \Return\; \lambda x. h (\lambda\Unit.resume~x)\;\In\\
|
|
% \Let\; y \revto ps~n\; \In\; r~y
|
|
% \ea
|
|
% \ea
|
|
% \ea
|
|
% \ea\right)~(\lambda \Unit. m~\Unit)
|
|
% \ea
|
|
% \ea
|
|
% \]\\
|
|
|
|
\begin{theorem}
|
|
If $\Delta; \Gamma \vdash M : C$ then $\Delta; \Gamma \vdash
|
|
\dstrans{M} : C$.
|
|
\end{theorem}
|
|
|
|
In order to obtain a simulation result, we allow reduction in the
|
|
simulated term to be performed under lambda abstractions (and indeed
|
|
anywhere in a term), which is necessary because of the redefinition of
|
|
the resumption to wrap the handler around its body.
|
|
%
|
|
Nevertheless, the simulation proof makes minimal use of this power,
|
|
merely using it to rename a single variable.
|
|
%
|
|
We write $R_{\mathrm{cong}}$ for the compatible closure of relation
|
|
$R$, that is the smallest relation including $R$ and closed under term
|
|
constructors for $\SCalc$.
|
|
%% , otherwise known as \emph{reduction up to
|
|
%% congruence}.
|
|
|
|
\begin{theorem}[Simulation up to congruence]
|
|
If $M \reducesto N$ then $\dstrans{M} \reducesto_{\mathrm{cong}}^+
|
|
\dstrans{N}$.
|
|
\end{theorem}
|
|
|
|
\begin{proof}
|
|
By induction on $\reducesto$ using a substitution lemma. The
|
|
interesting case is $\semlab{Op}$, which is where we apply a single
|
|
$\beta$-reduction, renaming a variable, under the lambda abstraction
|
|
representing the resumption.
|
|
\end{proof}
|
|
|
|
\section{Shallow as deep}
|
|
|
|
\newcommand{\sdtrans}[1]{\mathcal{D}\llbracket #1 \rrbracket}
|
|
|
|
Implementing shallow handlers in terms of deep handlers is slightly
|
|
more involved than the other way round.
|
|
%
|
|
It amounts to the encoding of a case split by a fold and involves a
|
|
translation on handler types as well as handler terms.
|
|
%
|
|
Formally, the translation $\sdtrans{-}$ is defined as the homomorphic
|
|
extension of the following equations to all types, terms, and type
|
|
environments.
|
|
\begin{equations}
|
|
\sdtrans{C \Rightarrow D} &=&
|
|
\sdtrans{C} \Rightarrow \Record{\UnitType \to \sdtrans{C}; \UnitType \to \sdtrans{D}} \medskip \\
|
|
\sdtrans{\ShallowHandle \; M \; \With \; H} &=&
|
|
\ba[t]{@{}l}
|
|
\Let\;z \revto \Handle \; \sdtrans{M} \; \With \; \sdtrans{H} \; \In\\
|
|
\Let\;\Record{f; g} = z \;\In\;
|
|
g\,\Unit
|
|
\ea \\
|
|
\sdtrans{H} &=& \sdtrans{\hret} \uplus \sdtrans{\hops} \\
|
|
\sdtrans{\{\Return \; x \mapsto N\}} &=&
|
|
\{\Return \; x \mapsto \Return\; \Record{\lambda \Unit.\Return\; x; \lambda \Unit.\sdtrans{N}}\} \\
|
|
\sdtrans{\{\ell\; p\; r \mapsto N\}_{\ell \in \mathcal{L}}} &=& \{
|
|
\bl
|
|
\ell\; p\; r \mapsto \\
|
|
\quad \Let \;r \revto
|
|
\lambda x. \Let\; z \revto r\,x\; \In\;
|
|
\Let\; \Record{f; g} = z\; \In\; f\,\Unit
|
|
\; \In\\
|
|
\quad \Return\;\Record{\lambda \Unit.\Let\; x \revto \Do\;\ell\,p\; \In\; r\,x; \lambda \Unit.\sdtrans{N}}\}_{\ell \in \mathcal{L}}
|
|
\el
|
|
\end{equations}
|
|
%
|
|
Each shallow handler is encoded as a deep handler that returns a pair
|
|
of thunks. The first forwards all operations, acting as the identity
|
|
on computations. The second interprets a single operation before
|
|
reverting to forwarding.
|
|
|
|
% \paragraph{Example} We demonstrate the translation $\sdtrans{-}$ on
|
|
% the $\Pipe$ handler from Section~\ref{sec:shallow-handlers-tutorial}
|
|
% (recall that the variables $c$ and $p$ are bound to the consumer and
|
|
% producer functions respectively). The example is reproduced in ANF
|
|
% notation.
|
|
% %
|
|
% \[
|
|
% \ba{@{~}l@{~}l@{}l}
|
|
% &\mathcal{D}&\left\llbracket
|
|
% \ba[m]{@{~}l}
|
|
% \ShallowHandle\; c\,\Unit \;\With\; \\
|
|
% \quad
|
|
% \ba[m]{@{}l@{~}c@{~}l@{}}
|
|
% \Return~x &\mapsto& \Return\; x \\
|
|
% \Await~\Unit~resume &\mapsto& \Copipe\; \Record{resume; p} \\
|
|
% \ea \\
|
|
% \ea\right\rrbracket = \\
|
|
% &
|
|
% &\ba[t]{@{~}l}
|
|
% \Let\; z \revto
|
|
% \ba[t]{@{~}l}
|
|
% \Handle\; c~\Unit \; \With\\
|
|
% \quad \ba[m]{@{~}l}
|
|
% \ba[m]{@{~}l@{~}l}
|
|
% \Return~x &\mapsto \Return\; \Record{\lambda\Unit. \Return\; x; \lambda\Unit. \Return\;x}\\
|
|
% \Await~\Unit~resume &\mapsto
|
|
% \ea\\
|
|
% \qquad\ba[t]{@{~}l}
|
|
% \Let\;r \revto \lambda x.\Let\; z \revto resume~x\;
|
|
% \In\; \Let\; \Record{f; g} = z \;\In\; f~\Unit\; \In\\
|
|
% \Return\;\Record{\lambda \Unit. \Let\; x \revto \Do\; \ell~p \;\In\; r~x;
|
|
% \lambda\Unit.\sdtrans{\Copipe}\Record{r; p}}
|
|
% \ea
|
|
% \ea
|
|
% \ea\\
|
|
% \In\;\Let\;\Record{f; g} = z\; \In\; g~\Unit
|
|
% \ea
|
|
% \ea
|
|
% \]
|
|
%
|
|
|
|
\begin{theorem}
|
|
If $\Delta; \Gamma \vdash M : C$ then $\sdtrans{\Delta};
|
|
\sdtrans{\Gamma} \vdash \sdtrans{M} : \sdtrans{C}$.
|
|
\end{theorem}
|
|
|
|
|
|
\newcommand{\admin}{admin}
|
|
\newcommand{\approxa}{\gtrsim}
|
|
|
|
As with the implementation of deep handlers as shallow handlers, the
|
|
implementation is again given by a local translation. However, this
|
|
time the administrative overhead is more significant. Reduction up to
|
|
congruence is insufficient and we require a more semantic notion of
|
|
administrative reduction.
|
|
|
|
\begin{definition}[Administrative evaluation contexts]
|
|
An evaluation context $\EC$ is administrative, $\admin(\EC)$, iff
|
|
\begin{enumerate}
|
|
\item For all values $V$, we have: $\EC[\Return\;V] \reducesto^\ast
|
|
\Return\;V$
|
|
\item For all evaluation contexts $\EC'$, operations $\ell \in BL(\EC)
|
|
\backslash BL(\EC')$, values $V$:
|
|
%
|
|
\[
|
|
\EC[\EC'[\Do\;\ell\;V]] \reducesto^\ast \Let\; x \revto \Do\;\ell\;V \;\In\; \EC[\EC'[\Return\;x]].
|
|
\]
|
|
\end{enumerate}
|
|
\end{definition}
|
|
%
|
|
The intuition is that an administrative evaluation context behaves
|
|
like the empty evaluation context up to some amount of administrative
|
|
reduction, which can only proceed once the term in the context becomes
|
|
sufficiently evaluated.
|
|
%
|
|
Values annihilate the evaluation context and handled operations are
|
|
forwarded.
|
|
%
|
|
%% The forwarding handler is a technical device which allows us to state
|
|
%% the second property in a uniform way by ensuring that the operation is
|
|
%% handled at least once.
|
|
|
|
\begin{definition}[Approximation up to administrative reduction]
|
|
Define $\approxa$ as the compatible closure of the following inference
|
|
rules.
|
|
%
|
|
\begin{mathpar}
|
|
\inferrule*
|
|
{ }
|
|
{M \approxa M}
|
|
|
|
\inferrule*
|
|
{M \reducesto M' \\ M' \approxa N}
|
|
{M \approxa N}
|
|
|
|
\inferrule*
|
|
{\admin(\EC) \\ M \approxa N}
|
|
{\EC[M] \approxa N}
|
|
\end{mathpar}
|
|
%
|
|
We say that $M$ approximates $N$ up to administrative reduction if $M
|
|
\approxa N$.
|
|
\end{definition}
|
|
%
|
|
Approximation up to administrative reduction captures the property
|
|
that administrative reduction may occur anywhere within a term.
|
|
%
|
|
The following lemma states that the forwarding component of the
|
|
translation is administrative.
|
|
\begin{lemma}\label{lem:sdtrans-admin}
|
|
For all shallow handlers $H$, the following context is administrative:
|
|
\begin{displaymath}
|
|
\Let\; z \revto
|
|
\Handle\; [~] \;\With\; \sdtrans{H}\;
|
|
\In\;
|
|
\Let\; \Record{f;\_} = z\; \In\; f\,\Unit.
|
|
\end{displaymath}
|
|
\end{lemma}
|
|
|
|
\begin{theorem}[Simulation up to administrative reduction]
|
|
If $M' \approxa \sdtrans{M}$ and $M \reducesto N$ then there exists
|
|
$N'$ such that $N' \approxa \sdtrans{N}$ and $M' \reducesto^+ N'$.
|
|
\end{theorem}
|
|
%
|
|
\begin{proof}
|
|
By induction on $\reducesto$ using a substitution lemma and
|
|
Lemma~\ref{lem:sdtrans-admin}. The interesting case is
|
|
$\semlab{Op^\dagger}$, which uses Lemma~\ref{lem:sdtrans-admin} to
|
|
approximate the body of the resumption up to administrative reduction.
|
|
\end{proof}
|
|
|
|
% \chapter{Computability, complexity, and expressivness}
|
|
% \label{ch:expressiveness}
|
|
% \section{Notions of expressiveness}
|
|
% Felleisen's macro-expressiveness, Longley's type-respecting
|
|
% expressiveness, Kammar's typability-preserving expressiveness.
|
|
|
|
% \section{Interdefinability of deep and shallow Handlers}
|
|
% \section{Encoding parameterised handlers}
|
|
|
|
\chapter{Asymptotic speedup with first-class control}
|
|
\label{ch:handlers-efficiency}
|
|
Describe the methodology\dots
|
|
\section{Generic search}
|
|
\section{Calculi}
|
|
\subsection{Base calculus}
|
|
\subsection{Handler calculus}
|
|
\section{A practical model of computation}
|
|
\subsection{Syntax}
|
|
\subsection{Semantics}
|
|
\subsection{Realisability}
|
|
\section{Points, predicates, and their models}
|
|
\section{Efficient generic search with effect handlers}
|
|
\subsection{Space complexity}
|
|
\section{Best-case complexity of generic search without control}
|
|
\subsection{No shortcuts}
|
|
\subsection{No sharing}
|
|
|
|
% \chapter{Speeding up programs in ML-like programming languages}
|
|
% \section{Mutable state}
|
|
% \section{Exception handling}
|
|
% \section{Effect system}
|
|
|
|
\part{Conclusions}
|
|
|
|
\chapter{Conclusions}
|
|
\label{ch:conclusions}
|
|
Some profound conclusions\dots
|
|
|
|
\chapter{Future Work}
|
|
\label{ch:future-work}
|
|
|
|
%%
|
|
%% Appendices
|
|
%%
|
|
% \appendix
|
|
|
|
%% If you want the bibliography single-spaced (which is allowed), uncomment
|
|
%% the next line.
|
|
%\nocite{*}
|
|
\singlespace
|
|
%\nocite{*}
|
|
%\printbibliography[heading=bibintoc]
|
|
\bibliographystyle{plainnat}
|
|
\bibliography{\jobname}
|
|
|
|
%% ... that's all, folks!
|
|
\end{document}
|
|
|