Initial commit

6 years ago · 1b87d2cde7
--- a/.gitignore
+++ b/.gitignore
@ -0,0 +1,13 @@
 /.site
 /.store
 /.stack-work
 /.vscode

 /node_modules

 /uni
 /portfolio.md
 /fonts
 /css/fonts

 /.mailmap
--- a/blag.cabal
+++ b/blag.cabal
@ -0,0 +1,25 @@
 name: blag
 version: 0.1.0.0
 build-type: Simple
 cabal-version: >= 1.10

 executable site
 main-is: site.hs
 build-depends: base
 , hakyll
 , pandoc
 , skylighting
 , process
 , containers
 , directory
 , pandoc-types
 , bytestring
 , uri-encode
 , deepseq
 , text
 , hsass
 , hakyll-sass
 ghc-options: -threaded
 default-language: Haskell2010

 ghc-options: -optl-fuse-ld=lld
--- a/css/code.css
+++ b/css/code.css
@ -0,0 +1,45 @@
 code, div.sourceCode {
 font-family: Fantasque Sans Mono, Fira Mono, monospace;
 font-size: 15pt;
 }

 code.inline {
 background-color: rgb(250,250,250);
 /* border: 1px solid rgb(200,200,200); */
 }

 table.sourceCode, tr.sourceCode, td.lineNumbers, td.sourceCode {
 margin: 0; padding: 0; vertical-align: baseline; border: none;
 }

 table.sourceCode {
 width: 100%; line-height: 100%;
 }

 td.lineNumbers { text-align: right; padding-right: 4px; padding-left: 4px; color: #aaaaaa; border-right: 1px solid #aaaaaa; }
 td.sourceCode { padding-left: 5px; }
 code.kw, span.kw { color: #af005f; } /* Keyword */
 code.dt, span.dt { color: #5f5faf; } /* DataType */
 code.dv, span.dv { color: #268bd2; } /* DecVal */
 code.bn, span.bn { color: #268bd2; } /* BaseN */
 code.fl, span.fl { color: #268bd2; } /* Float */
 code.ch, span.ch { color: #cb4b16; } /* Char */
 code.st, span.st { color: #cb4b16; } /* String */
 code.co, span.co { color: #8a8a8a; } /* Comment */
 code.ot, span.ot { color: #007020; } /* Other */
 code.al, span.al { color: #ff0000; } /* Alert */
 code.fu, span.fu { color: #666666; } /* Function */
 code.er, span.er { color: #ff0000; } /* Error */
 code.wa, span.wa { color: #60a0b0; } /* Warning */
 code.cn, span.cn { color: #880000; } /* Constant */
 code.sc, span.sc { color: #4070a0; } /* SpecialChar */
 code.vs, span.vs { color: #4070a0; } /* VerbatimString */
 code.ss, span.ss { color: #2aa198; } /* SpecialString */
 code.va, span.va { color: #073642; } /* Variable */
 code.cf, span.cf { color: #007020; } /* ControlFlow */
 code.op, span.op { color: #d33682; } /* Operator */
 code.pp, span.pp { color: #bc7a00; } /* Preprocessor */
 code.at, span.at { color: #7d9029; } /* Attribute */
 code.do, span.do { color: #ba2121; } /* Documentation */
 code.an, span.an { color: #60a0b0; } /* Annotation */
 code.cv, span.cv { color: #60a0b0; } /* CommentVar */
--- a/css/computermodern.css
+++ b/css/computermodern.css
@ -0,0 +1,13 @@
@font-face {
 font-family: "Computer Modern";
 src: url('/static/cmunorm.woff');
 }

 .math {
 font-family: Computer Modern, serif;
 }

 .math .display {
 font-size: 18px;
 text-align: center;
 }
--- a/css/default.scss
+++ b/css/default.scss
@ -0,0 +1,469 @@
 $purple: #424969;
 $orange: #ffac5f;
 $blonde: #f5ddbc;
 $light-purple: #faf0fa;
 $yugo: #ea8472;

 $header: $orange;
 $header-height: 50px;

 $max-width: 95ch;

 .mathpar, .math-paragraph {
 display: flex;
 flex-direction: row;
 flex-wrap: wrap;
 justify-content: space-around;
 align-items: center;
 }

 a#mastodon {
 display: none;
 }

 html, body {
 min-height: 100%;
 height: 100%;
 margin: 0;

 background-color: white;

 font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif;
 }

 body {
 display: flex;
 flex-direction: column;

 counter-reset: theorem figure;
 }

 div#header {
 background-color: $header;
 height: $header-height;

 display: flex;
 flex-direction: row;
 align-items: stretch;
 justify-content: space-between;

 flex-wrap: nowrap;
 overflow-x: auto;

 div#logo {
 margin-left: .5em;
 line-height: $header-height;

 padding-left: .5em;
 padding-right: .5em;
 font-size: 18pt;

 a {
 color: $purple;
 text-decoration: none;
 }

 transition: background-color .2s ease-in-out;
 }

 div#logo:hover {
 background-color: darken($header, 10%);
 }

 div#navigation {
 margin-right: .5em;

 display: flex;
 flex-direction: row;
 align-items: stretch;
 align-self: flex-end;
 justify-content: flex-end;

 line-height: $header-height;

 a {
 color: $purple;
 text-decoration: none;

 margin-left: .5em;
 margin-right: .5em;
 }

 div.nav-button {
 height: 100%;
 transition: background-color .2s ease-in-out;
 }

 div.nav-button:hover {
 background-color: darken($header, 10%);
 }
 }

 }

 div#content {
 max-width: $max-width;
 margin: 0px auto 0px auto;
 flex: 1 0 auto;

 span.katex, span.together {
 display: inline-block;
 }

 p {
 text-align: justify;
 letter-spacing: 1.75;

 code {
 display: inline-block;
 }

 span.qed {
 float: right;
 }

 span.theorem ::after {
 counter-increment: theorem;
 content: " " counter(theorem);
 }

 span.theorem, span.paragraph-marker {
 font-style: italic;
 }
 }

 p.image {
 text-align: center !important;
 }

 h1 {
 font-variant: small-caps;
 max-width: 120ch;
 }

 blockquote {
 background-color: $light-purple;

 border-radius: 10px;
 border: 1px solid $purple;

 padding: 0em 1em;
 }

 > article > blockquote {
 width: 80%;
 margin: auto;
 }

 > article > div.code-container {
 width: 80%;
 margin: auto;

 pre {
 padding: 0px 1em;
 }

 > span {
 display: inline;
 }
 }

 div.code-container {
 background-color: $light-purple;

 border-radius: 10px;
 border: 1px solid darken($light-purple, 10%);

 overflow-x: auto;

 > span {
 padding: 0.5em 1em 0.25em 1em;
 background-color: darken($light-purple, 10%);

 border-top-left-radius: 10px;

 box-shadow: 1px 1px darken($light-purple, 20%);
 display: none;
 }

 > span::after {
 content: " code";
 }

 div.sourceCode {
 padding: 0px .5em;
 }
 }

 div.code-container.custom-tag {
 > span::after {
 display: none;
 }
 }

 div.code-container.continues {
 > span {
 display: none;
 }
 }

 * {
 max-width: 100%;
 }

 details {
 summary {
 margin-left: 1em;
 font-size: 14pt;
 padding: .2em 1em;
 }

 border-radius: 5px;
 border: 1px solid $purple;

 padding: .2em 1em;

 background-color: white;
 font-size: 0pt;

 margin-top: 0.5em;
 margin-bottom: 0.5em;

 transition: font-size 0.3s ease-in-out, background-color 0.3s ease-in-out;
 transform: rotate3d(0, 0, 0, 0);
 }

 details[open] {
 background-color: $light-purple;
 font-size: 14pt;
 }

 .special-thanks {
 display: flex;
 flex-direction: column;
 align-items: center;
 justify-content: space-around;

 p {
 font-size: 21pt;
 margin-top: .5em;
 margin-bottom: 0px;
 }

 ul {
 list-style: none;
 li {
 margin: .5em 0px;
 border-radius: 10px;
 border: 1px solid $purple;
 background-color: $light-purple;
 
 padding: 1em;

 a {
 text-decoration: underline;
 }

 transition: all 0.2s ease-in-out;
 }

 li:hover {
 border-radius: 5px;
 transform: scale(1.01);
 background-color: lighten($light-purple, 5%);
 }
 }
 }

 .eqn-list {
 list-style: none;
 direction: rtl;
 counter-reset: equation;

 li {
 counter-increment: equation;

 span.katex-display {
 margin: 2px; 
 }

 * {
 direction: ltr;
 }
 }

 li::marker {
 content: "(" counter(equation) ")";
 font-family: KaTeX_Main, Times New Roman, serif;
 }
 }

 font-size: 14pt;
 line-height: 1.6;
 }

 div.info, span#reading-length {
 padding-left: 1em;
 font-style: italic;
 }

 span#reading-length::before {
 content: "Word count: "
 }

 div#footer {
 display: flex;
 align-items: center;
 justify-content: space-between;

 padding-left: 1em;
 padding-right: 1em;

 background-color: $light-purple;
 }

 .definition {
 text-decoration: dotted underline;
 }

 .post-list {
 list-style: none;
 padding: 0px;

 div.post-list-item {
 margin-top: .2em;
 margin-bottom: .2em;

 padding: 1em;

 border-radius: 10px;
 background-color: $light-purple;

 display: flex;
 justify-content: space-between;
 flex-wrap: wrap;
 align-items: flex-end;

 font-size: 11pt;

 a {
 font-size: 14pt;
 padding-right: 2em;
 }
 }
 }

 table {
 margin: auto;
 border-collapse: collapse;

 td, th {
 border: 1px solid $purple;
 text-align: center;
 padding: 0px 1em 0px 1em;

 > * {
 vertical-align: middle;
 }
 }

 td.image {
 padding: 0px;
 img {
 margin-top: auto;
 }
 }
 }

 figure {
 width: 100%;
 margin: auto;

 display: flex;
 flex-direction: column;
 align-items: center;
 justify-content: space-around;

 div {
 width: 100%;
 overflow-x: auto;
 }

 figcaption {
 font-size: 14pt;
 }

 figcaption::before {
 counter-increment: figure;
 content: "Figure " counter(figure) ". ";
 }
 }


@media only screen and (max-width: $max-width) {
 div#content {
 margin-left: 1em;
 margin-right: 1em;
 }

 .mathpar {
 overflow-x: auto;
 justify-content: space-evenly;

 > * {
 margin-left: .2em;
 margin-right: .2em;
 flex-shrink: 0;
 flex-grow: 0;
 }
 }
 }

 // Contact page

 .contact-list {
 display: flex;
 flex-direction: row;
 flex-wrap: wrap;
 justify-content: space-around;
 align-items: center;

 .contact-card {
 margin: 0px .5em;

 border: 1px solid $purple;
 border-radius: 10px;
 background-color: $blonde;

 padding: 0px 1em;

 .username, .username * {
 font-size: 21pt;
 color: $purple;
 }

 p {
 display: flex;
 align-items: center;
 justify-content: space-evenly;

 max-width: 40ch !important;
 }

 transition: all 0.2s ease-in-out;
 }

 .contact-card:hover {
 margin: 0px .55em;
 background-color: darken($blonde, 10%);
 border-radius: 5px;
 transform: scale(1.01);
 }
 }

@font-face {
 font-family: 'Fantasque Sans Mono';
 src: url('fonts/FantasqueSansMono-Regular.woff2') format('woff2');
 font-weight: 400;
 font-style: normal;
 }
--- a/css/katex.min.css
+++ b/css/katex.min.css
--- a/diagrams/cc/delimcc.tex
+++ b/diagrams/cc/delimcc.tex
@ -0,0 +1,15 @@
 \begin{scope}[node distance=0.75cm]

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {shift};
 \node (Stk1) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -0.75) {foo};
 \node (Stk2) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -1.5) {bar};
 \node (Stk3) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -2.25) {reset};
 \node (Stk3) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -3) {baz};
 \draw [red, very thick, dashed] (-3.6, -2.625) -- (-1.89, -2.625) -- (-1.89, 0.375) -- (-3.6, 0.375) -- cycle;
 \draw [arrows={Latex}-] (-4, 0.375) -- (-4, -3.375);
 \end{scope}
--- a/diagrams/eq/0cube.tex
+++ b/diagrams/eq/0cube.tex
@ -0,0 +1 @@
 \node[draw,circle,label=right:$A$,fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i0) at (0, 0) {};
--- a/diagrams/eq/1cube.tex
+++ b/diagrams/eq/1cube.tex
@ -0,0 +1,4 @@
 \node[draw,circle,label=left:{$A[0/i]$},fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i0) at (-1, 0) {};
 \node[draw,circle,label=right:{$A[1/i]$},fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i1) at (1, 0) {};

 \draw (i0) -- (i1);
--- a/diagrams/eq/2cube.tex
+++ b/diagrams/eq/2cube.tex
@ -0,0 +1,6 @@
 \node[draw,circle,label=left:{$A[0/i, 0/j]$},fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i0j0) at (-1, -1) {};
 \node[draw,circle,label=right:{$A[1/i, 0/j]$},fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i1j0) at (1, -1) {};
 \node[draw,circle,label=left:{$A[0/i, 1/j]$},fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i0j1) at (-1, 1) {};
 \node[draw,circle,label=right:{$A[1/i, 1/j]$},fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i1j1) at (1, 1) {};

 \draw (i0j0) -- (i1j0) -- (i1j1) -- (i0j1) -- (i0j0);
--- a/diagrams/eq/interval.tex
+++ b/diagrams/eq/interval.tex
@ -0,0 +1,5 @@
 \node[draw,circle,label=below:$i_0$,fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i0) at (-1, 0) {};
 \node[draw,circle,label=below:$i_1$,fill,outer sep=0.1cm, inner sep=0pt, minimum size=0.1cm] (i1) at (1, 0) {};

 \draw (i0) -- (i1) node [midway, above] (seg) {seg};
 % \draw[-] (i0) -- (i1);
--- a/diagrams/gm/app_gx.tex
+++ b/diagrams/gm/app_gx.tex
@ -0,0 +1,39 @@
 \begin{scope}[node distance=0.75cm]

 \node (FGX) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};
 \node (FG) [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, left of=FGX] {@};
 \node (X) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, right of=FGX] {x};
 \node (F) [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=FG, left of=FG, xshift=2] {f};
 \node (G) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FG, right of=FG, xshift=-2] {g};

 \node (GX)
 [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=F, xshift=0.75cm]
 {@};

 \draw[->] (FGX) to (X);
 \draw[->] (FGX) to (FG);
 \draw[->] (FG) to (F.north east);
 \draw[->] (FG) to (G.north west);

 \draw[->] (GX) to ([shift=({-0.35cm,-0.35cm})]GX)
 -- ++(0, -0.10cm)
 -| (G);

 \draw[->] (GX) to ([shift=({0.45cm,-0.35cm})]GX)
 -| (X);

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {};
 \node (Stk1) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -0.75) {};
 \node (Stk2) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -1.5) {};
 \node (Stk3) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -2.25) {};

 \draw[->] (Stk0.center) to (FGX);
 \draw[->] (Stk1.center) to (FG);
 \draw[->] (Stk2.center) to (F);
 \draw[->] (Stk3.center) to (GX);

 \end{scope}
--- a/diagrams/gm/app_kgx.tex
+++ b/diagrams/gm/app_kgx.tex
@ -0,0 +1,51 @@
 \begin{scope}[node distance=0.75cm]

 \node (FGX) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};
 \node (FG) [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, left of=FGX] {@};
 \node (X) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, right of=FGX] {x};
 \node (F) [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=FG, left of=FG, xshift=2] {f};
 \node (G) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FG, right of=FG, xshift=-2] {g};

 \node (KGX)
 [xshift=-0.55cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=F, xshift=0.75cm]
 {@};

 \node (K)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=KGX, left of=KGX]
 {K};

 \node (GX)
 [xshift=-0.45cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=KGX, right of=KGX]
 {@};

 \draw[->] (FGX) to (X);
 \draw[->] (FGX) to (FG);
 \draw[->] (FG) to (F.north east);
 \draw[->] (FG) to (G.north west);

 \draw[->] (KGX) to (K);
 \draw[->] (KGX) to (GX);

 \draw[->] (GX) to ([shift=({-0.35cm,-0.35cm})]GX)
 -- ++(0, -0.10cm)
 -| (G);

 \draw[->] (GX) to ([shift=({0.45cm,-0.35cm})]GX)
 -| (X);

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {};
 \node (Stk1) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -0.75) {};
 \node (Stk2) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -1.5) {};
 \node (Stk3) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -2.25) {};


 \draw[->] (Stk0.center) to (FGX);
 \draw[->] (Stk1.center) to (FG);
 \draw[->] (Stk2.center) to (F);
 \draw[->] (Stk3.center) to (KGX);

 \end{scope}
--- a/diagrams/gm/entry.tex
+++ b/diagrams/gm/entry.tex
@ -0,0 +1,25 @@
 \begin{scope}[node distance=0.75cm]

 \node (FGX) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};
 \node (FG) [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, left of=FGX] {@};
 \node (X) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, right of=FGX] {x};
 \node (F) [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=FG, left of=FG, xshift=2] {f};
 \node (G) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FG, right of=FG, xshift=-2] {g};

 \draw[->] (FGX) to (X);
 \draw[->] (FGX) to (FG);
 \draw[->] (FG) to (F.north east);
 \draw[->] (FG) to (G.north west);

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {};
 \node (Stk1) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -0.75) {};
 \node (Stk2) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -1.5) {};

 \draw[->] (Stk0.center) to (FGX);
 \draw[->] (Stk1.center) to (FG);
 \draw[->] (Stk2.center) to (F);

 \end{scope}
--- a/diagrams/gm/push_g.tex
+++ b/diagrams/gm/push_g.tex
@ -0,0 +1,31 @@
 \begin{scope}[node distance=0.75cm]

 \node (FGX) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};
 \node (FG) [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, left of=FGX] {@};
 \node (X) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, right of=FGX] {x};
 \node (F) [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=FG, left of=FG, xshift=2] {f};
 \node (G) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FG, right of=FG, xshift=-2] {g};

 \draw[->] (FGX) to (X);
 \draw[->] (FGX) to (FG);
 \draw[->] (FG) to (F.north east);
 \draw[->] (FG) to (G.north west);

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {};
 \node (Stk1) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -0.75) {};
 \node (Stk2) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -1.5) {};
 \node (Stk3) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -2.25) {};
 \node (Stk4) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -3) {};

 \draw[->] (Stk0.center) to (FGX);
 \draw[->] (Stk1.center) to (FG);
 \draw[->] (Stk2.center) to (F);
 \draw[->] (Stk3.center) to (X |- 0, -2.25cm) -- (X);
 \draw[->] (Stk4.center) to (G |- 0, -3cm) -- (G);

 \end{scope}
--- a/diagrams/gm/push_k.tex
+++ b/diagrams/gm/push_k.tex
@ -0,0 +1,44 @@
 \begin{scope}[node distance=0.75cm]

 \node (FGX) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};
 \node (FG) [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, left of=FGX] {@};
 \node (X) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, right of=FGX] {x};
 \node (F) [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=FG, left of=FG, xshift=2] {f};
 \node (G) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FG, right of=FG, xshift=-2] {g};

 \node (GX)
 [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=F, xshift=0.75cm]
 {@};

 \draw[->] (FGX) to (X);
 \draw[->] (FGX) to (FG);
 \draw[->] (FG) to (F.north east);
 \draw[->] (FG) to (G.north west);

 \draw[->] (GX) to ([shift=({-0.35cm,-0.35cm})]GX)
 -- ++(0, -0.10cm)
 -| (G);

 \draw[->] (GX) to ([shift=({0.45cm,-0.35cm})]GX)
 -| (X);

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {};
 \node (Stk1) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -0.75) {};
 \node (Stk2) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -1.5) {};
 \node (Stk3) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -2.25) {};
 \node (Stk4) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -3) {};

 \node (K) [right of=Stk4, xshift=1.5cm] {K};

 \draw[->] (Stk0.center) to (FGX);
 \draw[->] (Stk1.center) to (FG);
 \draw[->] (Stk2.center) to (F);
 \draw[->] (Stk3.center) to (GX);
 \draw[->] (Stk4.center) to (K);

 \end{scope}
--- a/diagrams/gm/push_x.tex
+++ b/diagrams/gm/push_x.tex
@ -0,0 +1,33 @@
 \begin{scope}[node distance=0.75cm]

 \node (FGX) [inner xsep=0.01cm, inner ysep=0.03cm]
 at (0, 0) {@};
 \node (FG) [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, left of=FGX]
 {@};
 \node (X) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, right of=FGX]
 {x};
 \node (F) [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=FG, left of=FG, xshift=2]
 {f};
 \node (G) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FG, right of=FG, xshift=-2]
 {g};

 \draw[->] (FGX) to (X);
 \draw[->] (FGX) to (FG);
 \draw[->] (FG) to (F.north east);
 \draw[->] (FG) to (G.north west);

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {};
 \node (Stk1) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -0.75) {};
 \node (Stk2) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -1.5) {};
 \node (Stk3) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -2.25) {};

 \draw[->] (Stk0.center) to (FGX);
 \draw[->] (Stk1.center) to (FG);
 \draw[->] (Stk2.center) to (F);
 \draw[->] (Stk3.center) to (0.5cm, -2.25cm) -- (X);

 \end{scope}
--- a/diagrams/gm/slide_3.tex
+++ b/diagrams/gm/slide_3.tex
@ -0,0 +1,34 @@
 \begin{scope}[node distance=0.75cm]

 \node (KGX)
 [xshift=-0.55cm, inner xsep=0.01cm, inner ysep=0.03cm]
 at (0, 0) {@};

 \node (K)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=KGX, left of=KGX]
 {K};

 \node (GX)
 [xshift=-0.45cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=KGX, right of=KGX]
 {@};

 \node (G)
 [xshift=0.45cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=GX, left of=GX]
 {g};

 \node (X)
 [xshift=-0.45cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=GX, right of=GX]
 {x};

 \draw[->] (KGX) to (K);
 \draw[->] (KGX) to (GX);

 \draw[->] (GX) to (G);
 \draw[->] (GX) to (X);

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {};

 \draw[->] (Stk0.center) to (KGX);

 \end{scope}
--- a/diagrams/gm/spine+stack.tex
+++ b/diagrams/gm/spine+stack.tex
@ -0,0 +1,25 @@
 \begin{scope}[node distance=0.75cm]

 \node (FGX) [color=blue,inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};
 \node (FG) [color=blue,xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, left of=FGX] {@};
 \node (X) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, right of=FGX] {y};
 \node (F) [color=blue,xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=FG, left of=FG, xshift=2] {f};
 \node (G) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FG, right of=FG, xshift=-2] {x};

 \draw[->] (FGX) to (X);
 \draw[->,color=blue] (FGX) to (FG);
 \draw[->,color=blue] (FG) to (F.north east);
 \draw[->] (FG) to (G.north west);

 \node (Stk0) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, 0) {};
 \node (Stk1) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -0.75) {};
 \node (Stk2) [draw, shape=rectangle, minimum width=1.5cm, minimum height=0.75cm, anchor=center]
 at (-2.75, -1.5) {};

 \draw[->] (Stk0.center) to (FGX);
 \draw[->] (Stk1.center) to (FG);
 \draw[->] (Stk2.center) to (F);

 \end{scope}
--- a/diagrams/gm/spine.tex
+++ b/diagrams/gm/spine.tex
@ -0,0 +1,14 @@
 \begin{scope}[node distance=0.75cm]

 \node (FGX) [color=blue,inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};
 \node (FG) [color=blue,xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, left of=FGX] {@};
 \node (X) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FGX, right of=FGX] {y};
 \node (F) [color=blue,xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=FG, left of=FG, xshift=2] {f};
 \node (G) [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=FG, right of=FG, xshift=-2] {x};

 \draw[->] (FGX) to (X);
 \draw[->,color=blue] (FGX) to (FG);
 \draw[->,color=blue] (FG) to (F.north east);
 \draw[->] (FG) to (G.north west);

 \end{scope}
--- a/diagrams/template/step1.tex
+++ b/diagrams/template/step1.tex
@ -0,0 +1 @@
 \node at (0, 0) {main};
--- a/diagrams/template/step2.tex
+++ b/diagrams/template/step2.tex
@ -0,0 +1,26 @@
 \begin{scope}[node distance=0.75cm]

 \node (DoDo4) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};

 \node (Do)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, left of=DoDo4]
 {double};

 \node (Do4) 
 [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, right of=DoDo4]
 {@};

 \node (Do_2)
 [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=Do4, left of=Do4, xshift=2]
 {double};

 \node (4)
 [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=Do4, right of=Do4, xshift=-2]
 {4};

 \draw[->] (DoDo4) to (Do);
 \draw[->] (DoDo4) to (Do4);
 \draw[->] (Do4) to (Do_2);
 \draw[->] (Do4) to (4);

 \end{scope}
--- a/diagrams/template/step3.tex
+++ b/diagrams/template/step3.tex
@ -0,0 +1,33 @@
 \begin{scope}[node distance=0.75cm]

 \node (DoDo4) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};

 \node (TimesAp)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, left of=DoDo4]
 {@};

 \node (Times)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=TimesAp, left of=TimesAp]
 {$+$};

 \node (Do4) 
 [xshift=-0.5cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4,
 right of=DoDo4, yshift=-0.5cm]
 {@};

 \node (Do_2)
 [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=Do4, left of=Do4, xshift=2]
 {double};

 \node (4)
 [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=Do4, right of=Do4, xshift=-2]
 {4};

 \draw[->] (DoDo4) to (TimesAp);
 \draw[->] (TimesAp) to (Times);
 \draw[->] (TimesAp) |- (Do4);
 \draw[->] (DoDo4) to (Do4);
 \draw[->] (Do4) to (Do_2);
 \draw[->] (Do4) to (4);

 \end{scope}
--- a/diagrams/template/step4.tex
+++ b/diagrams/template/step4.tex
@ -0,0 +1,38 @@
 \begin{scope}[node distance=0.75cm]

 \node (DoDo4) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};

 \node (TimesAp)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, left of=DoDo4]
 {@};

 \node (Times)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=TimesAp, left of=TimesAp]
 {$+$};

 \node (Times44) 
 [xshift=-0.5cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, right of=DoDo4, yshift=-0.5cm]
 {@};

 \node (4)
 [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=Times44, right of=Times44, yshift=-0.75cm]
 {4};

 \node (Times4)
 [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=Times44, left of=Times44, xshift=2]
 {@};

 \node (Times2)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=Times4, left of=Times4]
 {$+$};

 \draw[->] (DoDo4) to (TimesAp);
 \draw[->] (TimesAp) to (Times);
 \draw[->] (TimesAp) to (Times44);
 \draw[->] (DoDo4) to (Times44);
 \draw[->] (Times44) to (Times4);
 \draw[->] (Times4) to (Times2);
 \draw[->] (Times4) |- (4);
 \draw[->] (Times44) to (4);

 \end{scope}
--- a/diagrams/template/step4red.tex
+++ b/diagrams/template/step4red.tex
@ -0,0 +1,38 @@
 \begin{scope}[node distance=0.75cm]

 \node (DoDo4) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};

 \node (TimesAp)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, left of=DoDo4]
 {@};

 \node (Times)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=TimesAp, left of=TimesAp]
 {$+$};

 \node (Times44) 
 [xshift=-0.5cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, right of=DoDo4, yshift=-0.5cm, color=blue]
 {@};

 \node (4)
 [xshift=-0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=Times44, right of=Times44, yshift=-0.75cm, color=blue]
 {4};

 \node (Times4)
 [xshift=0.25cm, inner xsep=0.04cm, inner ysep=0.05cm, below of=Times44, left of=Times44, xshift=2, color=blue]
 {@};

 \node (Times2)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=Times4, left of=Times4, color=blue]
 {$+$};

 \draw[->] (DoDo4) to (TimesAp);
 \draw[->] (TimesAp) to (Times);
 \draw[->] (TimesAp) to (Times44);
 \draw[->] (DoDo4) to (Times44);
 \draw[->,color=blue,dashed] (Times44) to (Times4);
 \draw[->,color=blue,dashed] (Times4) to (Times2);
 \draw[->,color=blue,dashed] (Times4) |- (4);
 \draw[->,color=blue,dashed] (Times44) to (4);

 \end{scope}
--- a/diagrams/template/step5.tex
+++ b/diagrams/template/step5.tex
@ -0,0 +1,22 @@
 \begin{scope}[node distance=0.75cm]

 \node (DoDo4) [inner xsep=0.01cm, inner ysep=0.03cm] at (0, 0) {@};

 \node (TimesAp)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, left of=DoDo4]
 {@};

 \node (Times)
 [xshift=0.25cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=TimesAp, left of=TimesAp]
 {$+$};

 \node (8) 
 [xshift=-0.5cm, inner xsep=0.01cm, inner ysep=0.03cm, below of=DoDo4, right of=DoDo4, yshift=-0.75cm]
 {8};

 \draw[->] (DoDo4) to (TimesAp);
 \draw[->] (TimesAp) to (Times);
 \draw[->] (TimesAp) |- (8);
 \draw[->] (DoDo4) to (8);

 \end{scope}
--- a/hie.yaml
+++ b/hie.yaml
@ -0,0 +1,2 @@
 cradle:
 stack:
--- a/package-lock.json
+++ b/package-lock.json
@ -0,0 +1,140 @@
 {
 "name": "blag",
 "version": "1.0.0",
 "lockfileVersion": 1,
 "requires": true,
 "dependencies": {
 "anymatch": {
 "version": "3.1.1",
 "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.1.tgz",
 "integrity": "sha512-mM8522psRCqzV+6LhomX5wgp25YVibjh8Wj23I5RPkPppSVSjyKD2A2mBJmWGa+KN7f2D6LNh9jkBCeyLktzjg==",
 "requires": {
 "normalize-path": "^3.0.0",
 "picomatch": "^2.0.4"
 }
 },
 "binary-extensions": {
 "version": "2.1.0",
 "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.1.0.tgz",
 "integrity": "sha512-1Yj8h9Q+QDF5FzhMs/c9+6UntbD5MkRfRwac8DoEm9ZfUBZ7tZ55YcGVAzEe4bXsdQHEk+s9S5wsOKVdZrw0tQ=="
 },
 "braces": {
 "version": "3.0.2",
 "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz",
 "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==",
 "requires": {
 "fill-range": "^7.0.1"
 }
 },
 "chokidar": {
 "version": "3.4.3",
 "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.4.3.tgz",
 "integrity": "sha512-DtM3g7juCXQxFVSNPNByEC2+NImtBuxQQvWlHunpJIS5Ocr0lG306cC7FCi7cEA0fzmybPUIl4txBIobk1gGOQ==",
 "requires": {
 "anymatch": "~3.1.1",
 "braces": "~3.0.2",
 "fsevents": "~2.1.2",
 "glob-parent": "~5.1.0",
 "is-binary-path": "~2.1.0",
 "is-glob": "~4.0.1",
 "normalize-path": "~3.0.0",
 "readdirp": "~3.5.0"
 }
 },
 "commander": {
 "version": "2.20.3",
 "resolved": "https://registry.npmjs.org/commander/-/commander-2.20.3.tgz",
 "integrity": "sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ=="
 },
 "fill-range": {
 "version": "7.0.1",
 "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz",
 "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==",
 "requires": {
 "to-regex-range": "^5.0.1"
 }
 },
 "fsevents": {
 "version": "2.1.3",
 "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.1.3.tgz",
 "integrity": "sha512-Auw9a4AxqWpa9GUfj370BMPzzyncfBABW8Mab7BGWBYDj4Isgq+cDKtx0i6u9jcX9pQDnswsaaOTgTmA5pEjuQ==",
 "optional": true
 },
 "glob-parent": {
 "version": "5.1.1",
 "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.1.tgz",
 "integrity": "sha512-FnI+VGOpnlGHWZxthPGR+QhR78fuiK0sNLkHQv+bL9fQi57lNNdquIbna/WrfROrolq8GK5Ek6BiMwqL/voRYQ==",
 "requires": {
 "is-glob": "^4.0.1"
 }
 },
 "is-binary-path": {
 "version": "2.1.0",
 "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz",
 "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==",
 "requires": {
 "binary-extensions": "^2.0.0"
 }
 },
 "is-extglob": {
 "version": "2.1.1",
 "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz",
 "integrity": "sha1-qIwCU1eR8C7TfHahueqXc8gz+MI="
 },
 "is-glob": {
 "version": "4.0.1",
 "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.1.tgz",
 "integrity": "sha512-5G0tKtBTFImOqDnLB2hG6Bp2qcKEFduo4tZu9MT/H6NQv/ghhy30o55ufafxJ/LdH79LLs2Kfrn85TLKyA7BUg==",
 "requires": {
 "is-extglob": "^2.1.1"
 }
 },
 "is-number": {
 "version": "7.0.0",
 "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
 "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng=="
 },
 "katex": {
 "version": "0.11.1",
 "resolved": "https://registry.npmjs.org/katex/-/katex-0.11.1.tgz",
 "integrity": "sha512-5oANDICCTX0NqYIyAiFCCwjQ7ERu3DQG2JFHLbYOf+fXaMoH8eg/zOq5WSYJsKMi/QebW+Eh3gSM+oss1H/bww==",
 "requires": {
 "commander": "^2.19.0"
 }
 },
 "normalize-path": {
 "version": "3.0.0",
 "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
 "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA=="
 },
 "picomatch": {
 "version": "2.2.2",
 "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.2.2.tgz",
 "integrity": "sha512-q0M/9eZHzmr0AulXyPwNfZjtwZ/RBZlbN3K3CErVrk50T2ASYI7Bye0EvekFY3IP1Nt2DHu0re+V2ZHIpMkuWg=="
 },
 "readdirp": {
 "version": "3.5.0",
 "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.5.0.tgz",
 "integrity": "sha512-cMhu7c/8rdhkHXWsY+osBhfSy0JikwpHK/5+imo+LpeasTF8ouErHrlYkwT0++njiyuDvc7OFY5T3ukvZ8qmFQ==",
 "requires": {
 "picomatch": "^2.2.1"
 }
 },
 "sass": {
 "version": "1.28.0",
 "resolved": "https://registry.npmjs.org/sass/-/sass-1.28.0.tgz",
 "integrity": "sha512-9FWX/0wuE1KxwfiP02chZhHaPzu6adpx9+wGch7WMOuHy5npOo0UapRI3FNSHva2CczaYJu2yNUBN8cCSqHz/A==",
 "requires": {
 "chokidar": ">=2.0.0 <4.0.0"
 }
 },
 "to-regex-range": {
 "version": "5.0.1",
 "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
 "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
 "requires": {
 "is-number": "^7.0.0"
 }
 }
 }
 }
--- a/package.json
+++ b/package.json
@ -0,0 +1,21 @@
 {
 "name": "blag",
 "version": "1.0.0",
 "description": "[Go here instead](https://abby.how)",
 "main": "index.js",
 "dependencies": {
 "katex": "^0.11.1",
 "sass": "^1.28.0"
 },
 "devDependencies": {},
 "scripts": {
 "up": "stack run -- build && stack run -- deploy",
 "watch": "stack run -- watch"
 },
 "repository": {
 "type": "git",
 "url": "[email protected]:plt-hokusai/blag.git"
 },
 "author": "",
 "license": "ISC"
 }
--- a/pages/contact.md
+++ b/pages/contact.md
@ -0,0 +1,35 @@
 ---
 title: Contact
 ---
 Here are the easiest ways to reach me:

 <style>
 span#reading-length { display: none; }
 </style>

 <div class="contact-list">
 <div class="contact-card">
 <span class="username">@abby#4600</span>

 My Discord friend requests are always open. Feel free to add me for questions or comments!
 </div>

 <div class="contact-card">
 <span class="username">{abby}</span>

 <span>
 Message me directly on <a href="https://webchat.freenode.net/">Freenode</a> IRC, or join `##dependent` to talk about types!
 </span>
 </div>
 </div>

 If you like what I do, here are some ways you can support this blog:

 <div class="contact-list">
 <div class="contact-card">
 <span class="username"><a href="https://ko-fi.com/pltabby">Ko-fi</a></span>

 You can send me a one-time donation on Ko-Fi. Just remember not to read the name on the receipt!
 (Paypal sucks)
 </div>
 </div>
--- a/pages/index.html
+++ b/pages/index.html
@ -0,0 +1,13 @@
 ---
 title: Home
 ---

 <p>
 You've reached Abigail's blog, a place where I exposit and reflect on programming languages and type theory.
 Here's the posts I've written recently:
 </p>

 <h2>Posts</h2>
 $partial("templates/post-list.html")$

 <p>…or you can find more in the <a href="/archive.html">archives</a>.</p>
--- a/pages/oss.md
+++ b/pages/oss.md
@ -0,0 +1,14 @@
 ---
 title: Open-source Licenses
 ---

 <style>
 span#reading-length { display: none; }
 </style>

 This blog redistributes (parts of) the following free software projects:

 * **KaTeX** is a fast JavaScript library for rendering LaTeX on the client. I use it to pre-generate amazing looking mathematics at compile time. **KaTeX is licensed under the terms of the MIT license, with a copy available [here](/static/licenses/LICENSE.KaTeX)**.


 * **Fantasque Sans Mono** is the programming font I've used for the past 3 years, including on this website. **Fantasque Sans Mono is distributed under the terms of the Open Font License (OFL), with a copy available [here](/static/licenses/LICENSE.FantasqueSansMono)**.
--- a/pages/posts/2016-08-17-parsec.md
+++ b/pages/posts/2016-08-17-parsec.md
@ -0,0 +1,308 @@
 ---
 title: You could have invented Parsec
 date: August 17, 2016 01:29 AM
 ---

 As most of us should know, [Parsec](https://hackage.haskell.org/package/parsec)
 is a relatively fast, lightweight monadic parser combinator library.

 In this post I aim to show that monadic parsing is not only useful, but a simple
 concept to grok.

 We shall implement a simple parsing library with instances of common typeclasses
 of the domain, such as Monad, Functor and Applicative, and some example
 combinators to show how powerful this abstraction really is.

 ---

 Getting the buzzwords out of the way, being _monadic_ just means that Parsers
 instances of `Monad`{.haskell}. Recall the Monad typeclass, as defined in
 `Control.Monad`{.haskell},

 ```haskell
 class Applicative m => Monad m where
 return :: a -> m a
 (>>=) :: m a -> (a -> m b) -> m b
 {- Some fields omitted -}
 ```

 How can we fit a parser in the above constraints? To answer that, we must first
 define what a parser _is_.

 A naïve implementation of the `Parser`{.haskell} type would be a simple type
 synonym.

 ```haskell
 type Parser a = String -> (a, String)
 ```

 This just defines that a parser is a function from a string to a result pair
 with the parsed value and the resulting stream. This would mean that parsers are
 just state transformers, and if we define it as a synonym for the existing mtl
 `State`{.haskell} monad, we get the Monad, Functor and Applicative instances for
 free! But alas, this will not do.

 Apart from modeling the state transformation that a parser expresses, we need a
 way to represent failure. You already know that `Maybe a`{.haskell} expresses
 failure, so we could try something like this:

 ```haskell
 type Parser a = String -> Maybe (a, String)
 ```

 But, as you might have guessed, this is not the optimal representation either:
 `Maybe`{.haskell} _does_ model failure, but in a way that is lacking. It can
 only express that a computation was successful or that it failed, not why it
 failed. We need a way to fail with an error message. That is, the
 `Either`{.haskell} monad.

 ```haskell
 type Parser e a = String -> Either e (a, String)
 ```

 Notice how we have the `Maybe`{.haskell} and `Either`{.haskell} outside the
 tuple, so that when an error happens we stop parsing immediately. We could
 instead have them inside the tuple for better error reporting, but that's out of
 scope for a simple blag post.

 This is pretty close to the optimal representation, but there are still some
 warts things to address: `String`{.haskell} is a bad representation for textual
 data, so ideally you'd have your own `Stream`{.haskell} class that has instances
 for things such as `Text`{.haskell}, `ByteString`{.haskell} and
 `String`{.haskell}.

 One issue, however, is more glaring: You _can't_ define typeclass instances for
 type synonyms! The fix, however, is simple: make `Parser`{.haskell} a newtype.

 ```haskell
 newtype Parser a
 = Parser { parse :: String -> Either String (a, String) }
 ```

 ---

 Now that that's out of the way, we can actually get around to instancing some
 typeclasses.

 Since the AMP landed in GHC 7.10 (base 4.8), the hierarchy of the Monad
 typeclass is as follows:

 ```haskell
 class Functor (m :: * -> *) where
 class Functor m => Applicative m where
 class Applicative m => Monad m where
 ```

 That is, we need to implement Functor and Applicative before we can actually
 implement Monad.

 We shall also add an `Alternative`{.haskell} instance for expressing choice.

 First we need some utility functions, such as `runParser`{.haskell}, that runs a
 parser from a given stream.

 ```haskell
 runParser :: Parser a -> String -> Either String a
 runParser (Parser p) s = fst <$> p s
 ```

 We could also use function for modifying error messages. For convenience, we
 make this an infix operator, `<?>`{.haskell}.

 ```haskell
 (<?>) :: Parser a -> String -> Parser a
 (Parser p) <?> err = Parser go where
 go s = case p s of
 Left _ -> Left err
 Right x -> return x
 infixl 2 <?>
 ```


 `Functor`
 =======

 Remember that Functor models something that can be mapped over (technically,
 `fmap`-ed over).

 We need to define semantics for `fmap` on Parsers. A sane implementation would
 only map over the result, and keeping errors the same. This is a homomorphism,
 and follows the Functor laws.

 However, since we can't modify a function in place, we need to return a new
 parser that applies the given function _after_ the parsing is done.

 ```haskell
 instance Functor Parser where
 fn `fmap` (Parser p) = Parser go where
 go st = case p st of
 Left e -> Left e
 Right (res, str') -> Right (fn res, str')
 ```

 ### `Applicative`

 While Functor is something that can be mapped over, Applicative defines
 semantics for applying a function inside a context to something inside a
 context.

 The Applicative class is defined as

 ```haskell
 class Functor m => Applicative m where
 pure :: a -> m a
 (<*>) :: f (a -> b) -> f a -> f b
 ```

 Notice how the `pure`{.haskell} and the `return`{.haskell} methods are
 equivalent, so we only have to implement one of them.

 Let's go over this by parts.

 ```haskell
 instance Applicative Parser where
 pure x = Parser $ \str -> Right (x, str)
 ```

 The `pure`{.haskell} function leaves the stream untouched, and sets the result
 to the given value.

 The `(<*>)`{.haskell} function needs to to evaluate and parse the left-hand side
 to get the in-context function to apply it.

 ```haskell
 (Parser p) <*> (Parser p') = Parser go where
 go st = case p st of
 Left e -> Left e
 Right (fn, st') -> case p' st' of
 Left e' -> Left e'
 Right (v, st'') -> Right (fn v, st'')
 ```

 ### `Alternative`

 Since the only superclass of Alternative is Applicative, we can instance it
 without a Monad instance defined. We do, however, need an import of
 `Control.Applicative`{.haskell}.

 ```haskell
 instance Alternative Parser where
 empty = Parser $ \_ -> Left "empty parser"
 (Parser p) <|> (Parser p') = Parser go where
 go st = case p st of
 Left _ -> p' st
 Right x -> Right x
 ```

 ### `Monad`

 After almost a thousand words, one would be excused for forgetting we're
 implementing a _monadic_ parser combinator library. That means, we need an
 instance of the `Monad`{.haskell} typeclass.

 Since we have an instance of Applicative, we don't need an implementation of
 return: it is equivalent to `pure`, save for the class constraint.

 ```haskell
 instance Monad Parser where
 return = pure
 ```


 The `(>>=)`{.haskell} implementation, however, needs a bit more thought. Its
 type signature is

 ```haskell
 (>>=) :: m a -> (a -> m b) -> m b
 ```

 That means we need to extract a value from the Parser monad and apply it to the
 given function, producing a new Parser.

 ```haskell
 (Parser p) >>= f = Parser go where
 go s = case p s of
 Left e -> Left e
 Right (x, s') -> parse (f x) s'
 ```

 While some people think that the `fail`{.haskell} is not supposed to be in the
 Monad typeclass, we do need an implementation for when pattern matching fails.
 It is also convenient to use `fail`{.haskell} for the parsing action that
 returns an error with a given message.

 ```haskell
 fail m = Parser $ \_ -> Left m
 ```

 ---

 We now have a `Parser`{.haskell} monad, that expresses a parsing action. But, a
 parser library is no good when actual parsing is made harder than easier. To
 make parsing easier, we define _combinators_, functions that modify a parser in
 one way or another.

 But first, we should get some parsing functions.

 ### any, satisfying

 `any` is the parsing action that pops a character off the stream and returns
 that. It does no further parsing at all.

 ```haskell
 any :: Parser Char
 any = Parser go where
 go [] = Left "any: end of file"
 go (x:xs) = Right (x,xs)
 ```

 `satisfying` tests the parsed value against a function of type `Char ->
 Bool`{.haskell} before deciding if it's successful or a failure.

 ```haskell
 satisfy :: (Char -> Bool) -> Parser Char
 satisfy f = d
 x <- any
 if f x
 then return x
 else fail "satisfy: does not satisfy"
 ```

 We use the `fail`{.haskell} function defined above to represent failure.

 ### `oneOf`, `char`

 These functions are defined in terms of `satisfying`, and parse individual
 characters.

 ```haskell
 char :: Char -> Parser Char
 char c = satisfy (c ==) <?> "char: expected literal " ++ [c]

 oneOf :: String -> Parser Char
 oneOf s = satisfy (`elem` s) <?> "oneOf: expected one of '" ++ s ++ "'"
 ```

 ### `string`

 This parser parses a sequence of characters, in order.

 ```haskell
 string :: String -> Parser String
 string [] = return []
 string (x:xs) = do
 char x
 string xs
 return $ x:xs
 ```

 ---

 And that's it! In a few hundred lines, we have built a working parser combinator
 library with Functor, Applicative, Alternative, and Monad instances. While it's
 not as complex or featureful as Parsec in any way, it is powerful enough to
 define grammars for simple languages.

 [A transcription](/static/Parser.hs) ([with syntax
 highlighting](/static/Parser.hs.html)) of this file is available as runnable
 Haskell. The transcription also features some extra combinators for use.
--- a/pages/posts/2016-08-23-hasochism.lhs
+++ b/pages/posts/2016-08-23-hasochism.lhs
@ -0,0 +1,331 @@
 ---
 title: Dependent types in Haskell - Sort of
 date: August 23, 2016
 ---

 **Warning**: An intermediate level of type-fu is necessary for understanding
 *this post.

 The glorious Glasgow Haskell Compilation system, since around version 6.10 has
 had support for indexed type familes, which let us represent functional
 relationships between types. Since around version 7, it has also supported
 datatype-kind promotion, which lifts arbitrary data declarations to types. Since
 version 8, it has supported an extension called `TypeInType`, which unifies the
 kind and type level.

 With this in mind, we can implement the classical dependently-typed example:
 Length-indexed lists, also called `Vectors`{.haskell}.

 ----

 > {-# LANGUAGE TypeInType #-}

 `TypeInType` also implies `DataKinds`, which enables datatype promotion, and
 `PolyKinds`, which enables kind polymorphism.

 `TypeOperators` is needed for expressing type-level relationships infixly, and
 `TypeFamilies` actually lets us define these type-level functions.

 > {-# LANGUAGE TypeOperators #-}
 > {-# LANGUAGE TypeFamilies #-}

 Since these are not simple-kinded types, we'll need a way to set their kind
 signatures[^kind] explicitly. We'll also need Generalized Algebraic Data Types
 (or GADTs, for short) for defining these types.

 > {-# LANGUAGE KindSignatures #-}
 > {-# LANGUAGE GADTs #-}

 Since GADTs which couldn't normally be defined with regular ADT syntax can't
 have deriving clauses, we also need `StandaloneDeriving`.

 > {-# LANGUAGE StandaloneDeriving #-}

 > module Vector where
 > import Data.Kind

 ----

 Natural numbers
 ===============

 We could use the natural numbers (and singletons) implemented in `GHC.TypeLits`,
 but since those are not defined inductively, they're painful to use for our
 purposes.

 Recall the definition of natural numbers proposed by Giuseppe Peano in his
 axioms: **Z**ero is a natural number, and the **s**uccessor of a natural number
 is also a natural number.

 If you noticed the bold characters at the start of the words _zero_ and
 _successor_, you might have already assumed the definition of naturals to be
 given by the following GADT:

 < data Nat where
 < Z :: Nat
 < S :: Nat -> Nat

 This is fine if all you need are natural numbers at the _value_ level, but since
 we'll be parametrising the Vector type with these, they have to exist at the
 type level. The beauty of datatype promotion is that any promoted type will
 exist at both levels: A kind with constructors as its inhabitant types, and a
 type with constructors as its... constructors.

 Since we have TypeInType, this declaration was automatically lifted, but we'll
 use explicit kind signatures for clarity.

 > data Nat :: Type where
 > Z :: Nat
 > S :: Nat -> Nat

 The `Type` kind, imported from `Data.Kind`, is a synonym for the `*` (which will
 eventually replace the latter).

 Vectors
 =======

 Vectors, in dependently-typed languages, are lists that apart from their content
 encode their size along with their type.

 If we assume that lists can not have negative length, and an empty vector has
 length 0, this gives us a nice inductive definition using the natural number
 ~~type~~ kind[^kinds]

 > 1. An empty vector of `a` has size `Z`{.haskell}.
 > 2. Adding an element to the front of a vector of `a` and length `n` makes it
 > have length `S n`{.haskell}.

 We'll represent this in Haskell as a datatype with a kind signature of `Nat ->
 Type -> Type` - That is, it takes a natural number (remember, these were
 automatically lifted to kinds), a regular type, and produces a regular type.
 Note that, `->` still means a function at the kind level.

 > data Vector :: Nat -> Type -> Type where

 Or, without use of `Type`,

 < data Vector :: Nat -> * -> * where

 We'll call the empty vector `Nil`{.haskell}. Remember, it has size
 `Z`{.haskell}.

 > Nil :: Vector Z a

 Also note that type variables are implicit in the presence of kind signatures:
 They are assigned names in order of appearance.

 Consing onto a vector, represented by the infix constructor `:|`, sets its
 length to the successor of the existing length, and keeps the type of elements
 intact.

 > (:|) :: a -> Vector x a -> Vector (S x) a

 Since this constructor is infix, we also need a fixidity declaration. For
 consistency with `(:)`, cons for regular lists, we'll make it right-associative
 with a precedence of `5`.

 > infixr 5 :|

 We'll use derived `Show`{.haskell} and `Eq`{.haskell} instances for
 `Vector`{.haskell}, for clarity reasons. While the derived `Eq`{.haskell} is
 fine, one would prefer a nicer `Show`{.haskell} instance for a
 production-quality library.

 > deriving instance Show a => Show (Vector n a)
 > deriving instance Eq a => Eq (Vector n a)

 Slicing up Vectors {#slicing}
 ==================

 Now that we have a vector type, we'll start out by implementing the 4 basic
 operations for slicing up lists: `head`, `tail`, `init` and `last`.

 Since we're working with complicated types here, it's best to always use type
 signatures.

 Head and Tail {#head-and-tail}
 -------------

 Head is easy - It takes a vector with length `>1`, and returns its first
 element. This could be represented in two ways.

 < head :: (S Z >= x) ~ True => Vector x a -> a

 This type signature means that, if the type-expression `S Z >= x`{.haskell}
 unifies with the type `True` (remember - datakind promotion at work), then head
 takes a `Vector x a` and returns an `a`.

 There is, however, a much simpler way of doing the above.

 > head :: Vector (S x) a -> a

 That is, head takes a vector whose length is the successor of a natural number
 `x` and returns its first element.

 The implementation is just as concise as the one for lists:

 > head (x :| _) = x

 That's it. That'll type-check and compile.

 Trying, however, to use that function on an empty vector will result in a big
 scary type error:

 ```plain
 Vector> Vector.head Nil

 <interactive>:1:13: error:
 • Couldn't match type ‘'Z’ with ‘'S x0’
 Expected type: Vector ('S x0) a
 Actual type: Vector 'Z a
 • In the first argument of ‘Vector.head’, namely ‘Nil’
 In the expression: Vector.head Nil
 In an equation for ‘it’: it = Vector.head Nil
 ```

 Simplified, it means that while it was expecting the successor of a natural
 number, it got zero instead. This function is total, unlike the one in
 `Data.List`{.haskell}, which fails on the empty list.

 < head [] = error "Prelude.head: empty list"
 < head (x:_) = x

 Tail is just as easy, except in this case, instead of discarding the predecessor
 of the vector's length, we'll use it as the length of the resulting vector.

 This makes sense, as, logically, getting the tail of a vector removes its first
 length, thus "unwrapping" a level of `S`.

 > tail :: Vector (S x) a -> Vector x a
 > tail (_ :| xs) = xs

 Notice how neither of these have a base case for empty vectors. In fact, adding
 one will not typecheck (with the same type of error - Can't unify `Z`{.haskell}
 with `S x`{.haskell}, no matter how hard you try.)

 Init {#init}
 ----

 What does it mean to take the initial of an empty vector? That's obviously
 undefined, much like taking the tail of an empty vector. That is, `init` and
 `tail` have the same type signature.

 > init :: Vector (S x) a -> Vector x a

 The `init` of a singleton list is nil. This type-checks, as the list would have
 had length `S Z` (that is - 1), and now has length `Z`.

 > init (x :| Nil) = Nil

 To take the init of a vector with more than one element, all we do is recur on
 the tail of the list.

 > init (x :| y :| ys) = x :| Vector.init (y :| ys)

 That pattern is a bit weird - it's logically equivalent to `(x :|
 xs)`{.haskell}. But, for some reason, that doesn't make the typechecker happy,
 so we use the long form.

 Last {#last}
 ----

 Last can, much like the list version, be implemented in terms of a left fold.
 The type signature is like the one for head, and the fold is the same as that
 for lists. The foldable instance for vectors is given [here](#Foldable).

 > last :: Vector (S x) a -> a
 > last = foldl (\_ x -> x) impossible where

 Wait - what's `impossible`? Since this is a fold, we do still need an initial
 element - We could use a pointful fold with the head as the starting point, but
 I feel like this helps us to understand the power of dependently-typed vectors:
 That error will _never_ happen. Ever. That's why it's `impossible`!

 > impossible = error "Type checker, you have failed me!"

 That's it for the basic vector operations. We can now slice a vector anywhere
 that makes sense - Though, there's one thing missing: `uncons`.

 Uncons {#uncons}
 ------

 Uncons splits a list (here, a vector) into a pair of first element and rest.
 With lists, this is generally implemented as returning a `Maybe`{.haskell} type,
 but since we can encode the type of a vector in it's type, there's no need for
 that here.

 > uncons :: Vector (S x) a -> (a, Vector x a)
 > uncons (x :| xs) = (x, xs)

 Mapping over Vectors {#functor}
 ====================

 We'd like a `map` function that, much like the list equivalent, applies a
 function to all elements of a vector, and returns a vector with the same length.
 This operation should hopefully be homomorphic: That is, it keeps the structure
 of the list intact.

 The `base` package has a typeclass for this kind of morphism, can you guess what
 it is? If you guessed Functor, then you're right! If you didn't, you might
 aswell close the article now - Heavy type-fu inbound, though not right now.

 The functor instance is as simple as can be:

 > instance Functor (Vector x) where

 The fact that functor expects something of kind `* -> *`, we need to give the
 length in the instance head - And since we do that, the type checker guarantees
 that this is, in fact, a homomorphic relationship.

 Mapping over `Nil` just returns `Nil`.

 > f `fmap` Nil = Nil

 Mapping over a list is equivalent to applying the function to the first element,
 then recurring over the tail of the vector.

 > f `fmap` (x :| xs) = f x :| (fmap f xs)

 We didn't really need an instance of Functor, but I think standalone map is
 silly.

 Folding Vectors {#foldable}
 ===============

 The Foldable class head has the same kind signature as the Functor class head:
 `(* -> *) -> Constraint` (where `Constraint` is the kind of type classes), that
 is, it's defined by the class head

 < class Foldable (t :: Type -> Type) where

 So, again, the length is given in the instance head.

 > instance Foldable (Vector x) where
 > foldr f z Nil = z
 > foldr f z (x :| xs) = f x $ foldr f z xs

 This is _exactly_ the Foldable instance for `[a]`, except the constructors are
 different. Hopefully, by now you've noticed that Vectors have the same
 expressive power as lists, but with more safety enforced by the type checker.

 Conclusion
 ==========

 Two thousand words in, we have an implementation of functorial, foldable vectors
 with implementations of `head`, `tail`, `init`, `last` and `uncons`. Since
 going further (implementing `++`, since a Monoid instance is impossible) would
 require implementing closed type familes, we'll leave that for next time.

 Next time, we'll tackle the implementation of `drop`, `take`, `index` (`!!`, but
 for vectors), `append`, `length`, and many other useful list functions.
 Eventually, you'd want an implementation of all functions in `Data.List`. We
 shall tackle `filter` in a later issue.

 [^kind]: You can read about [Kind polymorphism and
 Type-in-Type](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#kind-polymorphism-and-type-in-type)
 in the GHC manual.

 [^kinds]: The TypeInType extension unifies the type and kind level, but this
 article still uses the word `kind` throughout. This is because it's easier to
 reason about types, datatype promotion and type familes if you have separate
 type and kind levels.
--- a/pages/posts/2016-08-26-parsec2.lhs
+++ b/pages/posts/2016-08-26-parsec2.lhs
@ -0,0 +1,172 @@
 ---
 title: Monadic Parsing with User State
 date: August 26, 2016
 ---

 > {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses #-}
 > module StatefulParsing where
 > import Control.Monad.State.Class
 > import Control.Applicative

 In this post I propose an extension to the monadic parser framework
 introduced in a previous post, _[You could have invented
 Parsec](/posts/2016-08-17.html)_, that extends
 the parser to also support embedded user state in your parsing.

 This could be used, for example, for parsing a language with
 user-extensible operators: The precedences and fixidities of operators
 would be kept in a hashmap threaded along the bind chain.

 Instead of posing these changes as diffs, we will rewrite the parser
 framework from scratch with the updated type.

 ---

 Parser `newtype`{.haskell}
 =========================

 Our new parser is polymorphic in both the return type and the user state
 that, so we have to update the `newtype`{.haskell} declaration to match.

 > newtype Parser state result
 > = Parser { runParser :: String
 > -> state
 > -> Either String (result, state, String) }

 Our tuple now contains the result of the parsing operation and the new
 user state, along with the stream. We still need to supply a stream to
 parse, and now also supply the initial state. This will be reflected in
 our functions.

 For convenience, we also make a `Parser' a`{.haskell} type alias for
 parsers with no user state.

 < type Parser' a = Parser () a

 Seeing as type constructors are also curried, we can apply η-reduction
 to get the following, which is what we'll go
 with.

 > type Parser' = Parser ()

 `Functor`{.haskell} instance
 ============================

 > instance Functor (Parser st) where

 The functor instance remains mostly the same, except now we have to
 thread the user state around, too.

 The instance head also changes to fit the kind signature of the
 `Functor`{.haskell} typeclass. Since user state can not change from
 fmapping, this is fine.

 > fn `fmap` (Parser p) = Parser go where
 > go st us = case p st us of
 > Left e -> Left e
 > Right (r, us', st') -> Right (fn r, us', st')

 As you can see, the new user state (`us'`) is just returned as is.

 `Applicative`{.haskell} instance
 ================================

 > instance Applicative (Parser st) where

 The new implementations of `pure`{.haskell} and `<*>`{.haskell} need to
 correctly manipulate the user state. In the case of `pure`, it's just passed
 as-is to the `Right`{.haskell} constructor.

 > pure ret = Parser go where
 > go st us = Right (ret, us, st)

 Since `(<*>)` needs to evaluate both sides before applying the function, we need
 to pass the right-hand side's generated user state to the right-hand side for
 evaluation.

 > (Parser f) <*> (Parser v) = Parser go where
 > go st us = case f st us of
 > Left e -> Left e
 > Right (fn, us', st') -> case v st' us' of
 > Left e -> Left e
 > Right (vl, us'', st'') -> Right (fn vl, us'', st'')


 `Monad`{.haskell} instance
 ==========================

 > instance Monad (Parser st) where

 Since we already have an implementation of `pure`{.haskell} from the Applicative
 instance, we don't need to worry about an implementation of `return`.

 > return = pure

 The monad instance is much like the existing monad instance, except now we have
 to give the updated parser state to the new computation.

 > (Parser p) >>= f = Parser go where
 > go s u = case p s u of
 > Left e -> Left e
 > Right (x, u', s') -> runParser (f x) s' u'

 `MonadState`{.haskell} instance
 ===============================

 > instance MonadState st (Parser st) where

 Since we now have a state transformer in the parser, we can make it an instance
 of the MTL's `MonadState` class.

 The implementation of `put`{.haskell} must return `()` (the unit value), and
 needs to replace the existing state with the supplied one. This operation can
 not fail.

 Since this is a parsing framework, we also need to define how the stream is
 going to be affected: In this case, it isn't.

 > put us' = Parser go where
 > go st _ = Right ((), us', st)

 The `get`{.haskell} function returns the current user state, and leaves it
 untouched. This operation also does not fail.

 > get = Parser go where
 > go st us = Right (us, us, st)

 Since we're an instance of `MonadState`{.haskell}, we needn't an implementation
 of `modify` and friends - They're given by the MTL.

 `Alternative`{.haskell} instance
 ================================

 > instance Alternative (Parser st) where

 The `Alternative`{.haskell} instance uses the same state as it was given for
 trying the next parse.

 The `empty`{.haskell} parser just fails unconditionally.

 > empty = Parser go where
 > go _ _ = Left "empty parser"

 `(<|>)` will try both parsers in order, reusing both the state and the stream.

 > (Parser p) <|> (Parser q) = Parser go where
 > go st us = case p st us of
 > Left e -> q st us
 > Right v -> Right v

 Conclusion
 ==========

 This was a relatively short post. This is because many of the convenience
 functions defined in the previous post also work with this parser framework, if
 you replace `Parser` with `Parser'`. You can now use `get`, `put` and `modify`
 to work on the parser's user state. As a closing note, a convenience function
 for running parsers with no state is given.

 > parse :: Parser' a -> String -> Either String a
 > parse str = case runParser str () of
 > Left e -> Left e
 > Right (x, _, _) -> x
--- a/pages/posts/2017-08-01-delimcc.md
+++ b/pages/posts/2017-08-01-delimcc.md
@ -0,0 +1,155 @@
 ---
 title: Delimited Continuations, Urn and Lua
 date: August 1, 2017
 ---

 As some of you might know, [Urn](https://squiddev.github.io/urn) is my
 current pet project. This means that any potential upcoming blag posts
 are going to involve it in some way or another, and that includes this
 one. For the uninitiated, Urn is a programming language which compiles
 to Lua[^1], in the Lisp tradition, with no clear ascendance: We take
 inspiration from several Lisps, most notably Common Lisp and Scheme.

 As functional programmers at heart, we claim to be minimalists: Urn is
 reduced to 12 core forms before compilation, with some of those being
 redundant (e.g. having separate `define` and `define-macro` builtins
 instead of indicating that the definition is a macro through
 a parameter). On top of these primitives we build all our abstraction,
 and one such abstraction is what this post is about: _Delimited
 continuations_.

 Delimited continuations are a powerful control abstraction first
 introduced by Matthias Felleisein[^2], initially meant as
 a generalisation of several other control primitives such as
 `call-with-current-continuation`{.scheme} from Scheme among others.
 However, whereas `call-with-current-continuation`{.scheme} captures
 a continuation representing the state of the entire program after that
 point, delimited continuations only reify a slice of program state. In
 this, they are cheaper to build and invoke, and as such may be used to
 implement e.g. lightweight threading primitives.

 While this may sound rather limiting, there are very few constructs that
 can simultaneously be implemented with
 `call-with-current-continuation`{.scheme} without also being expressible
 in terms of delimited continuations. The converse, however, is untrue.
 While `call/cc`{.scheme} be used to implement any control abstraction,
 it can't implement any _two_ control abstractions: the continuations it
 reifies are uncomposable[^3].

 ### Delimited Continuations in Urn

 Our implementation of delimited continuations follows the Guile Scheme
 tradition of two functions `call-with-prompt` and `abort-to-prompt`,
 which are semantically equivalent to the more traditional
 `shift`/`reset`. This is, however, merely an implementation detail, as
 both schemes are available.

 We have decided to base our implementation on Lua's existing coroutine
 machinery instead of implementing an ad-hoc solution especially for Urn.
 This lets us reuse and integrate with existing Lua code, which is one of
 the goals for the language.

 `call-with-prompt` is used to introduce a _prompt_ into scope, which
 delimits a frame execution and sets up an abort handler with the
 specified tag. Later on, calls to `abort-to-prompt` reify the rest of
 the program slice's state and jump into the handler set up.

 ```lisp
 (call/p 'a-prompt-tag
 (lambda ()
 ; code to run with the prompt
 )
 (lambda (k)
 ; abort handler
 ))
 ```

 One limitation of the current implementation is that the continuation,
 when invoked, will no longer have the prompt in scope. A simple way to
 get around this is to store the prompt tag and handler in values and use
 `call/p`[^4] again instead of directly calling the continuation.

 Unfortunately, being implemented on top of Lua coroutines does bring one
 significant disadvantage: The reified continuations are single-use.
 After a continuation has reached the end of its control frame, there's
 no way to make it go back, and there's no way to copy continuations
 either (while we have a wrapper around coroutines, the coroutines
 themselves are opaque objects, and there's no equivalent of
 `string.dump`{.lua} to, for instance, decompile and recompile them)

 ### Why?

 In my opinion (which, like it or not, is the opinion of the Urn team),
 Guile-style delimited continuations provide a much better abstraction
 than operating with Lua coroutines directly, which may be error prone
 and feels out of place in a functional-first programming language.

 As a final motivating example, below is an in-depth explanation of
 a tiny cooperative task scheduler.

 ```lisp
 (defun run-tasks (&tasks) ; 1
 (loop [(queue tasks)] ; 2
 [(empty? queue)] ; 2
 (call/p 'task (car queue)
 (lambda (k)
 (when (alive? k)
 (push-cdr! queue k)))) ; 3
 (recur (cdr queue)))) ; 4
 ```

 1. We begin, of course, by defining our function. As inputs, we take
 a list of tasks to run, which are generally functions, but may be Lua
 coroutines (`threads`) or existing continuations, too. As a sidenote,
 in Urn, variadic arguments have `&` prepended to them, instead of
 having symbols beginning of `&` acting as modifiers in a lambda-list.
 For clarity, that is wholly equivalent to `(defun run-tasks (&rest
 tasks)`{.lisp}.

 2. Then, we take the first element of the queue as the current task to
 run, and set up a prompt of execution. The task will run until it
 hits an `abort-to-prompt`, at which point it will be interrupted and
 the handler will be invoked.

 3. The handler inspects the reified continuation to see if it is
 suitable for being scheduled again, and if so, pushes it to the end
 of the queue. This means it'll be the first task to execute again
 when the scheduler is done with the current set of working tasks.

 4. We loop back to the start with the first element (the task we just
 executed) removed.

 Believe it or not, the above is a fully functioning cooperative
 scheduler that can execute any number of tasks.[^5]

 ### Conclusion

 I think that the addition of delimited continuations to Urn brings
 a much needer change in the direction of the project: Moving away from
 ad-hoc abstraction to structured, proven abstraction. Hopefully this is
 the first of many to come.


 [^1]: Though this might come off as a weird decision to some, there is
 a logical reason behind it: Urn was initially meant to be used in the
 [ComputerCraft](https://computercraft.info) mod for Minecraft, which
 uses the Lua programming language, though the language has outgrown it
 by now. For example, the experimental `readline` support is being
 implemented with the LuaJIT foreign function interface.

 [^2]: [The Theory and Practice of First-Class
 Prompts](http://www.cs.tufts.edu/~nr/cs257/archive/matthias-felleisen/prompts.pdf).

 [^3]: Oleg Kiselyov demonstrates
 [here](http://okmij.org/ftp/continuations/against-callcc.html#traps)
 that abstractions built on `call/cc`{.scheme} do not compose.

 [^4]: `call-with-prompt` is a bit of a mouthful, so the alias `call/p`
 is blessed.

 [^5]: There's a working example [here](/static/tasks.lisp) ([with syntax
 highlighting](/static/tasks.lisp.html)) as runnable Urn. Clone the
 compiler then execute `lua bin/urn.lua --run tasks.lisp`.

 <!-- vim: tw=72
 -->
--- a/pages/posts/2017-08-02-urnmatch.md
+++ b/pages/posts/2017-08-02-urnmatch.md
@ -0,0 +1,231 @@
 ---
 title: The Urn Pattern Matching Library
 date: August 2, 2017
 ---

 Efficient compilation of pattern matching is not exactly an open problem
 in computer science in the same way that implementing say, type systems,
 might be, but it's still definitely possible to see a lot of mysticism
 surrounding it.

 In this post I hope to clear up some misconceptions regarding the
 implementation of pattern matching by demonstrating one such
 implementation. Do note that our pattern matching engine is strictly
 _linear_, in that pattern variables may only appear once in the match
 head. This is unlike other languages, such as Prolog, in which variables
 appearing more than once in the pattern are unified together.

 ### Structure of a Pattern Match

 Pattern matching always involves a pattern (the _match head_, as we call
 it) and a value to be compared against that pattern, the _matchee_.
 Sometimes, however, a pattern match will also include a body, to be
 evaluated in case the pattern does match.

 ```lisp
 (case 'some-value ; matchee
 [some-pattern ; match head
 (print! "some body")]) ; match body
 ```

 As a side note, keep in mind that `case`{.lisp} has linear lookup of
 match bodies. Though logarithmic or constant-time lookup might be
 possible, it is left as an exercise for the reader.

 ### Compiling Patterns

 To simplify the task of compiling patterns to an intermade form without
 them we divide their compilation into two big steps: compiling the
 pattern's test and compiling the pattern's bindings. We do so
 _inductively_ - there are a few elementary pattern forms on which the
 more complicated ones are built upon.

 Most of these elementary forms are very simple, but two are the
 simplest: _atomic forms_ and _pattern variables_. An atomic form is the
 pattern correspondent of a self-evaluating form in Lisp: a string, an
 integer, a symbol. We compare these for pointer equality. Pattern
 variables represent unknowns in the structure of the data, and a way to
 capture these unknowns.

 +------------------+----------+-------------+
 | Pattern | Test | Bindings |
 +:=================+:=========+:============+
 | Atomic form | Equality | Nothing |
 +------------------+----------+-------------+
 | Pattern variable | Nothing | The matchee |
 +------------------+----------+-------------+

 All compilation forms take as input the pattern to compile along with
 a symbol representing the matchee. Patterns which involve other patterns
 (for instance, lists, conses) will call the appropriate compilation
 forms with the symbol modified to refer to the appropriate component of
 the matchee.

 Let's quickly have a look at compiling these elementary patterns before
 looking at the more interesting ones.

 ```lisp
 (defun atomic-pattern-test (pat sym)
 `(= ,pat ,sym))
 (defun atomic-pattern-bindings (pat sym)
 '())
 ```

 Atomic forms are the simplest to compile - we merely test that the
 symbol's value is equal (with `=`, which compares identities, instead of
 with `eq?` which checks for equivalence - more complicated checks, such
 as handling list equality, need not be handled by the equality function
 as we handle them in the pattern matching library itself) and emit no
 bindings.

 ```lisp
 (defun variable-pattern-test (pat sym)
 `true)
 (defun variable-pattern-bindings (pat sym)
 (list `(,pat ,sym)))
 ```

 The converse is true for pattern variables, which have no test and bind
 themselves. The returned bindings are in association list format, and
 the top-level macro that users invoke will collect these and them bind
 them with `let*`{.lisp}.

 Composite forms are a bit more interesting: These include list patterns
 and cons patterns, for instance, and we'll look at implementing both.
 Let's start with list patterns.

 To determine if a list matches a pattern we need to test for several
 things:

 1. First, we need to test if it actually is a list at all!
 2. The length of the list is also tested, to see if it matches the length
 of the elements stated in the pattern
 3. We check every element of the list against the corresponding elements
 of the pattern

 With the requirements down, here's the implementation.

 ```lisp
 (defun list-pattern-test (pat sym)
 `(and (list? ,sym) ; 1
 (= (n ,sym) ,(n pat)) ; 2
 ,@(map (lambda (index) ; 3
 (pattern-test (nth pat index) `(nth ,sym ,index)))
 (range :from 1 :to (n pat)))))
 ```

 To test for the third requirement, we call a generic dispatch function
 (which is trivial, and thus has been inlined) to compile the $n$th pattern
 in the list against the $n$th element of the actual list.

 List pattern bindings are similarly easy:

 ```lisp
 (defun list-pattern-bindings (pat sym)
 (flat-map (lambda (index)
 (pattern-bindings (nth pat index) `(nth ,sym ,index)))
 (range :from 1 :to (n pat))))
 ```

 Compiling cons patterns is similarly easy if your Lisp is proper: We
 only need to check for `cons`{.lisp}-ness (or `list`{.lisp}-ness, less
 generally), then match the given patterns against the car and the cdr.

 ```lisp
 (defun cons-pattern-test (pat sym)
 `(and (list? ,sym)
 ,(pattern-test (cadr pat) `(car ,sym))
 ,(pattern-test (caddr pat) `(cdr ,sym))))

 (defun cons-pattern-bindings (pat sym)
 (append (pattern-bindings (cadr pat) `(car ,sym))
 (pattern-bindings (caddr pat) `(cdr ,sym))))
 ```

 Note that, in Urn, `cons` patterns have the more general form `(pats*
 . pat)` (using the asterisk with the usual meaning of asterisk), and can
 match any number of elements in the head. It is also less efficient than
 expected, due to the nature of `cdr` copying the list's tail. (Our lists
 are not linked - rather, they are implemented over Lua arrays, and as
 such, removing the first element is rather inefficient.)

 ### Using patterns

 Now that we can compile a wide assortment of patterns, we need a way to
 actually use them to scrutinize data. For this, we implement two forms:
 an improved version of `destructuring-bind`{.lisp} and `case`{.lisp}.

 Implementing `destructuring-bind`{.lisp} is simple: We only have
 a single pattern to test against, and thus no search is nescessary. We
 simply generate the pattern test and the appropriate bindings, and
 generate an error if the pattern does not mind. Generating a friendly
 error message is similarly left as an exercise for the reader.

 Note that as a well-behaving macro, destructuring bind will not evaluate
 the given variable more than once. It does this by binding it to
 a temporary name and scrutinizing that name instead.

 ```lisp
 (defmacro destructuring-bind (pat var &body)
 (let* [(variable (gensym 'var))
 (test (pattern-test pat variable))
 (bindings (pattern-bindings pat variable))]
 `(with (,variable ,var)
 (if ,test
 (progn ,@body)
 (error! "pattern matching failure")))))
 ```

 Implementing case is a bit more difficult in a language without
 `cond`{.lisp}, since the linear structure of a pattern-matching case
 statement would have to be transformed into a tree of `if`-`else`
 combinations. Fortunately, this is not our case (pun intended,
 definitely.)

 ```lisp
 (defmacro case (var &cases)
 (let* [(variable (gensym 'variable))]
 `(with (,variable ,var)
 (cond ,@(map (lambda (c)
 `(,(pattern-test (car c) variable)
 (let* ,(pattern-bindings (car c) variable)
 ,@(cdr c))))
 cases)))))
 ```


 Again, we prevent reevaluation of the matchee by binding it to
 a temporary symbol. This is especially important in an impure,
 expression-oriented language as evaluating the matchee might have side
 effects! Consider the following contrived example:

 ```lisp
 (case (progn (print! "foo")
 123)
 [1 (print! "it is one")]
 [2 (print! "it is two")]
 [_ (print! "it is neither")]) ; _ represents a wild card pattern.
 ```

 If the matchee wasn't bound to a temporary value, `"foo"` would be
 printed thrice in this example. Both the toy implementation presented
 here and the implementation in the Urn standard library will only
 evaluate matchees once, thus preventing effect duplication.

 ### Conclusion

 Unlike previous blog posts, this one isn't runnable Urn. If you're
 interested, I recommend checking out [the actual
 implementation](https://gitlab.com/urn/urn/blob/master/lib/match.lisp).
 It gets a bit hairy at times, particularly with handling of structure
 patterns (which match Lua tables), but it's similar enough to the above
 that this post should serve as a vague map of how to read it.

 In a bit of a meta-statement I want to point out that this is the first
 (second, technically!) of a series of posts detailing the interesting
 internals of the Urn standard library: It fixes two things in the sorely
 lacking category: content in this blag, and standard library
 documentation.

 Hopefully this series is as nice to read as it is for me to write, and
 here's hoping I don't forget about this blag for a year again.
--- a/pages/posts/2017-08-06-constraintprop.md
+++ b/pages/posts/2017-08-06-constraintprop.md
@ -0,0 +1,276 @@
 ---
 title: Optimisation through Constraint Propagation
 date: August 06, 2017
 ---

 Constraint propagation is a new optimisation proposed for implementation
 in the Urn compiler[^mr]. It is a variation on the idea of
 flow-sensitive typing in that it is not applied to increasing program
 safety, rather being used to improve _speed_.

 ### Motivation

 The Urn compiler is decently fast for being implemented in Lua.
 Currently, it manages to compile itself (and a decent chunk of the
 standard library) in about 4.5 seconds (when using LuaJIT; When using
 the lua.org interpreter, this time roughly doubles). Looking at
 a call-stack profile of the compiler, we notice a very interesting data
 point: about 11% of compiler runtime is spent in the `(type)` function.

 There are two ways to fix this: Either we introduce a type system (which
 is insanely hard to do for a language as dynamic as Urn - or Lisp in
 general) or we reduce the number of calls to `(type)` by means of
 optimisation. Our current plan is to do the latter.

 ### How

 The proposed solution is to collect all the branches that the program
 has taken to end up in the state it currently is. Thus, every branch
 grows the set of "constraints" - the predicates which have been invoked
 to get the program here.

 Most useful predicates involve a variable: Checking if it is or isn't
 nil, if is positive or negative, even or odd, a list or a string, and
 etc. However, when talking about a single variable, this test only has
 to be performed _once_ (in general - mutating the variable invalidates
 the set of collected constraints), and their truthiness can be kept, by
 the compiler, for later use.

 As an example, consider the following code. It has three branches, all
 of which imply something different about the type of the variable `x`.

 ```lisp
 (cond
 [(list? x)] ; first case
 [(string? x)] ; second case
 [(number? x)]) ; third case
 ```

 If, in the first case, the program then evaluated `(car x)`, it'd end up
 doing a redundant type check. `(car)`, is, in the standard library,
 implemented like so:

 ```lisp
 (defun car (x)
 (assert-type! x list)
 (.> x 0))
 ```

 `assert-type!` is merely a macro to make checking the types of arguments
 more convenient. Let's make the example of branching code a bit more
 complicated by making it take and print the `car` of the list.

 ```lisp
 (cond
 [(list? x)
 (print! (car x))])
 ; other branches elided for clarity
 ```

 To see how constraint propagation would aid the runtime performance of
 this code, let's play optimiser for a bit, and see what this code would
 end up looking like at each step.

 First, `(car x)` is inlined.
 ```lisp
 (cond
 [(list? x)
 (print! (progn (assert-type! x list)
 (.> x 0)))])
 ```

 `assert-type!` is expanded, and the problem becomes apparent: the type
 of `x` is being computed _twice_!

 ```lisp
 (cond
 [(list? x)
 (print! (progn (if (! (list? x))
 (error! "the argument x is not a list"))
 (.> x 0)))])
 ```

 If the compiler had constraint propagation (and the associated code
 motions), this code could be simplified further.

 ```lisp
 (cond
 [(list? x)
 (print! (.> x 0))])
 ```

 Seeing as we already know that `(list? x)` is true, we don't need to
 test anymore, and the conditional can be entirely eliminated. Figuring
 out `(! (list? x))` from `(list? x)` is entirely trivial constant
 folding (the compiler already does it)

 This code is optimal. The `(list? x)` test can't be eliminated because
 nothing else is known about `x`. If its value were statically known, the
 compiler could eliminate the branch and invocation of `(car x)`
 completely by constant propagation and folding (`(car)` is, type
 assertion notwithstanding, a pure function - it returns the same results
 for the same inputs. Thus, it is safe to execute at compile time)

 ### How, exactly

 In this section I'm going to outline a very simple implementation of the
 constraint propagation algorithm to be employed in the Urn compiler.
 It'll work on a simple Lisp with no quoting or macros (thus, basically
 the lambda calculus).

 ```lisp
 (lambda (var1 var2) exp) ; λ-abstraction
 (foo bar baz) ; procedure application
 var ; variable reference
 (list x y z) ; list
 t, nil ; boolean
 (cond [t1 b1] [t2 b2]) ; conditional
 ```

 The language has very simple semantics. It has three kinds of values
 (closures, lists and booleans), and only a couple reduction rules. The
 evaluation rules are presented as an interpretation function (in Urn,
 not the language itself).

 ```lisp
 (defun interpret (x env)
 (case x
 [(lambda ?params . ?body)
 `(:closure ,params ,body ,(copy env))] ; 1
 [(list . ?xs)
 (map (cut interpret <> env) xs)] ; 2
 [t true] [nil false] ; 3
 [(cond . ?alts) ; 4
 (interpret
 (block (map (lambda (alt)
 (when (interpret (car alt) env)
 (break (cdr alt))))))
 env)]
 [(?fn . ?args)
 (case (eval fn env)
 [(:closure ?params ?body ?cl-env) ; 5
 (map (lambda (a k)
 (.<! cl-env (symbol->string a) (interpret k env)))
 params args)
 (last (map (cut interpret <> env) body))]
 [_ (error! $"not a procedure: ${fn}")])]
 [else (.> env (symbol->string x))]))
 ```

 1. In the case the expression currently being evaluated is a lambda, we
 make a copy of the current environment and store it in a _closure_.
 2. If a list is being evaluated, we recursively evaluate each
 sub-expression and store all of them in a list.
 3. If a boolean is being interpreted, they're mapped to the respective
 values in the host language.
 4. If a conditional is being evaluated, each test is performed in order,
 and we abort to interpret with the corresponding body.
 5. When evaluating a procedure application, the procedure to apply is
 inspected: If it is a closure, we evaluate all the arguments, bind
 them along with the closure environment, and interpret the body. If
 not, an error is thrown.

 Collecting constraints in a language as simple as this is fairly easy,
 so here's an implementation.

 ```lisp
 (defun collect-constraints (expr (constrs '()))
 (case expr
 [(lambda ?params . ?body)
 `(:constraints (lambda ,params
 ,@(map (cut collect-constraints <> constrs) body))
 ,constrs)]
 ```

 Lambda expressions incur no additional constraints, so the inner
 expressions (namely, the body) receive the old set.
 The same is true for lists:

 ```lisp
 [(list . ?xs)
 `(:constraints (list ,@(map (cut collect-constraints <> constrs) xs))
 ,constrs)]
 ```

 Booleans are simpler:

 ```lisp
 [t `(:constraints ,'t ,constrs)]
 [nil `(:constraints ,'nil ,constrs)]
 ```

 Since there are no sub-expressions to go through, we only associate the
 constraints with the boolean values.

 Conditionals are where the real work happens. For each case, we add that
 case's test as a constraint in its body.

 ```lisp
 [(cond . ?alts)
 `(:constraints
 (cond
 ,@(map (lambda (x)
 `(,(collect-constraints (car x) constrs)
 ,(collect-constraints (cadr x) (cons (car x) constrs))))
 alts))
 ,constrs)]
 ```

 Applications are as simple as lists. Note that we make no distinction
 between valid applications and invalid ones, and just tag both.

 ```lisp
 [(?fn . ?args)
 `(:constraints
 (,(collect-constraints fn constrs)
 ,@(map (cut collect-constraints <> constrs)
 args))
 ,constrs)]
 ```

 References are also straightforward:

 ```lisp
 [else `(:constraints ,expr ,constrs)]))
 ```

 That's it! Now, this information can be exploited to select a case
 branch at compile time, and eliminate the overhead of performing the
 test again.

 This is _really_ easy to do in a compiler that already has constant
 folding of alternatives. All we have to do is associate constraints to
 truthy values. For instance:

 ```lisp
 (defun fold-on-constraints (x)
 (case x
 [((:constraints ?e ?x)
 :when (known? e x))
 't]
 [else x]))
 ```

 That's it! We check if the expression is in the set of known
 constraints, and if so, reduce it to true. Then, the constant folding
 code will take care of eliminating the redundant branches.

 ### When

 This is a really complicated question. The Urn core language,
 unfortunately, is a tad more complicated, as is the existing optimiser.
 Collecting constraints and eliminating tests would be in completely
 different parts of the compiler.

 There is also a series of code motions that need to be in place for
 constraints to be propagated optimally, especially when panic edges are
 involved. Fortunately, these are all simple to implement, but it's still
 a whole lot of work.

 I don't feel confident setting a specific timeframe for this, but
 I _will_ post more blags on this topic. It's fascinating (for me, at
 least) and will hopefully make the compiler faster!

 [^mr]: The relevant merge request can be found
 [here](https://gitlab.com/urn/urn/issues/27).

--- a/pages/posts/2017-08-15-multimethods.md
+++ b/pages/posts/2017-08-15-multimethods.md
@ -0,0 +1,280 @@
 ---
 title: Multimethods in Urn
 date: August 15, 2017
 ---

 `multimethod`, noun. A procedure which decides runtime behaviour based
 on the types of its arguments.

 ### Introduction

 At some point, most programming language designers realise that they've
 outgrown the language's original feature set and must somehow expand it.
 Sometimes, this expansion is painless for example, if the language had
 already features in place to facilitate this, such as type classes or
 message passing.

 In our case, however, we had to decide on and implement a performant
 system for extensibility in the standard library, from scratch. For
 a while, Urn was using Lua's scheme for modifying the behaviour of
 standard library functions: metamethods in metatables. For the
 uninitiated, Lua tables can have _meta_-tables attached to modify their
 behaviour with respect to several language features. As an example, the
 metamethod `__add`{.lua} controls how Lua will add two tables.

 However, this was not satisfactory, the most important reason as to why
 being the fact that metamethods are associated with particular object
 _instances_, instead of being associated with the _types_ themselves.
 This meant that all the operations you'd like to modify had to be
 modified in one big go - inside the constructor. Consider the
 constructor for hash-sets as it was implemented before the addition of
 multimethods.

 ```lisp
 (defun make-set (hash-function)
 (let* [(hash (or hash-function id))]
 (setmetatable
 { :tag "set"
 :hash hash
 :data {} }
 { :--pretty-print
 (lambda (x)
 (.. "«hash-set: " (concat (map pretty (set->list x)) " ") "»"))
 :--compare #| elided for brevity |# })))
 ```

 That second table, the meta table, is entirely noise. The fact that
 constructors also had to specify behaviour, instead of just data, was
 annoying from a code style point of view and _terrible_ from a reuse
 point of view. Behaviour is closely tied to the implementation - remember
 that metamethods are tied to the _instance_. To extend the behaviour of
 standard library functions (which you can't redefine) for a type you do
 not control (whose constructor you also can not override), you suddenly
 need to wrap the constructor and add your own metamethods.

 ### Finding a Solution

 Displeased with the situation as it stood, I set out to discover what
 other Lisps did, and it seemed like the consensus solution was to
 implement open multimethods. And so we did.

 Multimethods - or multiple dispatch in general - is one of the best
 solutions to the expression problem. We can easily add new types, and
 new operations to work on existing types - and most importantly, this
 means touching _no_ existing code.

 Our implementation is, like almost everything in Urn, a combination of
 clever (ab)use of macros, tables and functions. A method is represented
 as a table - more specifically, a n-ary tree of possible cases, with
 a metamethod, `__call`{.lua}, which means multimethods can be called and
 passed around like regular functions - they are first-order.

 Upon calling a multimethod, it'll look up the correct method body to
 call for the given arguments - or the default method, or throw an error,
 if no default method is provided - and tail-call that, with all the
 arguments.

 Before diving into the ridiculously simple implementation, let's look at
 a handful of examples.

 #### Pretty printing

 Pretty printing is, quite possibly, the simplest application of multiple
 dispatch to extensibility. As of
 [`ba289d2d`](https://gitlab.com/urn/urn/commit/ba829d2de30e3b1bef4fa1a22a5e4bbdf243426b),
 the standard library implementation of `pretty` is a multimethod.

 Before, the implementation[^1] would perform a series of type tests and
 decide on the behaviour, including testing if the given object had
 a metatable which overrides the pretty-printing behaviour.

 The new implementation is _significantly_ shorter, so much so that I'm
 comfortable pasting it here.

 ```lisp
 (defgeneric pretty (x)
 "Pretty-print a value.")
 ```

 That's it! All of the logic that used to exist is now provided by the
 `defgeneric` macro, and adding support for your types is as simple as
 using `defmethod`.[^2]

 ```lisp
 (defmethod (pretty string) (x)
 (format "%q" x))
 ```

 As another example, let's define - and assume the following are separate
 modules - a new type, and add pretty printing support for that.

 ```lisp
 ; Module A - A box.
 (defun box (x)
 { :tag "box"
 :value x })
 ```

 The Urn function `type` will look for a `tag` element in tables and
 report that as the type if it is present, and that function is what the
 multimethod infrastructure uses to determine the correct body to call.
 This means that all we need to do if we want to add support for
 pretty-printing boxes is use defmethod again!

 ```lisp
 (defmethod (pretty box) (x) "🎁")
 ```

 #### Comparison

 A more complicated application of multiple dispatch for extensibility is
 the implementation of the `eq?` method in the standard library.
 Before[^3], based on a series of conditionals, the equality test was
 chosen at runtime. 
 Anyone with experience optimising code is wincing at the mere thought of
 this code.

 The new implementation of `eq?` is also comically short - a mere 2 lines
 for the definition, and only a handful of lines for all the previously
 existing cases.

 ```lisp
 (defgeneric eq? (x y)
 "Compare values for equality deeply.")

 (defmethod (eq? symbol symbol) (x y)
 (= (get-idx x :contents) (get-idx y :contents)))
 (defmethod (eq? string symbol) (x y) (= x (get-idx y :contents)))
 (defmethod (eq? symbol string) (x y) (= (get-idx x :contents) y))
 ```

 If we would, as an example, add support for comparing boxes, the
 implementation would similarly be short.

 ```lisp
 (defmethod (eq? box box) (x y)
 (= (.> x :value) (.> y :value)))
 ```

 ### Implementation

 `defgeneric` and `defmethod` are, quite clearly, macros. However,
 contrary to what one would expect, both their implementations are
 _quite_ simple.

 ```lisp
 (defmacro defgeneric (name ll &attrs)
 (let* [(this (gensym 'this))
 (method (gensym 'method))]
 `(define ,name
 ,@attrs
 (setmetatable
 { :lookup {} }
 { :__call (lambda (,this ,@ll)
 (let* [(,method (deep-get ,this :lookup ,@(map (lambda (x)
 `(type ,x)) ll)))]
 (unless ,method
 (if (get-idx ,this :default)
 (set! ,method (get-idx ,this :default))
 (error "elided for brevity")))
 (,method ,@ll))) }))))
 ```

 Everything `defgeneric` has to do is define a top-level symbol to hold
 the multimethod table, and generate, at compile time, a lookup function
 specialised for the correct number of arguments. In a language without
 macros, multimethod calls would have to - at runtime - loop over the
 provided arguments, take their types, and access the correct elements in
 the table.

 As an example of how generating the lookup function at compile time is
 better for performance, consider the (cleaned up[^4]) lookup function
 generated for the `(eq?)` method defined above.

 ```lua
 function(this, x, y)
 local method
 if this.lookup then
 local temp1 = this.lookup[type(x)]
 if temp1 then
 method = temp1[type(y)] or nil
 else
 method = nil
 end
 elseif this.default then
 method = this.default
 end
 if not method then
 error("No matching method to call for...")
 end
 return method(x, y)
 end
 ```

 `defmethod` and `defdefault` are very simple and uninteresting macros:
 All they do is wrap the provided body in a lambda expression along with
 the proper argument list and associate them to the correct element in
 the tree.

 ```lisp
 (defmacro defmethod (name ll &body)
 `(put! ,(car name) (list :lookup ,@(map s->s (cdr name)))
 (let* [(,'myself nil)]
 (set! ,'myself (lambda ,ll ,@body))
 ,'myself)))
 ```

 ### Conclusion

 Switching to methods instead of a big if-else chain improved compiler
 performance by 12% under LuaJIT, and 2% under PUC Lua. The performace
 increase under LuaJIT can be attributed to the use of polymorphic inline
 caches to speed up dispatch, which is now just a handful of table
 accesses - Doing it with the if-else chain is _much_ harder.

 Defining complex multiple-dispatch methods used to be an unthinkable
 hassle what with keeping straight which cases have been defined yet and
 which cases haven't, but they're now very simple to define: Just state
 out the number of arguments and list all possible cases.

 The fact that multimethods are _open_ means that new cases can be added
 on the fly, at runtime (though this is not officially supported, and we
 don't claim responsibility if you shoot your own foot), and that modules
 loaded later may improve upon the behaviour of modules loaded earlier.
 This means less coupling between the standard library, which has been
 growing to be quite large.

 This change has, in my opinion, made Urn a lot more expressive as
 a language, and I'd like to take a minute to point out the power of the
 Lisp family in adding complicated features such as these as merely
 library code: no changes were made to the compiler, apart from a tiny
 one regarding environments in the REPL - previously, it'd use the
 compiler's version of `(pretty)` even if the user had overridden it,
 which wasn't a problem with the metatable approach, but definitely is
 with the multimethod approach.

 Of course, no solution is all _good_. Compiled code size has increased
 a fair bit, and for the Urn compiler to inline across multimethod
 boundaries would be incredibly difficult - These functions are
 essentially opaque boxes to the compiler.

 Dead code elimination is harder, what with defining functions now being
 a side-effect to be performed at runtime - Telling which method cases
 are or aren't used is incredibly difficult with the extent of the
 dynamicity.

 [^1]:
 [Here](https://gitlab.com/urn/urn/blob/e1e9777498e1a7d690e3b39c56f616501646b5da/lib/base.lisp#L243-270).
 Do keep in mind that the implementation is _quite_ hairy, and grew to be
 like that because of our lack of a standard way of making functions
 extensible.

 [^2]: `%q` is the format specifier for quoted strings.

 [^3]:
 [Here](https://gitlab.com/urn/urn/blob/e1e9777498e1a7d690e3b39c56f616501646b5da/lib/type.lisp#L116-1420).
 Do keep in mind that that the above warnings apply to this one, too.

 [^4]: [The original generated code](/static/generated_code.lua.html) is
 quite similar, except the generated variable names make it a tad harder
 to read.
--- a/pages/posts/2017-09-08-dependent-types.md
+++ b/pages/posts/2017-09-08-dependent-types.md
@ -0,0 +1,516 @@
 ---
 title: Dependent Types
 date: September 08, 2017
 maths: true
 ---

 Dependent types are pretty cool, yo. This post is a semi-structured
 ramble about [dtt](https://ahti-saarelainen.zgrep.org/git/hydraz/dtt),
 a small dependently-typed "programming language" inspired by Thierry
 Coquand's Calculus of (inductive) Constructions (though, note that the
 _induction_ part is still lacking: There is support for defining
 inductive data types, and destructuring them by pattern matching, but
 since there's no totality checker, recursion is disallowed).

 `dtt` is written in Haskell, and served as a learning experience both in
 type theory and in writing programs using [extensible
 effects](https://hackage.haskell.org/package/freer). I *do* partly regret
 the implementation of effects I chose (the more popular
 [`extensible-effects`](https://hackage.haskell.org/package/extensible-effects)
 did not build on the Nixpkgs channel I had, so I went with `freer`;
 Refactoring between these should be easy enough, but I still haven't
 gotten around to it, yet)

 I originally intended for this post to be a Literate Haskell file,
 interleaving explanation with code. However, for a pet project, `dtt`'s
 code base quickly spiralled out of control, and is now over a thousand
 lines long: It's safe to say I did not expect this one bit.

 ### The language

 `dtt` is a very standard $\lambda_{\prod{}}$ calculus. We have all 4 axes of
 Barendgret's lambda cube, in virtue of having types be first class
 values: Values depending on values (functions), values depending on
 types (polymorphism), types depending on types (type operators), and
 types depending on values (dependent types). This places dtt squarely at
 the top, along with other type theories such as the Calculus of
 Constructions (the theoretical basis for the Coq proof assistant) and TT
 (the type theory behind the Idris programming language).

 The syntax is very simple. We have the standard lambda calculus
 constructs - $\lambda$-abstraction, application and variables - along
 with `let`{.haskell}-bindings, pattern matching `case` expression, and
 the dependent type goodies: $\prod$-abstraction and `Set`{.haskell}.

 _As an aside_, pi types are called as so because the dependent function
 space may (if you follow the "types are sets of values" line of
 thinking) be viewed as the cartesian product of types. Consider a type
 `A`{.haskell} with inhabitants `Foo`{.haskell}, `Bar`{.haskell} and
 a type `B`{.haskell} with inhabitant `Quux`{.haskell}. A dependent
 product $\displaystyle\prod_{(x: \mathtt{A})}\mathtt{B}$, then, has
 inhabitants `(Foo, Quux)`{.haskell} and `(Bar, Quux)`{.haskell}.

 You'll notice that dtt does not have a dedicated arrow type. Indeed, the
 dependent product subsumes both the $\forall$ quantifier of System $F$,
 and the arrow type $\to$ of the simply-typed lambda calculus. Keep this
 in mind: It'll be important later.

 Since dtt's syntax is unified (i.e., there's no stratification of terms
 and types), the language can be - and is - entirely contained in
 a single algebraic data type. All binders are _explicitly typed_, seeing
 as inference for dependent types is undecidable (and, therefore,
 bad).[^1]

 ```haskell
 type Type = Term
 data Term
 = Variable Var
 | Set Int
 | TypeHint Term Type
 | Pi Var Type Type
 | Lam Var Type Term
 | Let Var Term Term
 | App Term Term
 | Match Term [(Pattern, Term)]
 deriving (Eq, Show, Ord)
 ```

 The `TypeHint`{.haskell} term constructor, not mentioned before, is
 merely a convenience: It allows the programmer to check their
 assumptions and help the type checker by supplying a type (Note that we
 don't assume this type is correct, as you'll see later; It merely helps
 guide inference.)

 Variables aren't merely strings because of the large amount of
 substitutions we have to perform: For this, instead of generating a new
 name, we increment a counter attached to the variable - the pretty
 printer uses the original name to great effect, when unambiguous.

 ```haskell
 data Var
 = Name String
 | Refresh String Int
 | Irrelevant
 deriving (Eq, Show, Ord)
 ```

 The `Irrelevant`{.haskell} variable constructor is used to support $a
 \to b$ as sugar for $\displaystyle\prod_{(x: a)} b$ when $x$ does not
 appear free in $b$. As soon as the type checker encounters an
 `Irrelevant`{.haskell} variable, it is refreshed with a new name.

 `dtt` does not have implicit support (as in Idris), so all parameters,
 including type parameters, must be bound explicitly. For this, we
 support several kinds of syntatic sugar. First, all abstractions support
 multiple variables in a _binding group_. This allows the programmer to
 write `(a, b, c : α) -> β` instead of `(a : α) -> (b : α) -> (c : α) ->
 β`. Furthermore, there is special syntax `/\a` for single-parameter
 abstraction with type `Set 0`{.haskell}, and lambda abstractions support
 multiple binding groups.

 As mentioned before, the language does not support recursion (either
 general or well-founded). Though I would like to, writing a totality
 checker is hard - way harder than type checking $\lambda_{\prod{}}$, in
 fact. However, an alternative way of inspecting inductive values _does_
 exist: eliminators. These are dependent versions of catamorphisms, and
 basically encode a proof by induction. An inductive data type as Nat
 gives rise to an eliminator much like it gives rise to a natural
 catamorphism.

 ```
 inductive Nat : Type of {
 Z : Nat;
 S : Nat -> Nat
 }

 natElim : (P : Nat -> Type)
 -> P Z
 -> ((k : Nat) -> P k -> P (S k))
 -> (n : Nat)
 -> P n
 ```

 If you squint, you'll see that the eliminator models a proof by
 induction (of the proposition $P$) on the natural number $n$: The type
 signature basically states "Given a proposition $P$ on $\mathbb{N}$,
 a proof of $P_0$, a proof that $P_{(k + 1)}$ follows from $P_k$ and
 a natural number $n$, I'll give you a proof of $P_n$."

 This understanding of computations as proofs and types as propositions,
 by the way, is called the [Curry-Howard
 Isomorphism](https://en.wikipedia.org/wiki/Curry-Howard_correspondence).
 The regular, simply-typed lambda calculus corresponds to natural
 deduction, while $\lambda_{\prod{}}$ corresponds to predicate logic.

 ### The type system

 Should this be called the term system?

 Our type inference algorithm, contrary to what you might expect for such
 a complicated system, is actually quite simple. Unfortunately, the code
 isn't, and thus isn't reproduced in its entirety below.

 #### Variables

 The simplest case in any type system. The typing judgement that gives
 rise to this case is pretty much the identity: $\Gamma \vdash \alpha:
 \tau \therefore \Gamma \vdash \alpha: \tau$. If, from the current typing
 context we know that $\alpha$ has type $\tau$, then we know that
 $\alpha$ has type $\tau$.

 ```haskell
 Variable x -> do
 ty <- lookupType x -- (I)
 case ty of
 Just t -> pure t -- (II)
 Nothing -> throwError (NotFound x) -- (III)
 ```

 1. Look up the type of the variable in the current context.
 2. If we found a type for it, then return that (this is the happy path)
 3. If we didn't find a type for it, we raise a type error.

 #### `Set`{.haskell}s

 Since dtt has a cummulative hierarchy of universes, $\mathtt{Set}_k:
 \mathtt{Set}_{(k + 1)}$. This helps us avoid the logical inconsistency
 introduced by having _type-in-type_[^2], i.e. $\mathtt{Type}:
 \mathtt{Type}$. We say that $\mathtt{Set}_0$ is the type of _small
 types_: in fact, $\mathtt{Set}_0$ is where most computation actually
 happens, seeing as $\mathtt{Set}_k$ for $k \ge 1$ is reserved for
 $\prod$-abstractions quantifying over such types.

 ```haskell
 Set k -> pure . Set . (+1) $ k
 ```

 #### Type hints

 Type hints are the first appearance of the unification engine, by far
 the most complex part of dtt's type checker. But for now, suffices to
 know that ``t1 `assertEquality` t2``{.haskell} errors if the types t1
 and t2 can't be made to _line up_, i.e., unify.

 For type hints, we infer the type of given expression, and compare it
 against the user-provided type, raising an error if they don't match.
 Because of how the unification engine works, the given type may be more
 general (or specific) than the inferred one.

 ```haskell
 TypeHint v t -> do
 it <- infer v
 t `assertEquality` it
 pure t
 ```

 #### $\prod$-abstractions

 This is where it starts to get interesting. First, we mandate that the
 parameter type is inhabited (basically, that it _is_, in fact, a type).
 The dependent product $\displaystyle\prod_{(x : 0)} \alpha$, while allowed by the
 language's grammar, is entirely meaningless: There's no way to construct
 an inhabitant of $0$, and thus this function may never be applied.

 Then, in the context extended with $(\alpha : \tau)$, we require that
 the consequent is also a type itself: The function
 $\displaystyle\prod_{(x: \mathbb{N})} 0$, while again a valid parse, is
 also meaningless.

 The type of the overall abstraction is, then, the maximum value of the
 indices of the universes of the parameter and the consequent.

 ```haskell
 Pi x p c -> do
 k1 <- inferSet tx
 k2 <- local (insertType (x, p)) $
 inferSet c
 pure $ Set (k1 `max` k2)
 ```

 #### $\lambda$-abstractions

 Much like in the simply-typed lambda calculus, the type of
 a $\lambda$-abstraction is an arrow between the type of its parameter
 and the type of its body. Of course, $\lambda_{\prod{}}$ incurs the
 additional constraint that the type of the parameter is inhabited.

 Alas, we don't have arrows. So, we "lift" the lambda's parameter to the
 type level, and bind it in a $\prod$-abstraction.

 ```haskell
 Lam x t b -> do
 _ <- inferSet t
 Pi x t <$> local (insertType (x, t)) (infer b)
 ```

 Note that, much like in the `Pi`{.haskell} case, we type-check the body
 in a context extended with the parameter's type.

 #### Application

 Application is the most interesting rule, as it has to not only handle
 inference, it also has to handle instantiation of $\prod$-abstractions.

 Instantation is, much like application, handled by $\beta$-reduction,
 with the difference being that instantiation happens during type
 checking (applying a $\prod$-abstraction is meaningless) and application
 happens during normalisation (instancing a $\lambda$-abstraction is
 meaningless).

 The type of the function being applied needs to be
 a $\prod$-abstraction, while the type of the operand needs to be
 inhabited. Note that the second constraint is not written out
 explicitly: It's handled by the `Pi`{.haskell} case above, and
 furthermore by the unification engine.

 ```haskell
 App e1 e2 -> do
 t1 <- infer e1
 case t1 of
 Pi vr i o -> do
 t2 <- infer e2
 t `assertEquality` i
 N.normalise =<< subst [(vr, e2)] o -- (I)
 e -> throwError (ExpectedPi e) -- (II)
 ```

 1. Notice that, here, we don't substitute the $\prod$-bound variable by
 the type of $e_2$: That'd make us equivalent to System $F$. The whole
 _deal_ with dependent types is that types depend on values, and that
 entirely stems from this one line. By instancing a type variable with
 a value, we allow _types_ to depend on _values_.

 2. Oh, and if we didn't get a $\prod$-abstraction, error.

 ---

 You'll notice that two typing rules are missing here: One for handling
 `let`{.haskell}s, which was not included because it is entirely
 uninteresting, and one for `case ... of`{.haskell} expressions, which
 was redacted because it is entirely a mess.

 Hopefully, in the future, the typing of `case` expressions is simpler
 - if not, they'll probably be replaced by eliminators.

 ### Unification and Constraint Solving

 The unification engine is the man behind the curtain in type checking:
 We often don't pay attention to it, but it's the driving force behind it
 all. Fortunately, in our case, unification is entirely trivial: Solving
 is the hard bit.

 The job of the unification engine is to produce a set of constraints
 that have to be satisfied in order for two types to be equal. Then, the
 solver is run on these constraints to assert that they are logically
 consistent, and potentially produce substitutions that _reify_ those
 constraints. 
 Our solver isn't that cool, though, so it just verifies consitency.

 The kinds of constraints we can generate are as in the data type below.

 ```haskell
 data Constraint
 = Instance Var Term -- (1)
 | Equal Term Term -- (2)
 | EqualTypes Type Type -- (3)
 | IsSet Type -- (4)
 deriving (Eq, Show, Ord)
 ```

 1. The constraint `Instance v t`{.haskell} corresponds to a substitution
 between `v` and the term `t`.
 2. A constraint `Equal a b`{.haskell} states that the two terms `a` and
 `b` are equal under normalisation.
 3. Ditto, but with their _types_ (We normalise, infer, and check for
 equality)
 4. A constraint `IsSet t`{.haskell} asserts that the provided type has
 inhabitants.

 #### Unification

 Unification of most terms is entirely uninteresting. Simply line up the
 structures and produce the appropriate equality (or instance)
 constraints.

 ```haskell
 unify (Variable a) b = instanceC a b
 unify b (Variable a) = instanceC a b
 unify (Set a) (Set b) | a == b = pure []
 unify (App x y) (App x' y') =
 (++) <$> unify x x' <*> unify y y'
 unify (TypeHint a b) (TypeHint c d) = 
 (++) <$> unify a c <*> unify b d
 unify a b = throwError (NotEqual a b)
 ```

 Those are all the boring cases, and I'm not going to comment on them.
 Similarly boring are binders, which were abstracted out because hlint
 told me to.

 ```haskell
 unify (Lam v1 t1 b1) (Lam v2 t2 b2) = unifyBinder (v1, v2) (t1, t2) (b1, b2)
 unify (Pi v1 t1 b1) (Pi v2 t2 b2) = unifyBinder (v1, v2) (t1, t2) (b1, b2)
 unify (Let v1 t1 b1) (Let v2 t2 b2) = unifyBinder (v1, v2) (t1, t2) (b1, b2)
 unifyBinder (v1, v2) (t1, t2) (b1, b2) = do
 (a, b) <- (,) <$> unify (Variable v1) (Variable v2) <*> unify t1 t2
 ((a ++ b) ++) <$> unify b1 b2
 ```

 There are two interesting cases: Unification between some term and a pi
 abstraction, and unification between two variables.

 ```haskell
 unify ta@(Variable a) tb@(Variable b)
 | a == b = pure []
 | otherwise = do
 (x, y) <- (,) <$> lookupType a <*> lookupType b
 case (x, y) of
 (Just _, Just _) -> do
 ca <- equalTypesC ta tb
 cb <- equalC ta tb
 pure (ca ++ cb)
 (Just x', Nothing) -> instanceC b x'
 (Nothing, Just x') -> instanceC a x'
 (Nothing, Nothing) -> instanceC a (Variable b)
 ```

 If the variables are syntactically the same, then we're done, and no
 constraints have to be generated (Technically you could generate an
 entirely trivial equality constraint, but this puts unnecessary pressure
 on the solver).

 If either variable has a known type, then we generate an instance
 constraint between the unknown variable and the known one.

 If both variables have a value, we equate their types' types and their
 types. This is done mostly for error messages' sakes, seeing as if two
 values are propositionally equal, so are their types.

 Unification between a term and a $\prod$-abstraction is the most
 interesting case: We check that the $\prod$ type abstracts over a type
 (i.e., it corresponds to a System F $\forall$ instead of a System
 F $\to$), and _instance_ the $\prod$ with a fresh type variable.

 ```haskell
 unifyPi v1 t1 b1 a = do
 id <- refresh Irrelevant
 ss <- isSetC t1
 pi' <- subst [(v1, Variable id)] b1
 (++ ss) <$> unify a pi'

 unify a (Pi v1 t1 b1) = unifyPi v1 t1 b1 a
 unify (Pi v1 t1 b1) a = unifyPi v1 t1 b1 a
 ```

 #### Solving

 Solving is a recursive function of the list of constraints (a
 catamorphism!) with some additional state: Namely, a strict map of
 already-performed substitutions. Let's work through the cases in reverse
 order of complexity (and, interestingly, reverse order of how they're in
 the source code).

 ##### No constraints

 Solving an empty list of constraints is entirely trivial.

 ```haskell
 solveInner _ [] = pure ()
 ```

 #### `IsSet`{.haskell}

 We infer the index of the universe of the given type, much like in the
 inferrence case for $\prod$-abstractions, and check the remaining
 constraints.

 ```haskell
 solveInner map (IsSet t:xs) = do
 _ <- inferSet t
 solveInner map xs
 ```

 #### `EqualTypes`{.haskell}

 We infer the types of both provided values, and generate an equality
 constraint.

 ```haskell
 solveInner map (EqualTypes a b:xs) = do
 ta <- infer a
 tb <- infer b
 solveInner map (Equal ta tb:xs)
 ```

 #### `Equal`{.haskell}

 We merely have to check for syntactic equality of the (normal forms of)
 terms, because the hard lifting of destructuring and lining up was done
 by the unification engine.

 ```haskell
 solveInner map (Equal a b:xs) = do
 a' <- N.normalise a
 b' <- N.normalise b
 eq <- equal a' b'
 if eq
 then solveInner map xs
 else throwError (NotEqual a b)
 ```

 #### `Instance`{.haskell}

 If the variable we're instancing is already in the map, and the thing
 we're instancing it to _now_ is not the same as before, we have an
 inconsistent set of substitutions and must error.

 ```haskell
 solveInner map (Instance a b:xs)
 | a `M.member` map
 , b /= map M.! a
 , Irrelevant /= a
 = throwError $ InconsistentSubsts (a, b) (map M.! a)
 ```

 Otherwise, if we have a coherent set of instances, we add the instance
 both to scope and to our local state map and continue checking.

 ```haskell
 | otherwise =
 local (insertType (a, b)) $
 solveInner (M.insert a b map) xs
 ```

 ---

 Now that we have both `unify` and `solve`, we can write
 `assertEquality`: We unify the two types, and then try to solve the set
 of constraints.

 ```haskell
 assertEquality t1 t2 = do
 cs <- unify t1 t2
 solve cs
 ```

 The real implementation will catch and re-throw any errors raised by
 `solve` to add appropriate context, and that's not the only case where
 "real implementation" and "blag implementation" differ.

 ### Conclusion

 Wow, that was a lot of writing. This conclusion begins on exactly the
 500th line of the Markdown source of this article, and this is the
 longest article on this blag (by far). However, that's not to say it's
 bad: It was amazing to write, and writing `dtt` was also amazing. I am
 not good at conclusions.

 `dtt` is available under the BSD 3-clause licence, though I must warn
 you that the source code hasn't many comments.

 I hope you learned nearly as much as I did writing this by reading it.

 [^1]: As [proven](https://link.springer.com/chapter/10.1007/BFb0037103) by Gilles Dowek.
 [^2]: See [System U](https://en.wikipedia.org/wiki/System_U), also
 Girard's paradox - the type theory equivalent of [Russell's
 paradox](https://en.wikipedia.org/wiki/Russell%27s_paradox).
--- a/pages/posts/2018-01-18-amulet.md
+++ b/pages/posts/2018-01-18-amulet.md
@ -0,0 +1,456 @@
 ---
 title: The Amulet Programming Language
 date: January 18, 2018
 ---

 As you might have noticed, I like designing and implementing programming
 languages. This is another of these projects. Amulet is a
 strictly-evaluated, statically typed impure roughly functional
 programming language with support for parametric data types and rank-1
 polymorphism _à la_ Hindley-Milner (but [no
 let-generalization](#letgen)), along with row-polymorphic records. While
 syntactically inspired by the ML family, it's a disservice to those
 languages to group Amulet with them, mostly because of the (present)
 lack of modules.

 Planned features (that I haven't even started working on, as of writing
 this post) include generalized algebraic data types, modules and modular
 implicits, a reworked type inference engine based on _OutsideIn(X)_[^4]
 to support the other features, and, perhaps most importantly, a back-end
 that's not a placeholder (i.e. something that generates either C or LLVM
 and can be compiled to a standalone executable).

 The compiler is still very much a work in progress, and is actively
 being improved in several ways: Rewriting the parser for efficiency
 concerns (see [Lexing and Parsing](#parser)), improving the quality of
 generated code by introducing more intermediate representations, and
 introducing several optimisations on the one intermediate language we
 _do_ have.

 ## The Technical Bits

 In this section, I'm going to describe the implementation of the
 compiler as it exists at the time of writing - warts and all.
 Unfortunately, we have a bit too much code for all of it to fit in this
 blag post, so I'm only going to include the horribly broken bits here,
 and leave the rest out. Of course, the compiler is open source, and is
 available on my [GitHub][2].

 ### Lexing and Parsing {#parser}

 To call what we have a _lexer_ is a bit of an overstatement: The
 `Parser.Lexer` module, which underpins the actual parser, contains only
 a handful of imports and some definitions for use with [Parsec's][3]
 [`Text.Parsec.Token`][4] module; Everything else is boilerplate, namely,
 declaring, at top-level, the functions generated by `makeTokenParser`.

 Our parser is then built on top of this infrastructure (and the other
 combinators provided by Parsec) in a monadic style. Despite having
 chosen to use strict `Text`s, many of the Parsec combinators return
 `Char`s, and using the Alternative type class' ability to repeat actions
 makes linked lists of these - the dreaded `String` type. Due to this,
 and other inefficiencies, the parser is ridiculously bad at memory
 management.

 However, it does have some cute hacks. For example, the pattern parser
 has to account for being used in the parsing of both `match`{.ml} and
 `fun`{.ml} - in the former, destructuring patterns may appear without
 parenthesis, but in the latter, they _must_ be properly parenthesised:
 since `fun`{.ml} may have multiple patterns, it would be ambiguous if
 `fun Foo x -> ...`{.ml} is destructuring a `Foo` or takes two arguments.

 Instead of duplicating the pattern parser, one for `match`{.ml}es and
 one for function arguments, we instead _parametrised_ the parser over
 needing parenthesis or not by adding a rank-2 polymorphic continuation
 argument.

 ```haskell
 patternP :: (forall a. Parser a -> Parser a) -> Parser Pattern'
 patternP cont = wildcard <|> {- some bits omitted -} try destructure where
 destructure = withPos . cont $ do
 ps <- constrName
 Destructure ps <$> optionMaybe (patternP id)
 ```

 When we're parsing a pattern `match`{.ml}-style, the continuation given
 is `id`, and when we're parsing an argument, the continuation is
 `parens`.

 For the aforementioned efficiency concerns, however, we've decided to
 scrap the Parsec-based parser and move to an Alex/Happy based solution,
 which is not only going to be more maintainable and more easily hackable
 in the future, but will also be more efficient overall. Of course, for
 a toy compiler such as this one, efficiency doesn't matter that much,
 but using _one and a half gigabytes_ to compile a 20-line file is really
 bad.

 ### Renaming {#renamer}

 To simplify scope handling in both the type checker and optimiser, after
 parsing, each variable is tagged with a globally unique integer that is
 enough to compare variables. This also lets us use more efficient data
 structures later in the compiler, such as `VarSet`, which stores only the
 integer identifier of a variable in a big-endian Patricia tree[^1].

 Our approach, described in _[Secrets of the Glasgow Haskell Compiler
 inliner][5]_ as "the Sledgehammer", consists of duplicating _every_
 bound variable to avoid name capture problems. However, while the first
 of the listed disadvantages surely does apply, by doing all of the
 _renaming_ in one go, we mostly avoid the latter. Of course, since then,
 the Haskell ecosystem has evolved significantly, and the plumbing
 required is a lot less intrusive.

 In our compiler, we use MTL-style classes instead of concrete monad
 transformer stacks. We also run every phase after parsing in a single
 `GenT`{.haskell} monad, which provides a fresh supply of integers for
 names. "Plumbing" the fresh name supply, then, only involves adding a
 `MonadGen Int m` constraint to the context of functions that need it.

 Since the string component of parsed names is not thrown away, we also
 have to make up strings themselves. This is where another cute hack
 comes in: We generate, lazily, an infinite stream of names that goes
 `["a" .. "z", "aa" .. "az", "ba" .. "bz", ..]`, then use the
 `MonadGen`{.haskell} counter as an index into that stream.

 ```haskell
 alpha :: [Text]
 alpha = map T.pack $ [1..] >>= flip replicateM ['a'..'z']
 ```

 ### Desugaring

 The desugarer is a very simple piece of code which, through use of _Scrap
 Your Boilerplate_-style generic programming, traverses the syntax tree
 and rewrites nodes representing syntax sugar to their more explicit
 versions.

 Currently, the desugarer only expands _sections_: That is, expressions
 of the form `(+ e)` become `fun x -> x + e` (where `e` is a fresh name),
 expressions like `(e +)` become `fun x -> e + x`, and expressions like
 `.foo` becomes `fun x -> x.foo`.

 This is the only component of the compiler that I can reasonably
 include, in its entirety, in this post.

 ```haskell
 desugarProgram = everywhereM (mkM defaults) where
 defaults :: Expr Parsed -> m (Expr Parsed)
 defaults (BothSection op an) = do
 (ap, ar) <- fresh an
 (bp, br) <- fresh an
 pure (Fun ap (Fun bp (BinOp ar op br an) an) an)
 defaults (LeftSection op vl an) = do
 (cap, ref) <- fresh an
 pure (Fun cap (BinOp ref op vl an) an)
 defaults (RightSection op vl an) = do
 (cap, ref) <- fresh an
 pure (Fun cap (BinOp vl op ref an) an)
 defaults (AccessSection key an) = do
 (cap, ref) <- fresh an
 pure (Fun cap (Access ref key an) an)
 defaults x = pure x
 ```

 ### Type Checking

 By far the most complicated stage of the compiler pipeline, our
 inference algorithm is modelled after Algorithm W (extended with kinds
 and kind inference), with constraint generation and solving being two
 separate steps.

 We first traverse the syntax tree, in order, making up constraints and
 fresh type variables as needed, then invoke a unification algorithm to
 produce a substitution, then apply that over both the generated type (a
 skeleton of the actual result) and the syntax tree (which is explicitly
 annotated with types everywhere).

 The type inference code also generates and inserts explicit type
 applications when instancing polymorphic types, since we internally
 lower Amulet into a System F core language with explicit type
 abstraction and application. We have `TypeApp` nodes in the syntax tree
 that never get parsed or renamed, and are generated by the type checker
 before lowering happens.

 Our constraint solver is quite rudimentary, but it does the job nicely.
 We operate with a State monad with the current substitution. When we
 unify a variable with another type, it is added to the current
 substitution. Everything else is just zipping the types together. When
 we try to unify, say, a function type with a constructor, that's an
 error. If a variable has already been added to the current substitution and
 encounter it again, the new type is unified with the previously recorded
 one.

 ```haskell
 unify :: Type Typed -> Type Typed -> SolveM ()
 unify (TyVar a) b = bind a b
 unify a (TyVar b) = bind b a
 unify (TyArr a b) (TyArr a' b') = unify a a' *> unify b b'
 unify (TyApp a b) (TyApp a' b') = unify a a' *> unify b b'
 unify ta@(TyCon a) tb@(TyCon b)
 | a == b = pure ()
 | otherwise = throwError (NotEqual ta tb)
 ```

 This is only an excerpt, because we have very complicated types.

 #### Polymorphic Records

 One of Amulet's selling points (if one could call it that) is its support
 for row-polymorphic records. We have two types of first-class record
 types: _closed_ record types (the type of literals) and _open_ record
 types (the type inferred by record patterns and field getters.). Open
 record types have the shape `{ 'p | x_n : t_n ... x_n : t_n }`{.ml},
 while closed records lack the type variable `'p`{.ml}.

 Unification of records has 3 cases, but in all 3 cases it is checked that
 fields present in both records have unifiable types.

 - When unifying an open record with a closed one, present in both
 records have unifiable types, and instance the type variable to contain
 the extra fields.
 - When unifying two closed records, they must have exactly the same
 shape and unifiable types for common fields.
 - When unifying two open record types, a new fresh type variable is
 created to use as the "hole" and tack the fields together.

 As an example, `{ x = 1 }` has type `{ x : int }`{.ml}, the function
 `fun x -> x.foo` has type `{ 'p | foo : 'a } -> 'a`{.ml}, and
 `(fun r -> r.x) { y = 2 }` is a type error[^2].

 #### No Let Generalisation {#letgen}

 Vytiniotis, Peyton Jones and Schrijvers argue[^5] that HM-style
 `let`{.ml} generalisation interacts badly with complex type system
 extensions such as GADTs and type families, and should therefore be
 omitted from such systems. In a deviation from the paper, GHC 7.2
 reintroduces `let`{.ml} generalisation for local definitions that meet
 some criteria[^3].

 > Here's the rule. With `-XMonoLocalBinds` (the default), a binding
 > without a type signature is **generalised only if all its free variables
 > are closed.** 
 >
 > A binding is **closed** if and only if
 >
 > - It has a type signature, and the type signature has no free variables; or 
 > - It has no type signature, and all its free variables are closed, and it
 is unaffected by the monomorphism restriction. And hence it is fully
 generalised.

 We, however, have chosen to follow that paper to a tee. Despite not
 (yet!) having any of those fancy type system features that interact
 poorly with let generalisation, we do not generalise _any_ local
 bindings.


 ### Lowering

 After type checking is done (and, conveniently, type applications have
 been left in the correct places for us by the type checker), Amulet code
 is converted into an explicitly-typed intermediate representation, in
 direct style, which is used for (local) program optimisation. The AST is
 simplified considerably: from 19 constructors to 9.

 Type inference is no longer needed: the representation of core is packed
 with all the information we need to check that programs are
 type-correct. This includes types in every binder (lambda abstractions,
 `let`{.ml}s, pattern bindings in `match`{.ml}), big-lambda abstractions
 around polymorphic values (a $\lambda$ binds a value, while a $\Lambda$
 binds a type), along with the already mentioned type applications.

 Here, code also gets the error branches for non-exhaustive `match`{.ml}
 expressions, and, as a general rule, gets a lot uglier.

 ```ocaml
 let main _ = (fun r -> r.x) { x = 2 }

 (* Is elaborated into *)

 let main : ∀ 'e. 'e -> int =
 Λe : *. λk : 'e. match k {
 (p : 'e) : 'e -> (λl : { 'g | x : int }. match l {
 (r : { 'g | x : int }) : { 'g | x : int } -> match r {
 { (n : { 'g | x : int }) | x = (m : int) } : { 'g | x : int } -> m
 };
 (o : { 'g | x : int }) : { 'g | x : int } ->
 error @int "<test>[1:15 .. 1:27]"
 }) ({ {} | x : int = 2 });
 (q : 'e) : 'e -> error @int "<test>[1:14 .. 1:38]"
 } 
 ```

 ### Optimisation

 As the code we initially get from lowering is ugly and inefficient -
 along with being full of the abstractions functional programs have by
 nature, it is full of redundant matches created by e.g. the fact that
 functions can not do pattern matching directly, and that field access
 gets reduced to pattern matching - the optimiser's job is to make it
 prettier, and more efficient.

 The optimiser works by applying, in order, a series of local
 transformations operating on individual sub-terms to produce an efficient
 program, 25 times. The idea of applying them several times is that, when
 a simplification pass kicks in, more simplification opportunities might
 arise.

 #### `dropBranches`, `foldExpr`, `dropUselessLets`

 These trivial passes remove similarly trivial pieces of code that only
 add noise to the program. `dropBranches` will do its best to remove
 redundant arms from a `match`{.ml} expression, such as those that
 appear after an irrefutable pattern. `foldExpr` reduces uses of
 operators where both sides are known, e.g. `2 + 2` (replaced by the
 literal `5`) or `"foo " ^ "bar"` (replaced by the literal `"foo
 bar"`). `dropUselessLets` removes `let`{.ml}s that bind unused variables
 whose right-hand sides are pure expressions.

 #### `trivialPropag`, `constrPropag`

 The Amulet optimiser does inlining decisions in two (well, three)
 separate phases: One is called _propagation_, in which a `let` decides
 to propagate its bound values into the expression, and the other is the
 more traditional `inlining`, where variables get their values from the
 context.

 Propagation is by far the easiest of the two: The compiler can see both
 the definitions and all of the use sites, and could in theory decide if
 propagating is beneficial or not. Right now, we propagate all literals
 (and records made up solely of other trivial expressions), and do a
 round of propagation that is best described as a rule.

 ```ocaml
 let { v = C e } in ... v ...
 (* becomes *)
 let { v' = e } in ... C v' ...
 ```

 This _constructor propagation_ allows the `match`{.ml} optimisations to kick
 in more often, and is semantics preserving.

 #### `match`{.ml}-of-known-constructor

 This pass identifies `match`{.ml} expressions where we can statically
 determine the expression being analysed and, therefore, decide which
 branch is going to be taken.

 ```ocaml
 match C x with
 | C e -> ... e ...
 ...
 (* becomes *)
 ... x ...
 ```

 #### `match`{.ml}-of-bottom

 It is always safe to turn a `match`{.ml} where the term being matched is a
 diverging expression into only that diverging expression, thus reducing
 code size several times.

 ```ocaml
 match (error @int "message") with ...
 (* becomes *)
 error @int "message"
 ```

 As a special case, when one of the arms is itself a diverging
 expression, we use the type mentioned in that application to `error` to
 fix up the type of the value being scrutinized.

 ```ocaml
 match (error @foo "message") with
 | _ -> error @bar "message 2"
 ...
 (* becomes *)
 error @bar "message"
 ```

 #### `match`{.ml}-of-`match`{.ml}

 This transformation turns `match`{.ml} expressions where the expression
 being dissected is itself another `match`{.ml} "inside-out": we push the
 branches of the _outer_ `match`{.ml} "into" the _inner_ `match` (what
 used to be the expression being scrutinized). In doing so, sometimes,
 new opportunities for match-of-known-constructor arise, and the code
 ends up simpler.

 ```ocaml
 match (match x with
 | A -> B
 | C -> D) with
 | B -> e
 | D -> f
 (* becomes *)
 match x with
 | A -> match B with
 | B -> e
 | D -> f
 | C -> match D with
 | B -> e
 | D -> f
 ```

 A clear area of improvement here is extracting the outer branches into
 local `let`{.ml}-bound lambda abstractions to avoid an explosion in code
 size.

 #### `inlineVariable`, `betaReduce`

 In this pass, use of a variable is replaced with the definition of that
 variable, if it meets the following conditions:

 - The variable is a lambda abstraction; and
 - The lambda abstraction's body is not too _expensive_. Computing the
 cost of a term boils down to computing the depth of the tree
 representing that term, with some extra cost added to some specific
 types of expression.

 In doing this, however, we end up with pathological terms of the form
 `(fun x -> e) y`{.ml}. The `betaReduce` pass turns this into `let x = y in
 e`{.ml}. We generate `let`{.ml} bindings instead of substituting the
 variable with the parameter to maintain the same evaluation order and
 observable effects of the original code. This does mean that, often,
 propagation kicks in and gives rise to new simplification opportunities.

 ## Epilogue

 I was planning to write a section with a formalisation of the language's
 semantics and type system, but it turns out I'm no mathematician, no
 matter how hard I pretend. Maybe in the future.

 Our code generator is wholly uninteresting, and, most of all, a
 placeholder: This is why it is not described in detail (that is, at all)
 in this post. I plan to write a follow-up when we actually finish the
 native code generator.

 As previously mentioned, the compiler _is_ open source: the code is
 [here][2]. I recommend using the [Nix package manager][9] to acquire the
 Haskell dependencies, but Cabal should work too. Current work in
 rewriting the parser is happening in the `feature/alex-happy` branch.

 [^1]: This sounds fancy, but in practice, it boils down to using
 `Data.IntSet`{.haskell} instead of `Data.Set`{.haskell}.

 [^2]: As shown [here][6]. Yes, the error messages need improvement.

 [^3]: As explained in [this blog post][8].

 [^4]: Dimitrios Vytiniotis, Simon Peyton Jones, Tom Schrijvers,
 and Martin Sulzmann. 2011. [OutsideIn(X): Modular Type Inference With
 Local Assumptions][1]. _Note that, although the paper has been
 published in the Journal of Functional Programming, the version linked
 to here is a preprint._

 [^5]: Dimitrios Vytiniotis, Simon Peyton Jones, Tom Schrijvers. 2010.
 [Let Should not be Generalised][7].

 [1]: <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf>
 [2]: <https://github.com/zardyh/amulet/tree/66a4143af32c3e261af51b74f975fc48c0155dc8>
 [3]: <https://hackage.haskell.org/package/parsec-3.1.11>
 [4]: <https://hackage.haskell.org/package/parsec-3.1.11/docs/Text-Parsec-Token.html>
 [5]: <https://www.microsoft.com/en-us/research/wp-content/uploads/2002/07/inline.pdf>
 [6]: </snip/sel.b0e94.txt>
 [7]: <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tldi10-vytiniotis.pdf>
 [8]: <https://ghc.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7>
 [9]: <https://nixos.org/nix/>
--- a/pages/posts/2018-02-18-amulet-tc2.md
+++ b/pages/posts/2018-02-18-amulet-tc2.md
@ -0,0 +1,609 @@
 ---
 title: Amulet's New Type Checker
 date: February 18, 2018
 ---

 In the last post about Amulet I wrote about rewriting the type checking
 code. And, to everybody's surprise (including myself), I actually did
 it.

 Like all good programming languages, Amulet has a strong, static type
 system. What most other languages do not have, however, is (mostly)
 _full type inference_: programs are still type-checked despite (mostly)
 having no type annotations.

 Unfortunately, no practical type system has truly "full type inference":
 features like data-type declarations, integral to actually writing
 software, mandate some type annotations (in this case, constructor
 arguments). However, that doesn't mean we can't try.

 The new type checker, based on a constraint-generating but
 _bidirectional_ approach, can type a lot more programs than the older,
 Algorithm W-derived, quite buggy checker. As an example, consider the
 following definition. For this to check under the old type system, one
 would need to annotate both arguments to `map` _and_ its return type -
 clearly undesirable!

 ```ocaml
 let map f =
 let go cont xs =
 match xs with
 | Nil -> cont Nil
 | Cons (h, t) -> go (compose cont (fun x -> Cons (f h, x))) t
 in go id ;;
 ```

 Even more egregious is that the η-reduction of `map` would lead to an
 ill-typed program.

 ```ocaml
 let map f xs =
 let go cont xs = (* elided *)
 in go id xs ;;
 (* map : forall 'a 'b. ('a -> 'b) -> list 'a -> list 'b *)

 let map' f =
 let go cont xs = (* elided *)
 in go id ;;
 (* map' : forall 'a 'b 'c. ('a -> 'b) -> list 'a -> list 'c *)
 ```

 Having declared this unacceptable, I set out to rewrite the type
 checker, after months of procrastination. As is the case, of course,
 with such things, it only took some two hours, and I really shouldn't have
 procrastinated it for so long.

 Perhaps more importantly, the new type checker also supports rank-N
 polymorphism directly, with all appropriate checks in place: expressions
 checked against a polymorphic type are, in reality, checked against a
 _deeply skolemised_ version of that poly-type - this lets us enforce two
 key properties:

 1. the expression being checked _is_ actually parametric over the type
 arguments, i.e., it can't unify the skolem constants with any type
 constructors, and
 2. no rank-N arguments escape.

 As an example, consider the following function:

 ```ocaml
 let rankn (f : forall 'a. 'a -> 'a) = f ()
 ```

 Well-typed uses of this function are limited to applying it to the
 identity function, as parametricity tells us; and, indeed, trying to
 apply it to e.g. `fun x -> x + 1`{.ocaml} is a type error.

 ### The Solver

 As before, type checking is done by a traversal of the syntax tree
 which, by use of a `Writer`{.haskell} monad, produces a list of
 constraints to be solved. Note that a _list_ really is needed: a set, or
 similar data structure with unspecified order, will not do. The order in
 which the solver processes constraints is important!

 The support for rank-N types has lead to the solver needing to know
 about a new kind of constraint: _subsumption_ constraints, in addition
 to _unification_ constraints. Subsumption is perhaps too fancy a term,
 used to obscure what's really going on: subtyping. However, whilst
 languages like Java and Scala introduce subtyping by means of
 inheritance, our subtyping boils down to eliminating ∀s.

 ∀s are eliminated from the right-hand-side of subsumption constraints by
 _deep skolemisation_: replacing the quantified variables in the type
 with fresh type constants. The "depth" of skolemisation refers to the
 fact that ∀s to the right of arrows are eliminated along with the ones
 at top-level.

 ```haskell
 subsumes k t1 t2@TyForall{} = do
 t2' <- skolemise t2
 subsumes k t1 t2'
 subsumes k t1@TyForall{} t2 = do
 (_, _, t1') <- instantiate t1
 subsumes k t1' t2
 subsumes k a b = k a b
 ```

 The function for computing subtyping is parametric over what to do in
 the case of two monomorphic types: when this function is actually used
 by the solving algorithm, it's applied to `unify`.

 The unifier has the job of traversing two types in tandem to find the
 _most general unifier_: a substitution that, when applied to one type,
 will make it syntatically equal to the other. In most of the type
 checker, when two types need to be "equal", they're equal up to
 unification.

 Most of the cases are an entirely boring traversal, so here are the
 interesting ones.

 - Skolem type constants only unify with other skolem type constants:
 ```haskell
 unify TySkol{} TySkol{} = pure ()
 unify t@TySkol{} b = throwError $ SkolBinding t b
 unify b t@TySkol{} = throwError $ SkolBinding t b
 ```

 - Type variables extend the substitution:
 ```haskell
 unify (TyVar a) b = bind a b
 unify a (TyVar b) = bind b a
 ```

 - Polymorphic types unify up to α-renaming:
 ```haskell
 unify t@(TyForall vs ty) t'@(TyForall vs' ty')
 | length vs /= length vs' = throwError (NotEqual t t')
 | otherwise = do
 fvs <- replicateM (length vs) freshTV
 let subst = Map.fromList . flip zip fvs
 unify (apply (subst vs) ty) (apply (subst vs') ty')
 ```

 When binding a variable to a concrete type, an _occurs check_ is
 performed to make sure the substitution isn't going to end up containing
 an infinite type. Consider binding `'a := list 'a`: If `'a` is
 substituted for `list 'a` everywhere, the result would be `list (list
 'a)` - but wait, `'a` appears there, so it'd be substituted again, ad
 infinitum.

 Extra care is also needed when binding a variable to itself, as is the
 case with `'a ~ 'a`. These constraints are trivially discharged, but
 adding them to the substitution would mean an infinite loop!

 ```haskell
 occurs :: Var Typed -> Type Typed -> Bool
 occurs _ (TyVar _) = False
 occurs x e = x `Set.member` ftv e
 ```

 If the variable has already been bound, the new type is unified with the
 one present in the substitution being accumulated. Otherwise, it is
 added to the substitution.

 ```haskell
 bind :: Var Typed -> Type Typed -> SolveM ()
 bind var ty
 | occurs var ty = throwError (Occurs var ty)
 | TyVar var == ty = pure ()
 | otherwise = do
 env <- get
 -- Attempt to extend the environment, otherwise
 -- unify with existing type
 case Map.lookup var env of
 Nothing -> put (Map.singleton var (normType ty) `compose` env)
 Just ty'
 | ty' == ty -> pure ()
 | otherwise -> unify (normType ty) (normType ty')
 ```

 Running the solver, then, amounts to folding through the constraints in
 order, applying the substitution created at each step to the remaining
 constraints while also accumulating it to end up at the most general
 unifier.

 ```haskell
 solve :: Int -> Subst Typed
 -> [Constraint Typed]
 -> Either TypeError (Subst Typed)
 solve _ s [] = pure s
 solve i s (ConUnify e a t:xs) = do
 case runSolve i s (unify (normType a) (normType t)) of
 Left err -> Left (ArisingFrom err e)
 Right (i', s') -> solve i' (s' `compose` s) (apply s' xs)
 solve i s (ConSubsume e a b:xs) =
 case runSolve i s (subsumes unify (normType a) (normType b)) of
 Left err -> Left (ArisingFrom err e)
 Right (i', s') -> solve i' (s' `compose` s) (apply s' xs)
 ```

 ### Inferring and Checking Patterns

 Amulet, being a member of the ML family, does most data processing
 through _pattern matching_, and so, the patterns also need to be type
 checked.

 The pattern grammar is simple: it's made up of 6 constructors, while
 expressions are described by over twenty constructors.

 Here, the bidirectional approach to inference starts to shine. It is
 possible to have different behaviours for when the type of the
 pattern (or, at least, some skeleton describing that type) is known
 and for when it is not, and such a type must be produced from the
 pattern alone.

 In an unification-based system like ours, the inference judgement can be
 recovered from the checking judgement by checking against a fresh type
 variable.

 ```haskell
 inferPattern p = do
 x <- freshTV
 (p', binds) <- checkPattern p x
 pure (p', x, binds)
 ```

 Inferring patterns produces three things: an annotated pattern, since
 syntax trees after type checking carry their types; the type of values
 that pattern matches; and a list of variables the pattern binds.
 Checking omits returning the type, and yields only the annotated syntax
 tree and the list of bindings.

 As a special case, inferring patterns with type signatures overrides the
 checking behaviour. The stated type is kind-checked (to verify its
 integrity and to produce an annotated tree), then verified to be a
 subtype of the inferred type for that pattern.

 ```haskell
 inferPattern pat@(PType p t ann) = do
 (p', pt, vs) <- inferPattern p
 (t', _) <- resolveKind t
 _ <- subsumes pat t' pt -- t' ≤ pt
 case p' of
 Capture v _ -> pure (PType p' t' (ann, t'), t', [(v, t')])
 _ -> pure (PType p' t' (ann, t'), t', vs)
 ```

 Checking patterns is where the fun actually happens. Checking `Wildcard`s
 and `Capture`s is pretty much identical, except the latter actually
 expands the capture list.

 ```haskell
 checkPattern (Wildcard ann) ty = pure (Wildcard (ann, ty), [])
 checkPattern (Capture v ann) ty =
 pure (Capture (TvName v) (ann, ty), [(TvName v, ty)])
 ```

 Checking a `Destructure` looks up the type of the constructor in the
 environment, possibly instancing it, and does one of two things,
 depending on whether or not the destructuring did not have an inner
 pattern.

 ```haskell
 checkPattern ex@(Destructure con ps ann) ty =
 case ps of
 ```

 - If there was no inner pattern, then the looked-up type is unified with
 the "goal" type - the one being checked against.

 ```haskell
 Nothing -> do
 pty <- lookupTy con
 _ <- unify ex pty ty
 pure (Destructure (TvName con) Nothing (ann, pty), [])
 ```

 - If there _was_ an inner pattern, we proceed by decomposing the type
 looked up from the environment. The inner pattern is checked against the
 _domain_ of the constructor's type, while the "goal" gets unified with
 the _co-domain_.

 ```haskell
 Just p -> do
 (c, d) <- decompose ex _TyArr =<< lookupTy con
 (ps', b) <- checkPattern p c
 _ <- unify ex ty d
 ```

 Checking tuple patterns is a bit of a mess. This is because of a
 mismatch between how they're written and how they're typed: a 3-tuple
 pattern (and expression!) is written like `(a, b, c)`, but it's _typed_
 like `a * (b * c)`. There is a local helper that incrementally converts
 between the representations by repeatedly decomposing the goal type.

 ```haskell
 checkPattern pt@(PTuple elems ann) ty =
 let go [x] t = (:[]) <$> checkPattern x t
 go (x:xs) t = do
 (left, right) <- decompose pt _TyTuple t
 (:) <$> checkPattern x left <*> go xs right
 go [] _ = error "malformed tuple in checkPattern"
 ```

 Even more fun is the `PTuple` constructor is woefully overloaded: One
 with an empty list of children represents matching against `unit`{.ml}.
 One with a single child is equivalent to the contained pattern; Only one
 with more than two contained patterns makes a proper tuple.

 ```haskell
 in case elems of
 [] -> do
 _ <- unify pt ty tyUnit
 pure (PTuple [] (ann, tyUnit), [])
 [x] -> checkPattern x ty
 xs -> do
 (ps, concat -> binds) <- unzip <$> go xs ty
 pure (PTuple ps (ann, ty), binds)
 ```

 ### Inferring and Checking Expressions

 Expressions are incredibly awful and the bane of my existence. There are
 18 distinct cases of expression to consider, a number which only seems
 to be going up with modules and the like in the pipeline; this
 translates to 24 distinct cases in the type checker to account for all
 of the possibilities.

 As with patterns, expression checking is bidirectional; and, again,
 there are a lot more checking cases then there are inference cases. So,
 let's start with the latter.

 #### Inferring Expressions

 Inferring variable references makes use of instantiation to generate
 fresh type variables for each top-level universal quantifier in the
 type. These fresh variables will then be either bound to something by
 the solver or universally quantified over in case they escape.

 Since Amulet is desugared into a core language resembling predicative
 System F, variable uses also lead to the generation of corresponding
 type applications - one for each eliminated quantified variable.

 ```haskell
 infer expr@(VarRef k a) = do
 (inst, old, new) <- lookupTy' k
 if Map.null inst
 then pure (VarRef (TvName k) (a, new), new)
 else mkTyApps expr inst old new
 ```

 Functions, strangely enough, have both checking _and_ inference
 judgements: which is used impacts what constraints will be generated,
 and that may end up making type inference more efficient (by allocating
 less, or correspondingly spending less time in the solver).

 The pattern inference judgement is used to compute the type and bindings
 of the function's formal parameter, and the body is inferred in the
 context extended with those bindings; Then, a function type is
 assembled.

 ```haskell
 infer (Fun p e an) = do
 (p', dom, ms) <- inferPattern p
 (e', cod) <- extendMany ms $ infer e
 pure (Fun p' e' (an, TyArr dom cod), TyArr dom cod)
 ```

 Literals are pretty self-explanatory: Figuring their types boils down to
 pattern matching.

 ```haskell
 infer (Literal l an) = pure (Literal l (an, ty), ty) where
 ty = case l of
 LiInt{} -> tyInt
 LiStr{} -> tyString
 LiBool{} -> tyBool
 LiUnit{} -> tyUnit
 ```

 The inference judgement for _expressions_ with type signatures is very similar
 to the one for patterns with type signatures: The type is kind-checked,
 then compared against the inferred type for that expression. Since
 expression syntax trees also need to be annotated, they are `correct`ed
 here.

 ```haskell
 infer expr@(Ascription e ty an) = do
 (ty', _) <- resolveKind ty
 (e', et) <- infer e
 _ <- subsumes expr ty' et
 pure (Ascription (correct ty' e') ty' (an, ty'), ty')
 ```

 There is also a judgement for turning checking into inference, again by
 making a fresh type variable.

 ```haskell
 infer ex = do
 x <- freshTV
 ex' <- check ex x
 pure (ex', x)
 ```

 #### Checking Expressions

 Our rule for eliminating ∀s was adapted from the paper [Complete
 and Easy Bidirectional Typechecking for Higher-Rank Polymorphism].
 Unlike in that paper, however, we do not have explicit _existential
 variables_ in contexts, and so must check expressions against
 deeply-skolemised types to eliminate the universal quantifiers.

 [Complete and Easy Bidirectional Typechecking for Higher-Rank
 Polymorphism]: https://www.cl.cam.ac.uk/~nk480/bidir.pdf

 ```haskell
 check e ty@TyForall{} = do
 e' <- check e =<< skolemise ty
 pure (correct ty e')
 ```

 If the expression is checked against a deeply skolemised version of the
 type, however, it will be tagged with that, while it needs to be tagged
 with the universally-quantified type. So, it is `correct`ed.

 Amulet has rudimentary support for _typed holes_, as in dependently
 typed languages and, more recently, GHC. Since printing the type of
 holes during type checking would be entirely uninformative due to
 half-solved types, reporting them is deferred to after checking.

 Of course, holes must still have checking behaviour: They take whatever
 type they're checked against.

 ```haskell
 check (Hole v a) t = pure (Hole (TvName v) (a, t))
 ```

 Checking functions is as easy as inferring them: The goal type is split
 between domain and codomain; the pattern is checked against the domain,
 while the body is checked against the codomain, with the pattern's
 bindings in scope.

 ```haskell
 check ex@(Fun p b a) ty = do
 (dom, cod) <- decompose ex _TyArr ty
 (p', ms) <- checkPattern p dom
 Fun p' <$> extendMany ms (check b cod) <*> pure (a, ty)
 ```

 Empty `begin end` blocks are an error.

 ```
 check ex@(Begin [] _) _ = throwError (EmptyBegin ex)
 ```

 `begin ... end` blocks with at least one expression are checked by
 inferring the types of every expression but the last, and then checking
 the last expression in the block against the goal type.

 ```haskell
 check (Begin xs a) t = do
 let start = init xs
 end = last xs
 start' <- traverse (fmap fst . infer) start
 end' <- check end t
 pure (Begin (start' ++ [end']) (a, t))
 ```

 `let`s are pain. Since all our `let`s are recursive by nature, they must
 be checked, including all the bound variables, in a context where the
 types of every variable bound there are already available; To figure
 this out, however, we first need to infer the type of every variable
 bound there.

 If that strikes you as "painfully recursive", you're right. This is
 where the unification-based nature of our type system saved our butts:
 Each bound variable in the `let` gets a fresh type variable, the context
 is extended and the body checked against the goal.

 The function responsible for inferring and solving the types of
 variables is `inferLetTy`. It keeps an accumulating association list to
 check the types of further bindings as they are figured out, one by one,
 then uses the continuation to generalise (or not) the type.

 ```haskell
 check (Let ns b an) t = do
 ks <- for ns $ \(a, _, _) -> do
 tv <- freshTV
 pure (TvName a, tv)
 extendMany ks $ do
 (ns', ts) <- inferLetTy id ks (reverse ns)
 extendMany ts $ do
 b' <- check b t
 pure (Let ns' b' (an, t))
 ```

 We have decided to take [the advice of Vytiniotis, Peyton Jones, and
 Schrijvers], and refrain from generalising lets, except at top-level.
 This is why `inferLetTy` gets given `id` when checking terms.

 [the advice of Vytiniotis, Peyton Jones, and Schrijvers]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tldi10-vytiniotis.pdf

 The judgement for checking `if` expressions is what made me stick to
 bidirectional type checking instead of fixing out variant of Algorithm
 W. The condition is checked against the boolean type, while both
 branches are checked against the goal.

 ```haskell
 check (If c t e an) ty = If <$> check c tyBool
 <*> check t ty
 <*> check e ty
 <*> pure (an, ty)
 ```


 it is not possible, in general, to recover the type of a function
 at an application site, we infer it; The argument given is checked
 against that function's domain and the codomain is unified with the
 goal type.

 ```haskell
 check ex@(App f x a) ty = do
 (f', (d, c)) <- secondA (decompose ex _TyArr) =<< infer f
 App f' <$> check x d <*> fmap (a,) (unify ex ty c)
 ```

 To check `match`, the type of what's being matched against is first
 inferred because, unlike application where _some_ recovery is possible,
 we can not recover the type of matchees from the type of branches _at
 all_.

 ```haskell
 check (Match t ps a) ty = do
 (t', tt) <- infer t
 ```

 Once we have the type of the matchee in hands, patterns can be checked
 against that. The branches are then each checked against the goal type.

 ```haskell
 ps' <- for ps $ \(p, e) -> do
 (p', ms) <- checkPattern p tt
 (,) <$> pure p' <*> extendMany ms (check e ty)
 ```

 Checking binary operators is like checking function application twice.
 Very boring.

 ```haskell
 check ex@(BinOp l o r a) ty = do
 (o', to) <- infer o
 (el, to') <- decompose ex _TyArr to
 (er, d) <- decompose ex _TyArr to'
 BinOp <$> check l el <*> pure o'
 <*> check r er <*> fmap (a,) (unify ex d ty)
 ```

 Checking records and record extension is a hack, so I'm not going to
 talk about them until I've cleaned them up reasonably in the codebase.
 Record access, however, is very clean: we make up a type for the
 row-polymorphic bit, and check against a record type built from the goal
 and the key.

 ```haskell
 check (Access rc key a) ty = do
 rho <- freshTV
 Access <$> check rc (TyRows rho [(key, ty)])
 <*> pure key <*> pure (a, ty)
 ```

 Checking tuple expressions involves a local helper much like checking
 tuple patterns. The goal type is recursively decomposed and made to line
 with the expression being checked.

 ```haskell
 check ex@(Tuple es an) ty = Tuple <$> go es ty <*> pure (an, ty) where
 go [] _ = error "not a tuple"
 go [x] t = (:[]) <$> check x t
 go (x:xs) t = do
 (left, right) <- decompose ex _TyTuple t
 (:) <$> check x left <*> go xs right
 ```

 And, to finish, we have a judgement for turning inference into checking.

 ```haskell
 check e ty = do
 (e', t) <- infer e
 _ <- subsumes e ty t
 pure e'
 ```

 ### Conclusion

 I like the new type checker: it has many things you'd expect from a
 typed lambda calculus, such as η-contraction preserving typability, and
 substitution of `let`{.ocaml}-bound variables being generally
 admissable.

 Our type system is fairly complex, what with rank-N types and higher
 kinded polymorphism, so inferring programs under it is a bit of a
 challenge. However, I am fairly sure the only place that demands type
 annotations are higher-ranked _parameters_: uses of higher-rank
 functions are checked without the need for annotations.

 Check out [Amulet] the next time you're looking for a typed functional
 programming language that still can't compile to actual executables.

 [Amulet]: https://github.com/zardyh/amulet
--- a/pages/posts/2018-03-14-amulet-safety.md
+++ b/pages/posts/2018-03-14-amulet-safety.md
@ -0,0 +1,286 @@
 ---
 title: Amulet and Language Safety
 date: March 14, 2018
 ---

 Ever since its inception, Amulet has strived to be a language that
 _guarantees_ safety, to some extent, with its strong, static, inferred
 type system. Through polymorphism we gain the concept of
 _parametricity_, as explained in Philip Wadler's [Theorems for Free]: a
 function's behaviour does not depend on the instantiations you perform.

 However, the power-to-weight ratio of these features quickly plummets,
 as every complicated type system extension makes inference rather
 undecidable, which in turn mandates more and more type annotations. Of
 the complex extensions I have read about, three struck me as
 particularly elegant, and I have chosen to implement them all in Amulet:

 - Generalised Algebraic Data Types, which this post is about;
 - Row Polymorphism, which allows being precise about which structure
 fields a function uses; and
 - Rank-N types, which enables the implementation of many concepts
 including monadic regions.

 Both GADTs and rank-N types are in the "high weight" category: inference
 in the presence of both is undecidable. Adding support for the latter
 (which laid the foundations for the former) is what drove me to re-write
 the type checker, a crusade detailed in [my last post].

 Of course, in the grand scheme of things, some languages provide way
 more guarantees than Amulet: For instance, Rust, with its lifetime
 system, can prove that code is memory-safe at compile time;
 Dependently-typed languages such as Agda and Idris can express a lot of
 invariants in their type system, but inference is completely destroyed.
 Picking which features you'd like to support is a game of
 tradeoffs---all of them have benefits, but some have exceedingly high
 costs.

 Amulet was originally based on a very traditional, HM-like type system
 with support for row polymorphism. The addition of rank-N polymorphism
 and GADTs instigated the move to a bidirectional system, which in turn
 provided us with the ability to experiment with a lot more type system
 extensions (for instance, linear types)---in pursuit of more guarantees
 like parametricity.

 GADTs
 =====

 In a sense, generalised ADTs are a "miniature" version of the inductive
 families one would find in dependently-typed programming (and, indeed,
 Amulet can type-check _some_ uses of length-indexed vectors, although
 the lack of type-level computation is a showstopper). They allow
 non-uniformity in the return types of constructors, by packaging
 "coercions" along with the values; pattern matching, then, allows these
 coercions to influence the solving of particular branches.

 Since this is an introduction to indexed types, I am legally obligated
 to present the following three examples: the type of equality witnesses
 between two other types; higher-order abstract syntax, the type of
 well-formed terms in some language; and _vectors_, the type of linked
 lists with statically-known lengths.

 #### Equality

 As is tradition in intuitionistic type theory, we define equality by
 postulating (that is, introducing a _constructor_ witnessing)
 reflexivity: anything is equal to itself. Symmetry and transitivity can
 be defined as ordinary pattern-matching functions. However, this
 demonstrates the first (and main) shortcoming of our implementation:
 Functions which perform pattern matching on generalised constructors
 _must_ have explicitly stated types.[^1]

 ```ocaml
 type eq 'a 'b =
 | Refl : eq 'a 'a ;;

 let sym (Refl : eq 'a 'b) : eq 'b 'a = Refl ;;
 let trans (Refl : eq 'a 'b) (Refl : eq 'b 'c) : eq 'a 'c = Refl ;;
 ```

 Equality, when implemented like this, is conventionally used to
 implement substitution: If there exists a proof that `a` and `b` are
 equal, any `a` may be treated as a `b`.

 ```ocaml
 let subst (Refl : eq 'a 'b) (x : 'a) : 'b = x ;;
 ```

 Despite `a` and `b` being distinct, _rigid_ type variables, matching on
 `Refl` allows the constraint solver to treat them as equal.

 #### Vectors

 ```ocaml
 type z ;; (* the natural zero *)
 type s 'k ;; (* the successor of a number *)
 type vect 'n 'a = (* vectors of length n *)
 | Nil : vect z 'a
 | Cons : 'a * vect 'k 'a -> vect (s 'k) 'a
 ```

 Parametricity can tell us many useful things about functions. For
 instance, all closed, non-looping inhabitants of the type `forall 'a. 'a
 -> 'a` are operationally the identity function. However, expanding the
 type grammar tends to _weaken_ parametricity before making it stronger.
 Consider the type `forall 'a. list 'a -> list 'a`{.ocaml}---it has
 several possible implementations: One could return the list unchanged,
 return the empty list, duplicate every element in the list, drop some
 elements around the middle, among _many_ other possible behaviours.

 Indexed types are beyond the point of weakening parametricity, and start
 to make it strong again. Consider a function of type `forall 'a 'n. ('a
 -> 'a -> ordering) -> vect 'n 'a -> vect 'n 'a`{.ocaml}---by making the
 length of the vector explicit in the type, and requiring it to be kept
 the same, we have ruled out any implementations that drop or duplicate
 elements. A win, for sure, but at what cost? An implementation of
 insertion sort for traditional lists looks like this, when implemented
 in Amulet:

 ```ocaml
 let insert_sort cmp l =
 let insert e tl =
 match tl with
 | Nil -> Cons (e, Nil)
 | Cons (h, t) -> match cmp e h with
 | Lt -> Cons (e, Cons (h, t))
 | Gt -> Cons (h, insert e t)
 | Eq -> Cons (e, Cons (h, t))
 and go l = match l with
 | Nil -> Nil
 | Cons (x, xs) -> insert x (go xs)
 in go l ;;
 ```

 The implementation for vectors, on the other hand, is full of _noise_:
 type signatures which we would rather not write, but are forced to by
 the nature of type systems.

 ```ocaml
 let insert_sort (cmp : 'a -> 'a -> ordering) (v : vect 'n 'a) : vect 'n 'a =
 let insert (e : 'a) (tl : vect 'k 'a) : vect (s 'k) 'a =
 match tl with
 | Nil -> Cons (e, Nil)
 | Cons (h, t) -> match cmp e h with
 | Lt -> Cons (e, Cons (h, t))
 | Gt -> Cons (h, insert e t)
 | Eq -> Cons (e, Cons (h, t))
 and go (v : vect 'k 'a) : vect 'k 'a = match v with
 | Nil -> Nil
 | Cons (x, xs) -> insert x (go xs)
 in go v ;;
 ```

 These are not quite theorems for free, but they are theorems for quite
 cheap.

 #### Well-Typed Terms

 ```ocaml
 type term 'a =
 | Lit : int -> term int
 | Fun : ('a -> 'b) -> term ('a -> 'b)
 | App : term ('a -> 'b) * term 'a -> term 'b
 ```

 In much the same way as the vector example, which forced us to be
 correct with our functions, GADTs can also be applied in making us be
 correct with our _data_. The type `term 'a` represents well typed terms:
 the interpretation of such a value need not be concerned with runtime
 errors at all, by leveraging the Amulet type system to make sure its
 inputs are correct.

 ```
 let eval (x : term 'a) : 'a =
 match x with
 | Lit l -> l
 | Fun f -> f
 | App (f, x) -> (eval f) (eval x)
 ```


 While equalities let us bend the type system to our will, vectors and
 terms let _the type system_ help us, in making incorrect implementations
 compile errors.

 Rank-N Types
 ============

 Rank-N types are quite useful, I'm sure. To be quite honest, they were
 mostly implemented in preparation for GADTs, as the features have some
 overlap.

 A use case one might imagine if Amulet had notation for monads would be
 [an implementation of the ST monad][^2], which prevents mutable state
 from escaping by use of rank-N types. `St.run action` is a well-typed
 program, since `action` has type `forall 's. st 's int`, but `St.run
 action'` is not, since that has type `forall 's. st 's (ref 's int)`.

 ```ocaml
 let action =
 St.bind (alloc_ref 123) (fun var ->
 St.bind (update_ref var (fun x -> x * 2)) (fun () ->
 read_ref var))
 and action' =
 St.bind (alloc_ref 123) (fun var ->
 St.bind (update_ref var (fun x -> x * 2)) (fun () ->
 St.pure var))
 ```

 Conclusion
 ==========

 Types are very powerful things. A powerful type system helps guide the
 programmer by allowing the compiler to infer more and more of the
 _program_---type class dictionaries in Haskell, and as a more extreme
 example, proof search in Agda and Idris.

 However, since the industry has long been dominated by painfully
 first-order, very verbose type systems like those of Java and C#, it's
 no surprise that many programmers have fled to dynamically typed
 languages like ~~Go~~ Python---a type system needs to be fairly complex
 before it gets to being expressive, and it needs to be _very_ complex to
 get to the point of being useful.

 Complexity and difficulty, while often present together, are not
 nescessarily interdependent: Take, for instance, Standard ML. The
 first-order parametric types might seem restrictive when used to a
 system with like Haskell's (or, to some extent, Amulet's[^3]), but they
 actually allow a lot of flexibility, and do not need many annotations at
 all! They are a sweet spot in the design space.

 If I knew more about statistics, I'd have some charts here correlating
 programmer effort with implementor effort, and also programmer effort
 with the extent of properties one can state as types. Of course, these
 are all fuzzy metrics, and no amount of statistics would make those
 charts accurate, so have my feelings in prose instead:

 - Implementing a dynamic type system is _literally_ no effort. No effort
 needs to be spent writing an inference engine, or a constraint solver,
 or a renamer, or any other of the very complex moving parts of a type
 checker.

 However, the freedom they allow the implementor they take away from
 the programmer, by forcing them to keep track of the types of
 everything mentally. Even those that swear by dynamic types can not
 refute the claim that data has shape, and having a compiler that can
 make sure your shapes line up so you can focus on programming is a
 definite advantage.

 - On the opposite end of the spectrum, implementing a dependent type
 system is a _lot_ of effort. Things quickly diverge into undecidability
 before you even get to writing a solver---and higher order unification,
 which has a tendency to pop up, is undecidable too.

 While the implementor is subject to an endless stream of suffering,
 the programmer is in some ways free and some ways constrained. They
 can now express lots of invariants in the type system, from
 correctness of `sort` to correctness of [an entire compiler] or an
 [operating system kernel], but they must also state very precise types
 for everything.

 - In the middle lies a land of convenient programming without an
 endlessly suffering compiler author, a land first explored by the ML
 family with its polymorphic, inferred type system.

 This is clearly the sweet spot. Amulet leans slightly to the
 dependently type end of the spectrum, but can still infer the types
 for many simple and complex programs without any annotations-the
 programs that do not use generalised algebraic data types or rank-N
 polymorphism.

 [Theorems for Free]: https://people.mpi-sws.org/~dreyer/tor/papers/wadler.pdf
 [my last post]: /posts/2018-02-18.html
 [an implementation of the ST monad]: https://txt.abby.how/st-monad.ml.html
 [an entire compiler]: http://compcert.inria.fr/
 [operating system kernel]: https://sel4.systems/

 [^1]: In reality, the details are fuzzier. To be precise, pattern
 matching on GADTs only introduces an implication constraint when the
 type checker is applying a checking judgement. In practice, this means
 that at least the return type must be explicitly annotated.

 [^2]: Be warned that the example does not compile unless you remove the
 modules, since our renamer is currently a bit daft.

 [^3]: This is _my_ blog, and I'm allowed to brag about my projects, damn
 it.
--- a/pages/posts/2018-03-27-amulet-gadts.md
+++ b/pages/posts/2018-03-27-amulet-gadts.md
@ -0,0 +1,247 @@
 ---
 title: GADTs and Amulet
 date: March 27, 2018
 maths: true
 ---

 Dependent types are a very useful feature - the gold standard of
 enforcing invariants at compile time. However, they are still very much
 not practical, especially considering inference for unrestricted
 dependent types is equivalent to higher-order unification, which was
 proven to be undecidable.

 Fortunately, many of the benefits that dependent types bring aren't
 because of dependent products themselves, but instead because of
 associated features commonly present in those programming languages. One
 of these, which also happens to be especially easy to mimic, are
 _inductive families_, a generalisation of inductive data types: instead
 of defining a single type inductively, one defines an entire _family_ of
 related types.

 Many use cases for inductive families are actually instances of a rather
 less general concept, that of generalised algebraic data types, or
 GADTs: Contrary to the indexed data types of full dependently typed
 languages, these can and are implemented in several languages with
 extensive inference, such as Haskell, OCaml and, now, Amulet.

 Before I can talk about their implementation, I am legally obligated to
 present the example of _length indexed vectors_, linked structures whose
 size is known at compile time---instead of carrying around an integer
 representing the number of elements, it is represented in the type-level
 by a Peano[^1] natural number, as an _index_ to the vector type. By
 universally quantifying over the index, we can guarantee by
 parametricity[^2] that functions operating on these don't do inappropriate
 things to the sizes of vectors.

 ```ocaml
 type z ;;
 type s 'k ;;
 type vect 'n 'a =
 | Nil : vect z 'a
 | Cons : 'a * vect 'k 'a -> vect (s 'k) 'a
 ```

 Since the argument `'n` to `vect` (its length) varies with the constructor one
 chooses, we call it an _index_; On the other hand, `'a`, being uniform over all
 constructors, is called a _parameter_ (because the type is _parametric_ over
 the choice of `'a`). These definitions bake the measure of length into
 the type of vectors: an empty vector has length 0, and adding an element
 to the front of some other vector increases the length by 1.

 Matching on a vector reveals its index: in the `Nil` case, it's possible
 to (locally) conclude that it had length `z`. Meanwhile, the `Cons` case
 lets us infer that the length was the successor of some other natural
 number, `s 'k`, and that the tail itself has length `'k`.

 If one were to write a function to `map` a function over a `vect`or,
 they would be bound by the type system to write a correct implementation
 - well, either that or going out of their way to make a bogus one. It
 would be possible to enforce total correctness of a function such as
 this one, by adding linear types and making the vector parameter linear.

 ```ocaml
 let map (f : 'a -> 'b) (xs : vect 'n 'a) : vect 'n 'b =
 match xs with
 | Nil -> Nil
 | Cons (x, xs) -> Cons (f x, map f xs) ;;
 ```

 If we were to, say, duplicate every element in the list, an error would
 be reported. Unlike some others, this one is not very clear, and it
 definitely could be improved.

 ```
 Occurs check: The type variable jx
 occurs in the type s 'jx
 · Arising from use of the expression
 Cons (f x, Cons (f x, map f xs))
 │ 
 33 │ | Cons (x, xs) -> Cons (f x, Cons (f x, map f xs)) ;;
 │ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```

 This highlights the essence of GADTs: pattern matching on them reveals
 equalities about types that the solver can later exploit. This is what
 allows the programmer to write functions that vary their return types
 based on their inputs - a very limited form of type-term dependency,
 which brings us ever closer to the Calculus of Constructions corner of
 Barendregt's lambda cube[^3].

 The addition of generalised algebraic data types has been in planning
 for over two years---it was in the original design document. In a
 mission that not even my collaborator noticed, all of the recently-added
 type system and IR features were directed towards enabling the GADT
 work: bidirectional type checking, rank-N polymorphism and coercions.

 All of these features had cover stories: higher-ranked polymorphism was
 motivated by monadic regions; bidirectional type checking was motivated
 by the aforementioned polymorphism; and coercions were motivated by
 newtype optimisation. But, in reality, it was a conspiracy to make GADTs
 possible: having support for these features simplified implementing our
 most recent form of fancy types, and while adding all of these in one go
 would be possible, doing it incrementally was a lot saner.

 While neither higher-ranked types nor GADTs technically demand a
 bidirectional type system, implementing them with such a specification
 is considerably easier, removing the need for workarounds such as boxy
 types and a distinction between rigid/wobbly type variables. Our
 algorithm for GADT inference rather resembles Richard Eisenberg's
 [Bake]{.textsc}[^4], in that it only uses local equalities in _checking_
 mode.

 Adding GADTs also lead directly to a rewrite of the solver, which now
 has to work with _implication constraints_, of the form `(Q₁, ..., Qₙ)
 => Q`, which should be read as "Assuming `Q₁` through `Qₙ`, conclude
 `Q`." Pattern matching on generalised constructors, in checking mode,
 captures every constraint generated by checking the right-hand side of a
 clause and captures that as an implication constraint, with all the
 constructor-bound equalities as assumptions. As an example, this lets us
 write a type-safe cast function:

 ```ocaml
 type eq 'a 'b = Refl : eq 'a 'a
 (* an inhabitant of eq 'a 'b is a proof that 'a and 'b are equal *)

 let subst (Refl : eq 'a 'b) (x : 'a) : 'b = x ;;
 ```

 Unfortunately, to keep inference decidable, many functions that depend
 on generalised pattern matching need explicit type annotations, to guide
 the type checker.

 When _checking_ the body of the function, namely the variable reference
 `x`, the solver is working under an assumption `'a ~ 'b` (i.e., `'a` and
 `'b` stand for the same type), which lets us unify the stated type of
 `x`, namely `'a`, with the return type of the function, `'b`.

 If we remove the local assumption, say, by not matching on
 `Refl`{.haskell}, the solver will not be allowed to unify the two type
 variables `'a` and `'b`, and an error message will be reported[^6]:

 ```
 examples/gadt/equality.ml[11:43 ..11:43]: error
 Can not unify rigid type variable b with the rigid type variable a
 · Note: the variable b was rigidified because of a type ascription
 against the type forall 'a 'b. t 'a 'b -> 'a -> 'b
 and is represented by the constant bq
 · Note: the rigid type variable a, in turn,
 was rigidified because of a type ascription
 against the type forall 'a 'b. t 'a 'b -> 'a -> 'b
 · Arising from use of the expression
 x
 │ 
 11 │ let subst (_ : t 'a 'b) (x : 'a) : 'b = x ;;
 │ ~
 ```

 Our intermediate language was also extended, from a straightforward
 System F-like lambda calculus with type abstractions and applications,
 to a System F<sub>C</sub>-like system with _coercions_, _casts_, and
 _coercion abstraction_. Coercions are the evidence, produced by the
 solver, that an expression is usable as a given type---GADT patterns
 bind coercions like these, which are the "reification" of an implication
 constraint. This lets us make type-checking on the intermediate language
 fast and decidable[^5], as a useful sanity check.

 The two new judgements for GADT inference correspond directly to new
 cases in the `infer` and `check` functions, the latter of which I
 present here for completeness. The simplicity of this change serves as
 concrete evidence of the claim that bidirectional systems extend readily
 to new, complex features, producing maintainable and readable code.

 ```haskell
 check (Match t ps a) ty = do
 (t, tt) <- infer t
 ps <- for ps $ \(p, e) -> do
 (p', ms, cs) <- checkPattern p tt
 let tvs = Set.map unTvName (boundTvs p' ms)
 (p',) <$> implies (Arm p e) tt cs
 (local (typeVars %~ Set.union tvs)
 (extendMany ms (check e ty)))
 pure (Match t ps (a, ty))
 ``` 

 This corresponds to the checking judgement for matches, presented below.
 Note that in my (rather informal) theoretical presentation of Amulet
 typing judgements, we present implication constraints as a lexical scope
 of equalities conjoined with the scope of variables; Inference
 judgements (with double right arrows, $\Rightarrow$) correspond to uses of
 `infer`, pattern checking judgements ($\Leftarrow_\text{pat}$)
 correspond to `checkPattern`, which also doubles as $\mathtt{binds}$ and
 $\mathtt{cons}$, and the main checking judgement $\Leftarrow$ is the
 function `check`.

 $$
 \frac{\Gamma; \mathscr{Q} \vdash e \Rightarrow \tau
 \quad \Gamma \vdash p_i \Leftarrow_\text{pat} \tau
 \quad \Gamma, \mathtt{binds}(p_i); \mathscr{Q}, \mathtt{cons}(p_i)
 \vdash e_i \Leftarrow \sigma}
 {\Gamma; \mathscr{Q} \vdash \mathtt{match}\ e\ \mathtt{with}\ \{p_i \to
 e_i\} \Leftarrow \sigma}
 $$

 Our implementation of the type checker is a bit more complex, because it
 also does (some) elaboration and bookkeeping: tagging terms with types,
 blaming type errors correctly, etc.

 ---

 This new, complicated feature was a lot harder to implement than
 originally expected, but in the end it worked out. GADTs let us make the
 type system _stronger_, while maintaining the decidable inference that
 the non-fancy subset of the language enjoys.

 The example presented here was the most boring one possible, mostly
 because [two weeks ago] I wrote about their impact on the language's
 ability to make things safer.

 [^1]: Peano naturals are one particular formulation of the natural
 numbers, which postulates that zero (denoted `z` above) is a natural
 number, and any natural number's successor (denoted `s 'k` above) is
 itself natural.

 [^2]: This is one application of Philip Wadler's [Theorems for Free]
 technique: given a (polymorphic) type of some function, we can derive
 much of its behaviour.

 [^3]: Amulet is currently somewhere on the edge between λ2 - the second
 order lambda calculus, System F, and λP2, a system that allows
 quantification over types and terms using the dependent product form,
 which subsumes both the ∀ binder and the → arrow. Our lack of type
 functions currently leaves us very far from the CoC.

 [^4]: See [his thesis]. Our algorithm, of course, has the huge
 simplification of not having to deal with full dependent types.

 [^5]: Even if we don't do it yet---work is still ongoing to make the
 type checker and solver sane.

 [^6]: And quite a good one, if I do say so! The compiler
 syntax highlights and pretty-prints both terms and types relevant to the
 error, as you can see [here].

 [Theorems for Free]: http://homepages.inf.ed.ac.uk/wadler/topics/parametricity.html
 [his thesis]: https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs

 [two weeks ago]: /posts/2018-03-14.html
 [here]: https://i.abby.how/68c4d.png
--- a/pages/posts/2018-08-11-amulet-updates.md
+++ b/pages/posts/2018-08-11-amulet-updates.md
@ -0,0 +1,304 @@
 ---
 title: Amulet updates
 date: August 11, 2018
 maths: true
 ---

 Jesus, it's been a while. Though my last post was almost 6 months ago
 (give or take a few), I've been busy working on
 [Amulet](https://github.com/tmpim/amulet), which continues to grow,
 almost an eldritch abomination you try desperately, but fail, to kill.

 Since my last post, Amulet has changed a ton, in noticeable and
 not-so-noticeable ways. Here are the major changes to the compiler since
 then.

 Parser improvements
 ===================

 No language is good to use if it's inconvenient. So, in an effort to
 make writing code more convenient, we've removed the need for `;;` after
 top-level declarations, and added a _bunch_ of indentation sensitivity,
 thus making several keywords optional: `begin`{.ocaml} and `end`{.ocaml}
 are implicit in the body of a `fun`{.ocaml}, `match`{.ocaml}, or
 `let`{.ocaml}, which has made those keywords almost entirely obsolete.
 The body of a `let`{.ocaml} also need not be preceded by `in`{.ocaml} if
 meaning is clear from indentation.

 To demonstrate, where you would have

 ```ocaml
 let foo =
 let bar = fun x -> begin
 a;
 b;
 c
 end in begin
 bar ();
 bar 1;
 end ;;
 ```

 One can now write

 ```ocaml
 let foo =
 let bar = fun x ->
 a
 b
 c
 bar ()
 bar 1
 ```

 Moreover, we've added shorthand syntax for building and destructuring
 records: `{ x, y, z }`{.ocaml} is equivalent to `{ x = x, y = y, z = z
 }`{.ocaml} in both pattern and expression position.


 Changes to record typing
 ========================

 Whereas `{ x with a = b }` would extend the record `x` to contain a new
 field `a` (with value `b`), it's now _monomorphic update_ of the record
 `x`. That is: `x` must _already_ contain a field called `a`, with the
 same type as `b`.

 This lets you write a function for updating a field in a record, such as
 the one below, which would previously be impossible. Supporting
 polymorphic update is not a priority, but it'd be nice to have. The way
 PureScript, another language with row-polymorphic records, implements
 polymorphic update does not fit in with our constraint based type
 system. A new type of constraint would have to be introduced
 specifically for this, which while not impossible, is certainly
 annoying.

 ```ocaml
 let foo : forall 'row. { 'row | x : int } -> { 'row | x : int } =
 fun r -> { r with x = r.x + 1 }
 ```

 The impossibility of supporting polymorphic update with regular
 subsumption constraints $a \le b$ stems from the fact that, when faced
 with such a constraint, the compiler must produce a coercion function
 that turns _any_ $a$ into a $b$ _given the types alone_. This is
 possible for, say, field narrowing---just pick out the fields you want
 out of a bigger record---but not for update, since the compiler has no
 way of turning, for instance, an `int`{.ocaml} into a `string`{.ocaml}.

 Stronger support for Rank-N Types
 =================================

 Changes to how we handle subsumption have made it possible to store
 polymorphic values in not only tuples, but also general records. For
 instance:

 ```ocaml
 let foo = {
 apply : forall 'a 'b. ('a -> 'b) -> 'a -> 'b =
 fun x -> x
 } (* : { apply : forall 'a 'b. ('a -> 'b) -> 'a -> 'b } *)
 ```

 `foo`{.ocaml} is a record containing a single polymorphic application
 function. It can be used like so:

 ```ocaml
 let () =
 let { apply } = foo
 apply (+ 1) 1
 apply (fun x -> x) ()
 ```

 Pattern-matching Let
 ====================

 A feature I've desired for a while now, `let` expressions (and
 declarations!) can have a pattern as their left-hand sides, as
 demonstrated above. These can be used for any ol' type, including for
 cases where pattern matching would be refutable. I haven't gotten around
 to actually implementing this yet, but in the future, pattern matching
 in `let`s will be restricted to (arbitrary) product types only.

 ```ocaml
 type option 'a = Some of 'a | None
 type foo = Foo of { x : int }

 let _ =
 let Some x = ... (* forbidden *)
 let Foo { x } = ... (* allowed *)
 ```

 Even more "in-the-future", if we ever get around to adding attributes
 like OCaml's, the check for this could be bypassed by annotating the
 declaration with (say) a `[@partial]`{.ocaml} attribute.

 Unfortunately, since Amulet _is_ a strict language, these are a bit
 limited: They can not be recursive in _any_ way, neither directly nor
 indirectly.

 ```ocaml
 (* type error *)
 let (a, b) = (b, a)

 (* similarly *)
 let (a, b) = x
 and x = (a, b)
 ```

 Cycle detection and warnings
 ============================

 A verification pass is run over the AST if type-checking succeeds, to
 forbid illegal uses of recursion (strict language) and, as an additional
 convenience, warn when local variables go unused.

 For instance, this is [forbidden](/static/verify_error.png):

 ```ocaml
 let f = (fun x -> x) g
 and g = (fun x -> x) f
 ```

 And this gives a [warning](/static/verify_warn.png):

 ```ocaml
 let _ =
 let { a, b } = { a = 1, b = 2 }
 ()
 ```

 Plans for this include termination (and/or productivity) (as a
 warning) and exhaustiveness checks (as an error).

 No more `main`
 ============

 Since pattern-matching `let`{.ocaml}s are allowed at top-level, there's no more
 need for `main`. Instead of

 ```ocaml
 let main () =
 ...
 ```

 Just match on `()`{.ocaml} at top-level:

 ```ocaml
 let () =
 ...
 ```

 This gets rid of the (not so) subtle unsoundness introduced by the code
 generator having to figure out how to invoke `main`, and the type
 checker not checking that `main` has type `unit -> 'a`{.ocaml}, and also
 allows us to remove much of the silly special-casing around variables
 called `main`.

 ```ocaml
 let main x = x + 1
 (* attempt to perform arithmetic on a nil value *)
 ```

 Implicit Parameters
 ===================

 A bit like Scala's, these allow marking a function's parameter as
 implicit and having the type checker find out what argument you meant
 automatically. Their design is based on a bit of reading other compiler
 code, and also the paper on modular implicits for OCaml. However, we do
 not have a ML-style module system at all (much to my dismay, but it's
 being worked on), much less first class modules.

 Implicit parameters allow ad-hoc overloading based on dictionary passing
 (like type classes, but with less inference).

 ```ocaml
 type show 'a = Show of 'a -> string
 let show ?(Show f) = f

 let implicit show_string =
 Show (fun x -> x)

 let "foo" = show "foo"
 ```

 Here, unification makes it known that `show` is looking for an implicit
 argument of type `show string`{.ocaml}, and the only possibility is
 `show_string`{.ocaml}, which is what gets used.

 Implicit laziness
 =================

 There is a built-in type `lazy : type -> type`{.ocaml}, a function
 `force : forall 'a. lazy 'a -> 'a` for turning a thunk back into a
 value, and a keyword `lazy` that makes a thunk out of any expression.
 `lazy 'a`{.ocaml} and `'a` are mutual subtypes of eachother, and the
 compiler inserts thunks/`force`{.ocaml}s where appropriate to make code
 type-check.

 ```ocaml
 let x && y = if x then force y else false
 let () =
 false && launch_the_missiles ()

 (* no missiles were launched in the execution of this program *)
 ```

 General refactoring
 ===================

 - Literal patterns are allowed for all types, and they're tested of
 using `(==)`.

 - Amulet only has one type constructor in its AST for all its kinds of
 functions: `forall 'a. 'a -> int`{.ocaml}, `int -> string`{.ocaml} and `show string =>
 unit`{.ocaml} are all represented the same internally and disambiguated
 by dependency/visibility flags.

 - Polymorphic recursion is checked using "outline types", computed
 before fully-fledged inference kicks in based solely on the shape of
 values. This lets us handle the function below without an annotation on
 its return type by computing that `{ count = 1 }` _must_ have type `{
 count : int }` beforehand.

 Combined with the annotation on `x`, this gives us a "full" type
 signature, which lets us use checking for `size`, allowing polymorphic
 recursion to happen.

 ~~~{.ocaml}
 type nested 'a = Nested of nested ('a * 'a) * nested ('a * 'a) | One of 'a
 let size (x : nested 'a) =
 match x with
 | One _ -> { count = 1 }
 | Nested (a, _) -> { count = 2 * (size a).count }
 ~~~

 - The newtype elimination pass was rewritten once and, unfortunately,
 disabled, since it was broken with some touchy code.

 - Operator declarations like `let 2 + 2 = 5 in 2 + 2` are admissible.

 - Sanity of optimisations is checked at runtime by running a type
 checker over the intermediate language programs after all optimisations

 - Local opens are allowed, with two syntaxes: Either
 `M.( x + y)`{.ocaml} (or `M.{ a, b }`{.ocaml}) or `let open M in x +
 y`{.ocaml}.

 - Amulet is inconsistent in some more ways, such as `type : type`
 holding.

 - There are no more kinds.

 Conclusion
 ==========

 This post was a bit short, and also a bit hurried. Some of the features
 here deserve better explanations, but I felt like giving them an
 _outline_ (haha) would be better than leaving the blag to rot (yet
 again).

 Watch out for a blog post regarding (at _least_) implicit parameters,
 which will definitely involve the changes to subtyping involving
 records/tuples.
--- a/pages/posts/2019-01-28-mldelta.lhs
+++ b/pages/posts/2019-01-28-mldelta.lhs
@ -0,0 +1,329 @@
 ---
 title: Compositional Typing for ML
 date: January 28, 2019
 maths: true
 ---
 \long\def\ignore#1{}

 Compositional type-checking is a neat technique that I first saw in a
 paper by Olaf Chitil[^1]. He introduces a system of principal _typings_,
 as opposed to a system of principal _types_, as a way to address the bad
 type errors that many functional programming languages with type systems
 based on Hindley-Milner suffer from.

 Today I want to present a small type checker for a core ML (with,
 notably, no data types or modules) based roughly on the ideas from that
 paper. This post is _almost_ literate Haskell, but it's not a complete
 program: it only implements the type checker. If you actually want to
 play with the language, grab the unabridged code
 [here](https://github.com/zardyh/mld).

 \ignore{
 \begin{code}
 {-# LANGUAGE GeneralizedNewtypeDeriving, DerivingStrategies #-}
 \end{code}
 }

 ---

 \begin{code}
 module Typings where

 import qualified Data.Map.Merge.Strict as Map
 import qualified Data.Map.Strict as Map
 import qualified Data.Set as Set

 import Data.Foldable
 import Data.List
 import Data.Char

 import Control.Monad.Except
 \end{code}

 We'll begin, like always, by defining data structures for the language.
 Now, this is a bit against my style, but this system (which I
 shall call ML<sub>$\Delta$</sub> - but only because it sounds cool) is not
 presented as a pure type system - there are separate grammars for terms
 and types. Assume that `Var`{.haskell} is a suitable member of all the
 appropriate type classes.

 \begin{code}
 data Exp
 = Lam Var Exp
 | App Exp Exp
 | Use Var
 | Let (Var, Exp) Exp
 | Num Integer
 deriving (Eq, Show, Ord)

 data Type
 = TyVar Var
 | TyFun Type Type
 | TyCon Var
 deriving (Eq, Show, Ord)
 \end{code}

 ML<sub>$\Delta$</sub> is _painfully_ simple: It's a lambda calculus
 extended with `Let`{.haskell} since there needs to be a demonstration of
 recursion and polymorphism, and numbers so there can be a base type. It
 has no unusual features - in fact, it doesn't have many features at all:
 no rank-N types, GADTs, type classes, row-polymorphic records, tuples or
 even algebraic data types.

 I believe that a fully-featured programming language along the lines of
 Haskell could be shaped out of a type system like this, however I am not
 smart enough and could not find any prior literature on the topic.
 Sadly, it seems that compositional typings aren't a very active area of
 research at all. 

 The novelty starts to show up when we define data to represent the
 different kinds of scopes that crop up. There are monomorphic
 $\Delta$-contexts, which assign _types_ to names, and also polymorphic
 $\Gamma$-contexts, that assign _typings_ to names instead. While we're
 defining `newtype`{.haskell}s over `Map`{.haskell}s, let's also get
 substitutions out of the way.

 \begin{code}
 newtype Delta = Delta (Map.Map Var Type)
 deriving (Eq, Ord, Semigroup, Monoid)

 newtype Subst = Subst (Map.Map Var Type)
 deriving (Eq, Show, Ord, Monoid)

 newtype Gamma = Gamma (Map.Map Var Typing)
 deriving (Eq, Show, Ord, Semigroup, Monoid)
 \end{code}

 The star of the show, of course, are the typings themselves. A typing is
 a pair of a (monomorphic) type $\tau$ and a $\Delta$-context, and in a
 way it packages both the type of an expression and the variables it'll
 use from the scope.

 \begin{code}
 data Typing = Typing Delta Type
 deriving (Eq, Show, Ord)
 \end{code}

 With this, we're ready to look at how inference proceeds for
 ML<sub>$\Delta$</sub>. I make no effort at relating the rules
 implemented in code to anything except a vague idea of the rules in the
 paper: Those are complicated, especially since they deal with a language
 much more complicated than this humble calculus. In an effort not to
 embarrass myself, I'll also not present anything "formal".

 ---

 \begin{code}
 infer :: Exp -- The expression we're computing a typing for
 -> Gamma -- The Γ context
 -> [Var] -- A supply of fresh variables
 -> Subst -- The ambient substitution
 -> Either TypeError ( Typing -- The typing
 , [Var] -- New variables
 , Subst -- New substitution
 )
 \end{code}

 There are two cases when dealing with variables. Either a typing is
 present in the environment $\Gamma$, in which case we just use that
 with some retouching to make sure type variables aren't repeated - this
 takes the place of instantiating type schemes in Hindley-Milner.
 However, a variable can also _not_ be in the environment $\Gamma$, in
 which case we invent a fresh type variable $\alpha$[^2] for it and insist on
 the monomorphic typing $\{ v :: \alpha \} \vdash \alpha$.

 \begin{code}
 infer (Use v) (Gamma env) (new:xs) sub = 
 case Map.lookup v env of
 Just ty -> -- Use the typing that was looked up
 pure ((\(a, b) -> (a, b, sub)) (refresh ty xs))
 Nothing -> -- Make a new one!
 let new_delta = Delta (Map.singleton v new_ty)
 new_ty = TyVar new
 in pure (Typing new_delta new_ty, xs, sub)
 \end{code}

 Interestingly, this allows for (principal!) typings to be given even to
 code containing free variables. The typing for the expression `x`, for
 instance, is reported to be $\{ x :: \alpha \} \vdash \alpha$. Since
 this isn't meant to be a compiler, there's no handling for variables
 being out of scope, so the full inferred typings are printed on the
 REPL- err, RETL? A read-eval-type-loop!

 ```
 > x
 { x :: a } ⊢ a
 ```

 Moreover, this system does not have type schemes: Typings subsume those
 as well. Typings explicitly carry information regarding which type
 variables are polymorphic and which are constrained by something in the
 environment, avoiding a HM-like generalisation step.

 \begin{code}
 where
 refresh :: Typing -> [Var] -> (Typing, [Var])
 refresh (Typing (Delta delta) tau) xs =
 let tau_fv = Set.toList (ftv tau `Set.difference` foldMap ftv delta)
 (used, xs') = splitAt (length tau_fv) xs
 sub = Subst (Map.fromList (zip tau_fv (map TyVar used)))
 in (Typing (applyDelta sub delta) (apply sub tau), xs')
 \end{code}

 `refresh`{.haskell} is responsible for ML<sub>$\Delta$</sub>'s analogue of
 instantiation: New, fresh type variables are invented for each type
 variable free in the type $\tau$ that is not also free in the context
 $\Delta$. Whether or not this is better than $\forall$ quantifiers is up
 for debate, but it is jolly neat.

 The case for application might be the most interesting. We infer two
 typings $\Delta \vdash \tau$ and $\Delta' \vdash \sigma$ for the
 function and the argument respectively, then unify $\tau$ with $\sigma
 \to \alpha$ with $\alpha$ fresh.


 \begin{code}
 infer (App f a) env (alpha:xs) sub = do
 (Typing delta_f type_f, xs, sub) <- infer f env xs sub
 (Typing delta_a type_a, xs, sub) <- infer a env xs sub

 mgu <- unify (TyFun type_a (TyVar alpha)) type_f
 \end{code}

 This is enough to make sure that the expressions involved are
 compatible, but it does not ensure that the _contexts_ attached are also
 compatible. So, the substitution is applied to both contexts and they
 are merged - variables present in one but not in the other are kept, and
 variables present in both have their types unified.

 \begin{code}
 let delta_f' = applyDelta mgu delta_f
 delta_a' = applyDelta mgu delta_a
 delta_fa <- mergeDelta delta_f' delta_a'

 pure (Typing delta_fa (apply mgu (TyVar alpha)), xs, sub <> mgu)
 \end{code}

 If a variable `x` has, say, type `Bool` in the function's context but `Int`
 in the argument's context - that's a type error, one which that can be
 very precisely reported as an inconsistency in the types `x` is used at
 when trying to type some function application. This is _much_ better than
 the HM approach, which would just claim the latter usage is wrong.
 There are three spans of interest, not one.

 Inference for $\lambda$ abstractions is simple: We invent a fresh
 monomorphic typing for the bound variable, add it to the context when
 inferring a type for the body, then remove that one specifically from
 the typing of the body when creating one for the overall abstraction.

 \begin{code}
 infer (Lam v b) (Gamma env) (alpha:xs) sub = do
 let ty = TyVar alpha
 mono_typing = Typing (Delta (Map.singleton v ty)) ty
 new_env = Gamma (Map.insert v mono_typing env)

 (Typing (Delta body_delta) body_ty, xs, sub) <- infer b new_env xs sub

 let delta' = Delta (Map.delete v body_delta)
 pure (Typing delta' (apply sub (TyFun ty body_ty)), xs, sub)
 \end{code}

 Care is taken to apply the ambient substitution to the type of the
 abstraction so that details learned about the bound variable inside the
 body will be reflected in the type. This could also be extracted from
 the typing of the body, I suppose, but _eh_.

 `let`{.haskell}s are very easy, especially since generalisation is
 implicit in the structure of typings. We simply compute a typing from
 the body, _reduce_ it with respect to the let-bound variable, add it to
 the environment and infer a typing for the body.

 \begin{code}
 infer (Let (var, exp) body) gamma@(Gamma env) xs sub = do
 (exp_t, xs, sub) <- infer exp gamma xs sub
 let exp_s = reduceTyping var exp_t
 gamma' = Gamma (Map.insert var exp_s env)
 infer body gamma' xs sub
 \end{code}

 Reduction w.r.t. a variable `x` is a very simple operation that makes
 typings as polymorphic as possible, by deleting entries whose free type
 variables are disjoint with the overall type along with the entry for
 `x`.

 \begin{code}
 reduceTyping :: Var -> Typing -> Typing
 reduceTyping x (Typing (Delta delta) tau) =
 let tau_fv = ftv tau
 delta' = Map.filter keep (Map.delete x delta)
 keep sigma = not $ Set.null (ftv sigma `Set.intersection` tau_fv)
 in Typing (Delta delta') tau
 \end{code}

 ---

 Parsing, error reporting and user interaction do not have interesting
 implementations, so I have chosen not to include them here.

 Compositional typing is a very promising approach for languages with
 simple polymorphic type systems, in my opinion, because it presents a
 very cheap way of providing very accurate error messages much better
 than those of Haskell, OCaml and even Elm, a language for which good
 error messages are an explicit goal.

 As an example of this, consider the expression `fun x -> if x (add x 0)
 1`{.ocaml} (or, in Haskell, `\x -> if x then (x + (0 :: Int)) else (1 ::
 Int)`{.haskell} - the type annotations are to emulate
 ML<sub>$\Delta$</sub>'s insistence on monomorphic numbers).

 Types Bool and Int aren't compatible
 When checking that all uses of 'x' agree

 When that checking 'if x' (of type e -> e -> e)
 can be applied to 'add x 0' (of type Int)

 Typing conflicts:
 · x : Bool vs. Int

 The error message generated here is much better than the one GHC
 reports, if you ask me. It points out not that x has some "actual" type
 distinct from its "expected" type, as HM would conclude from its
 left-to-right bias, but rather that two uses of `x` aren't compatible.

 <interactive>:4:18: error:
 • Couldn't match expected type ‘Int’ with actual type ‘Bool’
 • In the expression: (x + 0 :: Int)
 In the expression: if x then (x + 0 :: Int) else 0
 In the expression: \ x -> if x then (x + 0 :: Int) else 0

 Of course, the prototype doesn't care for positions, so the error
 message is still not as good as it could be.

 Perhaps it should be further investigated whether this approach scales
 to at least type classes (since a form of ad-hoc polymorphism is
 absolutely needed) and polymorphic records, so that it can be used in a
 real language. I have my doubts as to if a system like this could
 reasonably be extended to support rank-N types, since it does not have
 $\forall$ quantifiers.

 **UPDATE**: I found out that extending a compositional typing system to
 support type classes is not only possible, it was also [Gergő Érdi's MSc.
 thesis](https://gergo.erdi.hu/projects/tandoori/)!

 **UPDATE**: Again! This is new. Anyway, I've cleaned up the code and
 [thrown it up on GitHub](https://github.com/zardyh/mld).

 Again, a full program implementing ML<sub>$\Delta$</sub> is available
 [here](https://github.com/zardyh/mld).
 Thank you for reading!


 [^1]: Olaf Chitil. 2001. Compositional explanation of types and
 algorithmic debugging of type errors. In Proceedings of the sixth ACM
 SIGPLAN international conference on Functional programming (ICFP '01).
 ACM, New York, NY, USA, 193-204.
 [DOI](http://dx.doi.org/10.1145/507635.507659).

 [^2]: Since I couldn't be arsed to set up monad transformers and all,
 we're doing this the lazy way (ba dum tss): an infinite list of
 variables, and hand-rolled reader/state monads.
--- a/pages/posts/2019-09-22-amulet-records.md
+++ b/pages/posts/2019-09-22-amulet-records.md
@ -0,0 +1,191 @@
 ---
 title: "A Quickie: Manipulating Records in Amulet"
 date: September 22, 2019
 maths: true
 ---

 Amulet, unlike some [other languages], has records figured out. Much like
 in ML (and PureScript), they are their own, first-class entities in the
 language as opposed to being syntax sugar for defining a product
 constructor and projection functions.

 ### Records are good

 Being entities in the language, it's logical to characterize them by
 their introduction and elimination judgements[^1].

 Records are introduced with record literals:

 $$
 \frac{
 \Gamma \vdash \overline{e \downarrow \tau}
 }{
 \Gamma \vdash \{ \overline{\mathtt{x} = e} \} \downarrow \{ \overline{\mathtt{x} : \tau} \}
 }
 $$

 And eliminated by projecting a single field:

 $$
 \frac{
 \Gamma \vdash r \downarrow \{ \alpha | \mathtt{x} : \tau \}
 }{
 \Gamma \vdash r.\mathtt{x} \uparrow \tau
 }
 $$

 Records also support monomorphic update:

 $$
 \frac{
 \Gamma \vdash r \downarrow \{ \alpha | \mathtt{x} : \tau \}
 \quad \Gamma \vdash e \downarrow \tau
 }{
 \Gamma \vdash \{ r\ \mathtt{with\ x} = e \} \downarrow \{ \alpha | \mathtt{x} : \tau \}
 }
 $$

 ### Records are.. kinda bad?

 Unfortunately, the rather minimalistic vocabulary for talking about
 records makes them slightly worthless. There's no way to extend a
 record, or to remove a key; Changing the type of a key is also
 forbidden, with the only workaround being enumerating all of the keys
 you _don't_ want to change.

 And, rather amusingly, given the trash-talking I pulled in the first
 paragraph, updating nested records is still a nightmare.

 ```amulet
 > let my_record = { x = 1, y = { z = 3 } }
 my_record : { x : int, y : { z : int } }
 > { my_record with y = { my_record.y with z = 4 } }
 _ = { x = 1, y = { z = 4 } }
 ```

 Yikes. Can we do better?

 ### An aside: Functional Dependencies

 Amulet recently learned how to cope with [functional dependencies].
 Functional dependencies extend multi-param type classes by allowing the
 programmer to restrict the relationships between parameters. To
 summarize it rather terribly:

 ```amulet
 (* an arbitrary relationship between types *)
 class r 'a 'b
 (* a function between types *)
 class f 'a 'b | 'a -> 'b
 (* a one-to-one mapping *)
 class o 'a 'b | 'a -> 'b, 'b -> 'a
 ```

 ### Never mind, records are good

 As of [today], Amulet knows the magic `row_cons` type class, inspired by
 [PureScript's class of the same name].

 ```amulet
 class
 row_cons 'record ('key : string) 'type 'new
 | 'record 'key 'type -> 'new (* 1 *)
 , 'new 'key -> 'record 'type (* 2 *)
 begin
 val extend_row : forall 'key -> 'type -> 'record -> 'new
 val restrict_row : forall 'key -> 'new -> 'type * 'record
 end
 ```

 This class has built-in solving rules corresponding to the two
 functional dependencies:

 1. If the original `record`, the `key` to be inserted, and its
 `type` are all known, then the `new` record can be solved for;
 2. If both the `key` that was inserted, and the `new` record, it is
 possible to solve for the old `record` and the `type` of the `key`.

 Note that rule 2 almost lets `row_cons` be solved for in reverse. Indeed, this is expressed by the type of `restrict_row`, which discovers both the `type` and the original `record`.

 Using the `row_cons` class and its magical methods...

 1. Records can be extended:
 ```amulet
 > Amc.extend_row @"foo" true { x = 1 }
 _ : { foo : bool, x : int } =
 { foo = true, x = 1 }
 ```
 2. Records can be restricted:
 ```amulet
 > Amc.restrict_row @"x" { x = 1 }
 _ : int * { } = (1, { x = 1 })
 ```

 And, given [a suitable framework of optics], records can be updated
 nicely:

 ```amulet
 > { x = { y = 2 } } |> (r @"x" <<< r @"y") ^~ succ
 _ : { x : { y : int } } =
 { x = { y = 3 } }
 ```

 ### God, those are some ugly types

 It's worth pointing out that making an optic that works for all fields,
 parametrised by a type-level string, is not easy or pretty, but it is
 work that only needs to be done once.

 ```ocaml
 type optic 'p 'a 's <- 'p 'a 'a -> 'p 's 's

 class
 Amc.row_cons 'r 'k 't 'n
 => has_lens 'r 'k 't 'n
 | 'k 'n -> 'r 't
 begin
 val rlens : strong 'p => proxy 'k -> optic 'p 't 'n
 end

 instance
 Amc.known_string 'key
 * Amc.row_cons 'record 'key 'type 'new
 => has_lens 'record 'key 'type 'new
 begin
 let rlens _ =
 let view r =
 let (x, _) = Amc.restrict_row @'key r
 x
 let set x r =
 let (_, r') = Amc.restrict_row @'key r
 Amc.extend_row @'key x r'
 lens view set
 end

 let r
 : forall 'key -> forall 'record 'type 'new 'p.
 Amc.known_string 'key
 * has_lens 'record 'key 'type 'new
 * strong 'p
 => optic 'p 'type 'new =
 fun x -> rlens @'record (Proxy : proxy 'key) x
 ```

 ---

 Sorry for the short post, but that's it for today.

 ---

 [^1]: Record fields $\mathtt{x}$ are typeset in monospaced font to make
 it apparent that they are unfortunately not first-class in the language,
 but rather part of the syntax. Since Amulet's type system is inherently
 bidirectional, the judgement $\Gamma \vdash e \uparrow \tau$ represents
 type inference while $\Gamma \vdash e \downarrow \tau$ stands for type
 checking.

 [functional dependencies]: https://web.cecs.pdx.edu/~mpj/pubs/fundeps.html
 [other languages]: https://haskell.org
 [today]: https://github.com/tmpim/amulet/pull/168
 [PureScript's class of the same name]: https://pursuit.purescript.org/builtins/docs/Prim.Row#t:Cons
 [a suitable framework of optics]: /static/profunctors.ml.html
--- a/pages/posts/2019-09-25-amc-prove.md
+++ b/pages/posts/2019-09-25-amc-prove.md
@ -0,0 +1,136 @@
 ---
 title: "Announcement: amc-prove"
 date: September 25, 2019
 maths: true
 ---

 `amc-prove` is a smallish tool to automatically prove (some) sentences
 of constructive quantifier-free[^1] first-order logic using the Amulet
 compiler's capability to suggest replacements for typed holes.

 In addition to printing whether or not it could determine the truthiness
 of the sentence, `amc-prove` will also report the smallest proof term it
 could compute of that type.

 ### What works right now

 * Function types `P -> Q`{.amcprove}, corresponding to $P \to Q$ in the logic.
 * Product types `P * Q`{.amcprove}, corresponding to $P \land Q$ in the logic.
 * Sum types `P + Q`{.amcprove}, corresponding to $P \lor Q$ in the logic
 * `tt`{.amcprove} and `ff`{.amcprove} correspond to $\top$ and $\bot$ respectively
 * The propositional bi-implication type `P <-> Q`{.amcprove} stands for $P \iff Q$
 and is interpreted as $P \to Q \land Q \to P$

 ### What is fiddly right now

 Amulet will not attempt to pattern match on a sum type nested inside a
 product type. Concretely, this means having to replace $(P \lor Q) \land
 R \to S$ by $(P \lor Q) \to R \to S$ (currying).

 `amc-prove`'s support for negation and quantifiers is incredibly fiddly.
 There is a canonical empty type, `ff`{.amcprove}, but the negation
 connective `not P`{.amcprove} expands to `P -> forall 'a.
 'a`{.amcprove}, since empty types aren't properly supported. As a
 concrete example, take the double-negation of the law of excluded middle
 $\neg\neg(P \lor \neg{}P)$, which holds constructively.

 If you enter the direct translation of that sentence as a type,
 `amc-prove` will report that it couldn't find a solution. However, by
 using `P -> ff`{.amc-prove} instead of `not P`{.amc-prove}, a solution is
 found.

 ```amc-prove
 ? not (not (P + not P))
 probably not.
 ? ((P + (P -> forall 'a. 'a)) -> forall 'a. 'a) -> forall 'a. 'a
 probably not.
 ? ((P + (P -> ff)) -> ff) -> ff
 yes.
 fun f -> f (R (fun b -> f (L b)))
 ```

 ### How to get it

 `amc-prove` is bundled with the rest of the Amulet compiler [on Github].
 You'll need [Stack] to build. I recommend building with `stack build
 --fast` since the compiler is rather large and `amc-prove` does not
 benefit much from GHC's optimisations.

 ```
 % git clone https://github.com/tmpim/amc-prove.git
 % cd amc-prove
 % stack build --fast
 % stack run amc-prove
 Welcome to amc-prove.
 ?
 ```


 ### Usage sample

 Here's a small demonstration of everything that works.

 ```amc-prove
 ? P -> P
 yes.
 fun b -> b
 ? P -> Q -> P
 yes.
 fun a b -> a
 ? Q -> P -> P
 yes.
 fun a b -> b
 ? (P -> Q) * P -> Q
 yes.
 fun (h, x) -> h x
 ? P * Q -> P
 yes.
 fun (z, a) -> z
 ? P * Q -> Q
 yes.
 fun (z, a) -> a
 ? P -> Q -> P * Q
 yes.
 fun b c -> (b, c)
 ? P -> P + Q
 yes.
 fun y -> L y
 ? Q -> P + Q
 yes.
 fun y -> R y
 ? (P -> R) -> (Q -> R) -> P + Q -> R
 yes.
 fun g f -> function
 | (L y) -> g y
 | (R c) -> f c
 ? not (P * not P)
 yes.
 Not (fun (a, (Not h)) -> h a)
 (* Note: Only one implication of DeMorgan's second law holds
 constructively *)
 ? not (P + Q) <-> (not P) * (not Q)
 yes.
 (* Note: I have a marvellous term to prove this proposition,
 but unfortunately it is too large to fit in this margin. *)
 ? (not P) + (not Q) -> not (P * Q)
 yes.
 function
 | (L (Not f)) ->
 Not (fun (a, b) -> f a)
 | (R (Not g)) ->
 Not (fun (y, z) -> g z)
 ```

 [^1]: Technically, amc-prove "supports" the entire Amulet type system,
 which includes things like type-classes and rank-N types (it's equal in
 expressive power to System F). However, the hole-filling logic is meant
 to aid the programmer while she codes, not exhaustively search for a
 solution, so it was written to fail early and fail fast instead of
 spending unbounded time searching for a solution that might not be
 there.

 You can find the proof term I redacted from DeMorgan's first law [here].

 [on Github]: https://github.com/tmpim/amulet
 [Stack]: https://haskellstack.org
 [here]: /static/demorgan-1.ml.html
--- a/pages/posts/2019-09-29-amc-prove-interactive.md
+++ b/pages/posts/2019-09-29-amc-prove-interactive.md
@ -0,0 +1,202 @@
 ---
 title: Interactive amc-prove
 date: September 29, 2019
 ---

 Following my [last post announcing amc-prove](/posts/2019-09-25.html), I
 decided I'd make it more accessible to people who wouldn't like to spend
 almost 10 minutes compiling Haskell code just to play with a fiddly
 prover.

 So I made a web interface for the thing: Play with it below.

 Text immediately following <span style='color:red'>> </span> is editable.

 <noscript>
 Sorry, this post isn't for you.
 </noscript>

 <div id='prover-container'>
 <div id='prover'>
 <pre id='prover-output'>
 <span style='color: red' id=prover-prompt>> </span><span id='prover-input' contenteditable='true'>(not P) + (not Q) -> not (P * Q)</span>
 </pre>
 </div>
 </div>

 <style>
 div#prover-container {
 width: 100%;
 height: 600px;
 border: 1px solid #c0c0c0;
 background: #d6d6d6;
 box-shadow: 1px 1px #c0c0c0;
 border-radius: 0.3em;
 }

 div#prover {
 width: 100%;
 height: 100%;
 overflow-y: scroll;
 }
 pre#prover-output, pre#prover-output > * {
 white-space: pre-wrap;
 }
 span#prover-input {
 border: 1px solid #c0c0c0;
 font-family: monospace;
 }
 </style>

 <script async>
 let input = document.getElementById('prover-input');
 let output = document.getElementById('prover-output');
 let prompt = document.getElementById('prover-prompt');

 let ERROR_REGEX = /^\<input\>\[(\d+):(\d+) \.\.(\d+):(\d+)\]: error$/;
 let NEGATIVE_REGEX = /^probably not\.$/;


 let prove = async (sentence) => {
 let response;
 try {
 response = await fetch('/prove', {
 method: 'POST',
 headers: {
 Host: '/prove'
 },
 body: sentence
 });
 } catch (e) {
 return { error: true, error_msg: ['Server responded with an error'] }
 }
 const prover_response = (await response.text()).split('\n').map(x => x.trimEnd()).filter(x => x !== '');
 const result_line = prover_response[0];

 console.log(result_line);
 console.log(result_line.match(ERROR_REGEX));

 if (response.status !== 200) {
 return { error: true, error_msg: ['Server responded with an error'] }
 } else if (result_line.match(ERROR_REGEX) !== null) {
 return { error: true, error_msg: prover_response.slice(1) }
 } else if (result_line.match(NEGATIVE_REGEX) !== null) {
 return { error: false, proven: false }
 } else {
 return { error: false, proven: true, proof: prover_response.slice(1) };
 }
 };

 const LEX_RULES = [
 [/^(fun(ction)?|match|not)/, 'kw'],
 [/^[a-z][a-z0-9]*/, 'va'],
 [/^[A-Z][A-Za-z0-9]*/, 'dt'],
 [/^[\(\)\[\]<->\+\*\-,|]/, 'va']
 ];

 let tokenise = (code) => {
 let tokens = []
 let exit = false;
 while (code !== '' && !exit) {
 let matched_this_loop = false;

 LEX_RULES.map(([regex, clss]) => {
 let had_spc = code.match(/^\s*/)[0]
 let match = code.trimStart().match(regex);

 if (match !== null) {
 let matched = match[0];
 code = code.trimStart().slice(matched.length);
 tokens.push({ t: had_spc + matched, c : clss });
 matched_this_loop = true;
 };
 });

 if (!matched_this_loop) {
 exit = true;
 tokens.push({ t : code, c : 'va' });
 }
 }
 return tokens;
 }

 let syntax_highlight = (code) => {
 let container = document.createElement('span');
 code.map(line => {
 let elems = tokenise(line).map(token => {
 let span = document.createElement('span');
 span.innerText = token.t;
 span.classList.add(token.c);
 container.appendChild(span);
 });
 container.appendChild(document.createElement('br'));
 });
 return container;
 }

 let history = [];
 let history_index = 0;

 input.onkeydown = async (e) => {
 let key = e.key || e.which;
 if (key == 'Enter' && !e.shiftKey) {
 e.preventDefault();
 let text = input.innerText;

 history_index = -1;
 if (text !== history[history.length - 1]) {
 history.push(text);
 }

 let result = await prove(text);

 let old_input = syntax_highlight(['> ' + text]);
 let out_block = document.createElement('span');

 if (result.error) {
 out_block.style = 'color: red';
 out_block.innerText = 'error:\n';
 result.error_msg.slice(0, 1).map(e => {
 let span = document.createElement('span');
 span.style = 'color: red';
 span.innerText = ' ' + e + '\n';
 out_block.appendChild(span);
 });
 } else if (result.proven) {
 out_block.classList.add('kw');
 out_block.innerText = 'yes:\n'
 out_block.appendChild(syntax_highlight(result.proof));
 } else {
 out_block.classList.add('kw');
 out_block.innerText = 'not proven\n';
 }
 input.innerText = '';

 output.insertBefore(old_input, prompt);
 output.insertBefore(out_block, prompt);
 input.scrollIntoView();
 } else if (key === 'Up' || key === 'ArrowUp') {
 e.preventDefault();
 console.log(history, history_index)
 if(history_index > 0) {
 history_index--;
 } else if(history_index < 0 && history.length > 0) {
 history_index = history.length - 1
 } else {
 return;
 }
 input.innerText = history[history_index];
 input.focus();
 } else if (key == 'Down' || key === 'ArrowDown') {
 e.preventDefault();
 if(history_index >= 0) {
 history_index = history_index < history.length - 1 ? history_index + 1 : -1;
 } else {
 return;
 }

 input.innerText = history[history_index] || '';
 }
 }

 </script>
--- a/pages/posts/2019-10-04-amulet-kinds.md
+++ b/pages/posts/2019-10-04-amulet-kinds.md
@ -0,0 +1,369 @@
 ---
 title: Typed Type-Level Computation in Amulet
 date: October 04, 2019
 maths: true
 ---

 Amulet, as a programming language, has a focus on strong static typing. This has led us to adopt
 many features inspired by dependently-typed languages, the most prominent of which being typed holes
 and GADTs, the latter being an imitation of indexed families.

 However, Amulet was up until recently sorely lacking in a way to express computational content in
 types: It was possible to index datatypes by other, regular datatypes ("datatype promotion", in the
 Haskell lingo) since the type and kind levels are one and the same, but writing functions on those
 indices was entirely impossible.

 As of this week, the language supports two complementary mechanisms for typed type-level programming:
 _type classes with functional dependencies_, a form of logic programming, and _type functions_, which
 permit functional programming on the type level.

 I'll introduce them in that order; This post is meant to serve as an introduction to type-level
 programming using either technique in general, but it'll also present some concepts formally and with
 some technical depth.

 ### Type Classes are Relations: Programming with Fundeps

 In set theory[^1] a _relation_ $R$ over a family of sets $A, B, C, \dots$ is a subset of the
 cartesian product $A \times B \times C \times \dots$. If $(a, b, c, \dots) \in R_{A,B,C,\dots}$ we
 say that $a$, $b$ and $c$ are _related_ by $R$.

 In this context, a _functional dependency_ is a term $X \leadsto Y$
 where $X$ and $Y$ are both sets of natural numbers. A relation is said
 to satisfy a functional dependency $X \leadsto Y$ when, for any tuple in
 the relation, the values at $X$ uniquely determine the values at $Y$.

 For instance, the relations $R_{A,B}$ satisfying $\{0\} \leadsto \{1\}$ are partial functions $A \to
 B$, and if it were additionally to satisfy $\{1\} \leadsto \{0\}$ it would be a partial one-to-one
 mapping.

 One might wonder what all of this abstract nonsense[^2] has to do with type classes. The thing is, a
 type class `class foo : A -> B -> constraint`{.amulet} is a relation $\text{Foo}_{A,B}$! With this in
 mind, it becomes easy to understand what it might mean for a type class to satisfy a functional
 relation, and indeed the expressive power that they bring.

 To make it concrete:

 ```amulet
 class r 'a 'b (* an arbitrary relation between a and b *)
 class f 'a 'b | 'a -> 'b (* a function from a to b *)
 class i 'a 'b | 'a -> 'b, 'b -> 'a (* a one-to-one mapping between a and b *)
 ```

 #### The Classic Example: Collections

 In Mark P. Jones' paper introducing functional dependencies, he presents as an example the class
 `collects : type -> type -> constraint`{.amulet}, where `'e`{.amulet} is the type of elements in the
 collection type `'ce`{.amulet}. This class can be used for all the standard, polymorphic collections
 (of kind `type -> type`{.amulet}), but it also admits instances for monomorphic collections, like a
 `bitset`.

 ```amulet
 class collects 'e 'ce begin
 val empty : 'ce
 val insert : 'e -> 'ce -> 'ce
 val member : 'e -> 'ce -> bool
 end
 ```

 Omitting the standard implementation details, this class admits instances like:

 ```amulet
 class eq 'a => collects 'a (list 'a)
 class eq 'a => collects 'a ('a -> bool)
 instance collects char string (* amulet strings are not list char *)
 ```

 However, Jones points out this class, as written, has a variety of problems. For starters, `empty`{.amulet} has
 an ambiguous type, `forall 'e 'ce. collects 'e 'ce => 'ce`{.amulet}. This type is ambiguous because the type
 varialbe `e`{.amulet} is $\forall$-bound, and appears in the constraint `collects 'e 'ce`{.amulet}, but doesn't
 appear to the right of the `=>`{.amulet}; Thus, we can't solve it using unification, and the program
 would have undefined semantics.

 Moreover, this class leads to poor inferred types. Consider the two functions `f`{.amulet} and `g`, below.
 These have the types `(collects 'a 'c * collects 'b 'c) => 'a -> 'b -> 'c -> 'c`{.amulet} and
 `(collects bool 'c * collects int 'c) => 'c -> 'c`{.amulet} respectively.

 ```amulet
 let f x y coll = insert x (insert y coll)
 let g coll = f true 1 coll
 ```

 The problem with the type of `f`{.amulet} is that it is too general, if we wish to model homogeneous
 collections only; This leads to the type of `g`, which really ought to be a type error, but isn't; The
 programming error in its definition won't be reported here, but at the use site, which might be in a
 different module entirely. This problem of poor type inference and bad error locality motivates us to
 refine the class `collects`, adding a functional dependency:

 ```amulet
 (* Read: 'ce determines 'e *)
 class collects 'e 'ce | 'ce -> 'e begin
 val empty : 'ce
 val insert : 'e -> 'ce -> 'ce
 val member : 'e -> 'ce -> bool
 end
 ```

 This class admits all the same instances as before, but now the functional dependency lets Amulet
 infer an improved type for `f`{.amulet} and report the type error at `g`{.amulet}.

 ```amulet
 val f : collects 'a 'b => 'a -> 'a -> 'b -> 'b
 ```

 ```
 │ 
 2 │ let g coll = f true 1 coll
 │ ^
 Couldn't match actual type int
 with the type expected by the context, bool
 ```

 One can see from the type of `f`{.amulet} that Amulet can simplify the conjunction of constraints
 `collects 'a 'c * collects 'b 'c`{.amulet} into `collects 'a 'c`{.amulet} and substitute `'b`{.amulet}
 for `'a`{.amulet} in the rest of the type. This is because the second parameter of `collects`{.amulet}
 is enough to determine the first parameter; Since `'c`{.amulet} is obviously equal to itself,
 `'a`{.amulet} must be equal to `'b`.

 We can observe improvement within the language using a pair of data types, `(:-) : constraint ->
 constraint -> type`{.amulet} and `dict : constraint -> type`{.amulet}, which serve as witnesses of
 implication between constraints and a single constraint respectively.

 ```amulet
 type dict 'c = Dict : 'c => dict 'c
 type 'p :- 'q = Sub of ('p => unit -> dict 'q)

 let improve : forall 'a 'b 'c. (collects 'a 'c * collects 'b 'c) :- ('a ~ 'b) =
 Sub (fun _ -> Dict)
 ```

 Because this program type-checks, we can be sure that `collects 'a 'c * collects 'b 'c`{.amulet}
 implies `'a`{.amulet} is equal to `'b`{.amulet}. Neat!

 ### Computing with Fundeps: Natural Numbers and Vectors

 If you saw this coming, pat yourself on the back.

 I'm required by law to talk about vectors in every post about types. No, really; It's true.
 I'm sure everyone's seen this by now, but vectors are cons-lists indexed by their type as a Peano
 natural.

 ```amulet
 type nat = Z | S of nat
 type vect 'n 'a =
 | Nil : vect Z 'a
 | Cons : 'a * vect 'n 'a -> vect (S 'n) 'a
 ```

 Our running objective for this post will be to write a function to append two vectors, such that the
 length of the result is the sum of the lengths of the arguments.[^3] But, how do we even write the
 type of such a function?

 Here we can use a type class with functional dependencies witnessing the fact that $a + b = c$, for
 some $a$, $b$, $c$ all in $\mathbb{N}$. Obviously, knowing $a$ and $b$ is enough to know $c$, and the
 functional dependency expresses that. Due to the way we're going to be implementing `add`, the other
 two functional dependencies aren't admissible.

 ```amulet
 class add 'a 'b 'c | 'a 'b -> 'c begin end
 ```

 Adding zero to something just results in that something, and if $a + b = c$ then $(1 + a) + b = 1 + c$.

 ```amulet
 instance add Z 'a 'a begin end
 instance add 'a 'b 'c => add (S 'a) 'b (S 'c) begin end
 ```

 With this in hands, we can write a function to append vectors.

 ```amulet
 let append : forall 'n 'k 'm 'a. add 'n 'k 'm
 => vect 'n 'a -> vect 'k 'a -> vect 'm 'a =
 fun xs ys ->
 match xs with
 | Nil -> ys
 | Cons (x, xs) -> Cons (x, append xs ys)
 ```

 Success! 
 ... or maybe not. Amulet's complaining about our definition of `append` even though it's correct; What
 gives?

 The problem is that while functional dependencies let us conclude equalities from pairs of instances,
 it doesn't do us any good if there's a single instance. So we need a way to reflect the equalities in
 a way that can be pattern-matched on. If your GADT senses are going off, that's a good thing.

 #### Computing with Evidence

 This is terribly boring to do and what motivated me to add type functions to Amulet in the first
 place, but the solution here is to have a GADT that mirrors the structure of the class instances, and
 make the instances compute that. Then, in our append function, we can match on this evidence to reveal
 equalities to the type checker.

 ```amulet
 type add_ev 'k 'n 'm =
 | AddZ : add_ev Z 'a 'a
 | AddS : add_ev 'a 'b 'c -> add_ev (S 'a) 'b (S 'c)

 class add 'a 'b 'c | 'a 'b -> 'c begin
 val ev : add_ev 'a 'b 'c
 end

 instance add Z 'a 'a begin
 let ev = AddZ
 end

 instance add 'a 'b 'c => add (S 'a) 'b (S 'c) begin
 let ev = AddS ev
 end
 ```

 Now we can write vector `append` using the `add_ev` type.

 ```amulet
 let append' (ev : add_ev 'n 'm 'k)
 (xs : vect 'n 'a)
 (ys : vect 'm 'a)
 : vect 'k 'a =
 match ev, xs with
 | AddZ, Nil -> ys
 | AddS p, Cons (x, xs) -> Cons (x, append' p xs ys)
 and append xs ys = append' ev xs ys
 ```

 This type-checks and we're done.

 ### Functions on Types: Programming with Closed Type Functions

 Look, duplicating the structure of a type class at the value level just so the compiler can figure out
 equalities is stupid. Can't we make it do that work instead? Enter _closed type functions_.

 ```amulet
 type function (+) 'n 'm begin
 Z + 'n = 'n
 (S 'k) + 'n = S ('k + 'n)
 end
 ```

 This declaration introduces the type constructor `(+)`{.amulet} (usually written infix) and two rules
 for reducing types involving saturated applications of `(+)`{.amulet}. Type functions, unlike type
 classes which are defined like Prolog clauses, are defined in a pattern-matching style reminiscent of
 Haskell.

 Each type function has a set of (potentially overlapping) _equations_, and the compiler will reduce an
 application using an equation as soon as it's sure that equation is the only possible equation based
 on the currently-known arguments.

 Using the type function `(+)`{.amulet} we can use our original implementation of `append` and have it
 type-check:

 ```amulet
 let append (xs : vect 'n 'a) (ys : vect 'k 'a) : vect ('n + 'k) 'a =
 match xs with
 | Nil -> ys
 | Cons (x, xs) -> Cons (x, append xs ys)
 let ys = append (Cons (1, Nil)) (Cons (2, Cons (3, Nil)))
 ```

 Now, a bit of a strange thing is that Amulet reduces type family applications as lazily as possible,
 so that `ys` above has type `vect (S Z + S (S Z)) int`{.amulet}. In practice, this isn't an issue, as
 a simple ascription shows that this type is equal to the more orthodox `vect (S (S (S Z)))
 int`{.amulet}.

 ```amulet
 let zs : vect (S (S (S Z))) int = ys
 ```

 Internally, type functions do pretty much the same thing as the functional dependency + evidence
 approach we used internally. Each equation gives rise to an equality _axiom_, represented as a
 constructor because our intermediate language pretty much lets constructors return whatever they damn
 want.

 ```amulet
 type + '(n : nat) '(m : nat) =
 | awp : forall 'n 'm 'r. 'n ~ Z -> 'm ~ 'n -> ('n + 'm) ~ 'n
 | awq : forall 'n 'k 'm 'l. 'n ~ (S 'k) -> 'm ~ 'l
 -> ('n + 'm) ~ (S ('k + 'l))
 ```

 These symbols have ugly autogenerated names because they're internal to the compiler and should never
 appear to users, but you can see that `awp` and `awq` correspond to each clause of the `(+)`{.amulet}
 type function, with a bit more freedom in renaming type variables.

 ### Custom Type Errors: Typing Better

 Sometimes - I mean, pretty often - you have better domain knowledge than Amulet. For instance, you
 might know that it's impossible to `show` a function. The `type_error` type family lets you tell the
 type checker this:

 ```amulet
 instance
 (type_error (String "Can't show functional type:" :<>: ShowType ('a -> 'b))
 => show ('a -> 'b)
 begin
 let show _ = ""
 end
 ```

 Now trying to use `show` on a function value will give you a nice error message:

 ```amulet
 let _ = show (fun x -> x + 1)
 ```
 ```
 │ 
 1 │ let _ = show (fun x -> x + 1)
 │ ^^^^^^^^^^^^^^^^^^^^^
 Can't show functional type: int -> int
 ```

 ### Type Families can Overlap

 Type families can tell when two types are equal or not:

 ```amulet
 type function equal 'a 'b begin
 discrim 'a 'a = True
 discrim 'a 'b = False
 end
 ```

 But overlapping equations need to agree:

 ```amulet
 type function overlap_not_ok 'a begin
 overlap_not_ok int = string
 overlap_not_ok int = int
 end
 ```
 ```
 Overlapping equations for overlap_not_ok int
 • Note: first defined here,
 │ 
 2 │ overlap_not_ok int = string
 │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 but also defined here
 │ 
 3 │ overlap_not_ok int = int
 │ ^^^^^^^^^^^^^^^^^^^^^^^^
 ```

 ### Conclusion

 Type families and type classes with functional dependencies are both ways to introduce computation in
 the type system. They both have their strengths and weaknesses: Fundeps allow improvement to inferred
 types, but type families interact better with GADTs (since they generate more equalities). Both are
 important in language with a focus on type safety, in my opinion.

 [^1]: This is not actually the definition of a relation with full generality; Set theorists are
 concerned with arbitrary families of sets indexed by some $i \in I$, where $I$ is a set of indices;
 Here, we've set $I = \mathbb{N}$ and restrict ourselves to the case where relations are tuples.

 [^2]: At least it's not category theory.

 [^3]: In the shower today I actually realised that the `append` function on vectors is a witness to
 the algebraic identity $a^n * a^m = a^{n + m}$. Think about it: the `vect 'n`{.amulet} functor is
 representable by `fin 'n`{.amulet}, i.e. it is isomorphic to functions `fin 'n -> 'a`{.amulet}. By
 definition, `fin 'n`{.amulet} is the type with `'n`{.amulet} elements, and arrow types `'a ->
 'b`{.amulet} have $\text{size}(b)^{\text{size}(a)}$ elements, which leads us to conclude `vect 'n
 'a` has size $\text{size}(a)^n$ elements.
--- a/pages/posts/2019-10-19-amulet-quicklook.md
+++ b/pages/posts/2019-10-19-amulet-quicklook.md
@ -0,0 +1,126 @@
 ---
 title: "A Quickie: A Use Case for Impredicative Polymorphism"
 path: impredicative-polymorphism
 date: October 19, 2019
 ---

 Amulet now (as of the 18th of October) has support for impredicative
 polymorphism based on [Quick Look impredicativity], an algorithm first
 proposed for GHC that treats inference of applications as a two-step
 process to enable inferring impredicative types.

 As a refresher, impredicative types (in Amulet) are types in which a
 `forall`{.amuçet} appears under a type constructor (that is not
 `(->)`{.amulet} or `(*)`{.amulet}, since those have special variance in
 the compiler).

 Quick Look impredicativity works by doing type checking of applications
 in two phases: the _quick look_, which is called so because it's faster
 than regular type inference, and the regular type-checking of
 arguments.

 Given a `n`-ary application
 <code>f x<sub>1</sub> ... x<sub>n</sub></code>:

 <ol type="I">
 <li>
 The _quick look_ proceeds by inferring the type of the function to
 expose the first `n` quantifiers, based on the form of the arguments.
 For a regular term argument `e`, we expect a `'t ->`{.amulet} quantifier; For
 visible type arguments, we expect either `forall 'a.`{.amulet} or
 `forall 'a ->`{.amulet}.

 After we have each of the quantifiers, we quickly infer a type for each
 of the _simple_ arguments in
 <code>x<sub>1</sub> ... x<sub>n</sub></code>.
 Here, simple means either a
 variable, literal, application or an expression annotated with a type
 `x : t`{.amulet}. With this type in hands, we unify it with the type
 expected by the quantifier, to collect a partial substituion (in which
 unification failures are ignored), used to discover impredicative
 instantiation.

 For example, say `f : 'a -> list 'a -> list 'a`{.amulet} (the cons
 function)[^1], and we want to infer the application `f (fun x -> x) (Nil
@(forall 'xx. 'xx -> 'xx))`{.amulet}. Here, the quick look will inspect
 each argument in turn, coming up with a `list 'a ~ list (forall 'xx. 'xx
 -> 'xx)`{.amulet} equality by looking at the second argument. Since the
 first argument is not simple, it tells us nothing. Thus, the second
 phase starts with the substitution `'a := forall 'xx. 'xx ->
 'xx`{.amulet}.
 </li>

 <li>
 The second phase is traditional type-checking of each argument in turn,
 against its respective quantifier. Here we use Amulet's type-checking
 function `check` instead of applying type-inference then constraining
 with subsumption since that results in more precise resuls.

 However, instead of taking the quantifiers directly from the function's
 inferred type, we first apply the substitution generated by the
 quick-look. Thus, keeping with the example, we check the function `(fun
 x -> x)`{.amulet} against the type `forall 'xx. 'xx -> 'xx`{.amulet},
 instead of checking it against the type variable `'a`{.amulet}.

 This is important because checking against a type variable degrades to
 inference + subsumption, which we wanted to avoid in the first place!
 Thus, if we had no quick look, the function `(fun x -> x)`{.amulet}
 would be given monomorphic type `'t1 -> 't2`{.amulet} (where
 `'t1'`{.amulet}, `'t2`{.amulet} are fresh unification variables), and
 we'd try to unify `list ('t1 -> 't2) ~ list (forall 'xx. 'xx ->
 'xx)`{.amulet} - No dice!
 </li>
 </ol>

 ### Why does this matter?

 Most papers discussing impredicative polymorphism focus on the boring,
 useless example of stuffing a list with identity functions. Indeed, this
 is what I demonstrated above.

 However, a much more useful example is putting _lenses_ in lists (or
 `optional`{.amulet}, `either`{.amulet}, or what have you). Recall the
 van Laarhoven encoding of lenses:

 ```amulet
 type lens 's 't 'a 'b <- forall 'f. functor 'f => ('a -> 'f 'b) -> 's -> 'f 't
 ```

 If you're not a fan of that, consider also the profunctor encoding of
 lenses:

 ```amulet
 type lens 's 't 'a 'b <- forall 'p. strong 'p => 'p 'a 'b -> 'p 's 't
 ```

 These types are _both_ polymorphic, which means we can't normally have a
 `list (lens _ _ _ _)`{.amulet}. This is an issue! The Haskell `lens`
 library works around this by providing a `LensLike`{.haskell} type,
 which is not polymorphic and takes the functor `f` by means of an
 additional parameter. However, consider the difference in denotation
 between

 ```haskell
 foo :: [Lens a a Int Int] -> a -> (Int, a)
 bar :: Functor f => [LensLike f a a Int Int] -> a -> (Int, a)
 ```

 The first function takes a list of lenses; It can then use these lenses
 in any way it pleases. The second, however, takes a list of lens-like
 values _that all use the same functor_. Thus, you can't `view` using the
 head of the list and `over` using the second element! (Recall that
 `view` uses the `Const`{.haskell} functor and `over`{.amulet} the
 `Identity`{.amulet} functor). Indeed, the second function can't use the
 lenses at all, since it must work for an arbitrary functor and not
 `Const`{.haskell}/`Identity`{.haskell}.

 Of course, [Amulet lets you put lenses in lists]: See `lens_list` and
 `xs` at the bottom of the file.


 [^1]: Assume that the `'a`{.amulet} variable is bound by a `forall
 'a.`{.amulet} quantifier. Since we don't use visible type application in
 the following example, I just skipped mentioning it.

 [Quick Look impredicativity]: https://github.com/serras/ghc-proposals/blob/quick-look/proposals/0000-quick-look-impredicativity.md
 [Amulet lets you put lenses in lists]: /static/profunctor-impredicative.ml.html
--- a/pages/posts/2020-01-31-lazy-eval.lhs
+++ b/pages/posts/2020-01-31-lazy-eval.lhs
--- a/pages/posts/2020-07-12-continuations.md
+++ b/pages/posts/2020-07-12-continuations.md
@ -0,0 +1,380 @@
 ---
 title: The Semantics of Evaluation &amp; Continuations
 date: July 12th, 2020
 maths: true
 ---

 Continuations are a criminally underappreciated language feature. Very few languages (off the top of my head: most Scheme dialects, some Standard ML implementations, and Ruby) support the---already very expressive---undelimited continuations---the kind introduced by `call/cc`{.scheme}---and even fewer implement the more expressive delimited continuations. Continuations (and tail recursion) can, in a first-class, functional way, express _all_ local and non-local control features, and are an integral part of efficient implementations of algebraic effects systems, both as language features and (most importantly) as libraries.

 <div style="display: flex">
 <div>
 Continuations, however, are notoriously hard to understand. In an informal way, we can say that a continuation is a first-class representation of the "future" of a computation. By this I do not mean a future in the sense of an asynchronous computation, but in a temporal sense. While descriptions like this are "correct" in some sense, they're also not useful. What does it mean to store the "future" of a computation in a value? 

 Operationally, we can model continuations as just a segment of control stack. This model is perhaps better suited for comprehension by programmers familiar with the implementation details of imperative programming languages, which is decidedly not my target audience. Regardless, this is how continuations (especially the delimited kind) are generally presented.

 With no offense to the authors of these articles, some of which I greatly respect as programming language designers and implementers, I do not think that this approach is very productive in a functional programming context. This reductionist, imperative view would almost be like explaining the _concept_ of a proper tail call by using a trampoline, rather than presenting trampolines as one particular implementation strategy for the tail-call-ly challenged.
 </div>
 <figure style="min-width:20%; padding-left: 12pt">
 <img class="tikzpicture" src="/diagrams/cc/delimcc.svg" />
 _Fig 1. A facsimile of a diagram you'd find attached to an explanation of delimited continuations. Newer frames on top._
 </figure>
 </div>

 In a more functional context, then, I'd like to present the concept of continuation as a _reification_ of an _evaluation context_. I stress that this presentation is not novel, though it is, perhaps, uncommon outside of the academic literature on continuations. Reification, here, is the normal English word. It's a posh way of saying "to make into a thing". For example, an `(eval)`{.scheme} procedure is a _reification_ of the language implementation---it's an interpreter made into a thing, a thing that looks, walks and quacks like a procedure.

 The idea of evaluation contexts, however, seems to have remained stuck in the ivory towers that the mainstream so often accuse us of inhabiting.

 Evaluation Contexts
 -------------------

 What _is_ an evaluation context? Unhelpfully, the answer depends on the language we're talking about. Since the language family you're most likely to encounter continuations in is Scheme, we'll use a Scheme-_like_ language (not corresponding to any of the R<sup>K</sup>RS standards). Our language has the standard set of things you'd find in a minimalist functional language used for an academic text: lambda expressions, written `(lambda arg exp)`{.scheme} that close over variables in lexical scope; applications, also n-ary, written `(func arg )`{.scheme}, `if`{.scheme}-expressions written `(if condition then else)`{.scheme}, with the `else` expression being optional and defaulting to the false value `#f`{.scheme}, integers, integer operations, and, of course, variables.

 As an abbreviation one can write `(lambda (a . args) body)` to mean `(lambda a (lambda args body))` (recursively), and similarily for applications (associating to the left), but the language itself only has unary application and currying. This is in deviation from actual Scheme implementations which have complex parameter passing schemes, including variadic arguments (collecting any overflow in a list), keyword and optional arguments, etc. While all of these features are important for day-to-day programming, they do nothing but cloud the presentation here with needless verbosity.

 ```scheme
 e ::= (lambda arg expr) ; function definitions
 | (if expr expr expr) ; if expression
 | (expr expr) ; function applications
 | var ; variables
 | #t | #f ; scheme programmers spell booleans funny
 | 1 | 2 | 3 | 4 ... ; integers
 ```

 The set of values in this miniScheme language inclues lambda expressions, the booleans `#t`{.scheme} and `#f`{.scheme}, and the integers; Every other expression can potentially take a step. Here, taking a step means applying a _reduction rule_ in the language's semantics, or finding a _congruence_ rule that allows some sub-expression to suffer a reduction rule.

 An example of reduction rule is &beta;-reduction, which happens when the function being applied is a &lambda;-abstraction and all of its arguments have been reduced to values. The rule, which says that an application of a lambda to a value can be reduced to its body in one step, is generally written in the notation of sequent calculus as below.

 <details>
 <summary>Fancy reduction rule type-set in TeX</summary>
 <noscript>Sorry, I use KaTeX for my mathematics. Read on!</noscript>
 $$\frac{}{(\lambda x.e) v \longrightarrow e\{v/x\}}$$
 </details>

 However, let's use the Lisp notation above and write reduction rules as if they were code. The notation I'm using here is meant to evoke [Redex], a tool for defining programming semantics implemented as a Racket language. Redex is really neat and I highly recommend it for anyone interested in studying programming language semantics formally.

 [Redex]: https://docs.racket-lang.org/redex/

 <!-- reduction rules -->
 <div style="display: flex; flex-direction: column; justify-content: space-around">
 <h4 style="text-align: center">Reduction rules</h4>
 <div class="mathpar">
 <div>
 ```scheme
 (--> ((lambda x e) v)
 (subst x v e))
 ```
 </div>
 <div>
 ```scheme
 (--> (if #t e_1 e_2)
 (e_1))
 ```
 </div>
 <div>
 ```scheme
 (--> (if #f e_1 e_2)
 (e_2))
 ```
 </div>
 </div>
 </div>

 These rules, standard though they may be, have a serious problem. Which, you might ask? They only apply when the expressions of interest are already fully evaluated. No rule matches for when the condition of an `if`{.scheme} expression is a function application, or another conditional; The application rule, also, only applies when the argument has already been evaluated (it's _call-by-value_, or _strict_). What can we do? Well, a simple and obvious solution is to specify _congruence_ rules that let us reduce in places of interest.

 <!-- congruence rules -->
 <div style="display: flex; flex-direction: column; justify-content: space-around">
 <h4 style="text-align: center">Congruence rules</h4>
 <div class="mathpar">
 <div>
 ```scheme
 [ (--> e_1 v)
 --------------------------
 (--> (e_1 e_2) (v e_2))]
 ```
 Evaluating in function position
 </div>
 <div>
 ```scheme
 [ (--> e_2 v)
 --------------------------
 (--> (e_1 e_2) (e_1 v))]
 ```
 Evaluating in argument position
 </div>
 <div>
 ```scheme
 [ (--> e_1 v)
 -----------------------
 (--> (if e_1 e_2 e_3)
 (if v e_2 e_3))]
 ```
 Evaluating in scrutinee position
 </div>
 </div>
 </div>

 Hopefully the problem should be clear. If it isn't, consider adding binary operators for the field operations: Each of the 4 (addition, subtraction, multiplication, division) needs 2 congruence rules, one for reducing either argument, even though they each have a single reduction rule. In general, an N-ary operator will have N congruence rules, one for each of its N operands, but only one reduction rule!

 The solution to this problem comes in the form of _evaluation contexts_. We can define a grammar of "expressions with holes", generally written as <noscript>E[·]</noscript><span class='script'>$\operatorname{E}[\cdot]$</span>, where the <noscript>·</noscript><span class='script'>$\cdot$</span> stands for an arbitrary expression. In code, we'll denote the hole with `<>`, perhaps in evocation of the macros `cut` and `cute` from SRFI 26[^1].

 Our grammar of evaluation contexts, which we'll call `E` in accordance with tradition, looks like this:

 ```scheme
 E ::= <> ; any expression can be evaluated
 | (E e) ; evaluate the function
 | (v E) ; evaluate the argument
 | (if E e e) ; evaluate the condition
 ```

 Now we can write all our congruence rules by appealing to a much simpler, and most importantly, singular, _context rule_, that says reduction is legal anywhere in an evaluation context.

 <div style="text-align: center;">
 <div style="display: inline-block; text-align: left;">
 ```scheme
 [(--> e v)
 ----------------------------------
 (--> (in-hole E e) (in-hole E v)]
 ```
 </div>
 _Redex uses the notation `(in-hole E e)` to mean an evaluation context `E` with `e` "plugging" the hole `<>`._
 </div>

 What do evaluation contexts actually have to do with programming language implementation, however? Well, if you squint a bit, and maybe introduce some parameters, evaluation contexts look a lot like what you'd find attached to an operation in...

 Continuation-passing Style
 --------------------------

 I'm not good at structuring blog posts, please bear with me.

 Continuation-passing style, also known as <span title="Child protective service- sike!" style="text-decoration: underline dotted">CPS</span>, is a popular intermediate representation for functional language compilers. The goal of CPS is to make evaluation order explicit, and to implement complex control operations like loops, early returns, exceptions, coroutines and more in terms of only lambda abstraction. To achieve this, the language is stratified into two kinds of expressions, "complex" and "atomic".

 Atomic expressions, or atoms, are not radioactive or explosive: In fact, they're quite the opposite! The Atoms of CPS are the values of our direct-style language. Forms like `#t`{.scheme}, `#f`{.scheme}, numbers and lambda expressions will not undergo any more evaluation, and thus may appear anywhere. Complex expressions are those that _do_ cause evaluation, such as conditionals and procedure application.

 To make sure that evaluation order is explicit, every complex expression has a _continuation_ attached, which here boils down to a function which receives the return value of the expression. Procedures, instead of returning to a caller, will instead tail-call their continuation.

 The grammar of our mini Scheme after it has gone CPS transformation is as follows:

 <div style="text-align: center;">
 <div style="display: inline-block; text-align: left;">
 ```scheme
 atom ::= (lambda (arg kont) expr) ; continuation argument
 | var ; these remain as they were.
 | #t | #f
 | 1 | 2 | 3 | 4
 expr ::= (atom atom atom) ; function, argument, continuation
 | (if atom expr expr) ; conditional, then_c, else_c
 | atom ; atoms are also valid expressions
 ```
 </div>
 </div>

 Note that function application now has _three_ components, but all of them are atoms. Valid expressions include things like `(f x halt)`, which means "apply `f` to `x` such that it returns to `halt`", but do _not_ include `(f (g x y) (h y z))`, which have an ambiguous reduction order. Instead, we must write a &lambda;-abstraction to give a name to the result of each intermediate computation.

 For example, the (surface) language application `(e_1 e_2)`, where both are complex expressions, has to be rewritten as either of the following expressions, which correspond respectively to evaluating the function first or the argument first. `(e_1 (lambda r1 (e_2 (lambda r2 (r1 r2))))`{.scheme}

 <div class="mathpar">
 <div>
 ```scheme
 (e_1 (lambda r_1
 (e_2 (lambda r_2
 (r_1 r_2 k)))))
 ```
 Evaluating the function first
 </div>
 <div>
 ```scheme
 (e_1 (lambda r_1
 (e_2 (lambda r_2
 (r_1 r_2 k)))))
 ```
 Evaluating the argument first
 </div>
 </div>

 If you have, at any point while reading the previous 2 or so paragraphs, squinted, then you already know where I'm going with this. If not, do it now.

 The continuation of an expression corresponds to its evaluation context. The `v`s in our discussion of semantics are the `atom`s of CPS, and most importantly, contexts `E` get closed over with a lambda expression `(lambda x E[x])`{.scheme}, replacing the hole `<>` with a bound variable `x`. Evaluating an expression `(f x)`{.scheme} in a context `E`, say `(<> v)` corresponds to `(f x (lambda x (x v)))`{.scheme}.

 If a language implementation uses the same representation for both user procedures and lambda expressions---which is **very** inefficient, let me stress---then we get first-class _control_ for "free". First-class in the sense that control operations, like `return`, can be stored in variables, or lists, passed as arguments to procedures, etc. The fundamental first-class control operator for undelimited continuations is called `call-with-current-continuation`{.scheme}, generally abbreviated to `call/cc`{.scheme}.

 <div style="text-align: center;">
 <div style="display: inline-block; text-align: left;">
 ```scheme
 (define call/cc (lambda (f cc) (f cc cc)))
 ```
 </div>
 </div>

 Using `call/cc`{.scheme} and a mutable cell holding a list we can implement cooperative threading. The `(yield)` operator has the effect of capturing the current continuation and adding it to (the end) of the list, dequeueing a potentially _different_ saved continuation from the list and jumping there instead.

 <div style="text-align: center;">
 <div style="display: inline-block; text-align: left;">
 ```scheme
 (define threads '())
 ; Jump to the next thread (read: continuation) or exit the program
 ; if there are no more threads to schedule
 (define exit
 (let ((exit exit))
 (lambda ()
 (if (null? threads) ; are we out of threads to switch to?
 (exit) ; if so, exit the program
 (let ((thr (car threads))) ; select the first thread
 (set! threads (cdr threads)) ; dequeue it
 (thr)))))))) ; jump there
 ; Add a function to the list of threads. After finishing its work,
 ; the function needs to (exit) so another thread can take over.
 (define (fork f)
 (set! threads (append threads
 (list (lambda () (f) (exit))))))
 ; Capture the current continuation, enqueue it, and switch to
 ; a different thread of execution.
 (define (yield)
 (call/cc (lambda (cc)
 (set! threads (append threads (list cc)))
 (exit))))
 ```
 </div>
 </div>

 That's a cooperative threading implementation in 25 lines of Scheme! If whichever implementation you are using has a performant `call/cc`{.scheme}, this will correspond ropughly to the normal stack switching that a cooperative threading implementation has to do.

 That last paragraph is a bit of a weasel, though. What's a "performant call/cc" look like? Well, `call/cc`{.scheme} continuations have _abortive_ behaviour[^2], which means they have the effect of _replacing_ the current thread of control when invoked, instead of prepending a segment of stack---which is known as "functional continuations". That is, it's basically a spiffed up `longjmp`{.c}, which in addition to saving the state of the registers, copies the call stack along with it.

 However, `call/cc`{.scheme} is a bit overkill for applications such as threads, and even then, it's not the most powerful control abstraction. For one `call/cc`{.scheme} _always_ copies the entire continuation, with no way to *ahem* delimit it. Because of this, abstractions built on `call-with-current-continuation`{.scheme} [do not compose].

 [do not compose]: http://okmij.org/ftp/continuations/against-callcc.html

 We can fix all of these problems, ironically enough, by adding _more_ power. We instead introduce a _pair_ operators, `prompt` and `control`, which...

 Delimit your Continuations
 --------------------------

 This shtick again?

 Delimited continuations are one of those rare ideas that happen once in a lifetime and revolutionise a field---maybe I'm exaggerating a bit. They, unfortunately, have not seen very widespread adoption. But they do have all the characteristics of one of those revolutionary ideas: they're simple to explain, simple to implement, and very powerful.

 The idea is obvious from the name, so much that it feels insulting to repeat it: instead of capturing the continuation, have a marker that _delimits_ what's going to be captured. What does this look like in our reduction semantics?

 The syntax of evaluation contexts does not change, only the operations. We gain operations `(prompt e)`{.scheme} and `(control k e)`{.scheme}, with the idea being that when `(control k e)` is invoked inside of a `(prompt)` form, the evaluation context from the `control` to the nearest outermost `prompt` is reified as a function and bound to `k`.

 <div class="mathpar">
 <div>
 ```scheme
 [-------------------
 (--> (prompt v) v)]
 ```
 Delimiting a value does nothing
 </div>
 <div>
 ```scheme
 [----------------------------------------------------------
 (--> (prompt (in-hole E (control k body)))
 (prompt ((lambda k body) (lambda x (in-hole E x)))))]
 ```
 Capture the continuation, bind it to the variable `k`, and keep going.
 </div>
 </div>

 By not adding `(prompt E)` to the grammar of evaluation contexts, we ensure that `E` is devoid of any prompts by construction. This captures the intended semantics of "innermost enclosing prompt"---if `E` were modified to include prompts, the second rule would instead capture to the _outermost_ enclosing prompt, and we're back to undelimited call/cc.

 Note that `prompt` and `control` are not the only pair of delimited control operators! There's also `shift` and `reset` (and `prompt0`/`control0`). `reset` is basically the same thing as `prompt`, but `shift` is different from `control` in that the captured continuation has the prompt—uh, the delimiter—reinstated, so that it cannot "escape".

 <div style="text-align: center;">
 <div style="display: inline-block; text-align: left;">
 ```scheme
 [-----------------------------------------------------------------
 (--> (reset (in-hole E (shift k body)))
 (reset ((lambda k body) (lambda x (reset (in-hole E x))))))]
 ```
 Reinstate the prompt when the captured continuation is applied.
 </div>
 </div>

 Yet another pair, which I personally prefer, is what you'd find in Guile's `(ice-9 control)`, namely `(call-with-prompt tag thunk handler)` and `(abort-to-prompt tag value)`. These are significantly more complex than bare `shift` and `reset` since they implement _multi-prompt_ delimited continuations. They're more like exception handlers than anything, with the addded power that your "exception handler" could restart the code after you `throw`{.java}.


 <div style="text-align: center;">
 <div style="display: inline-block; text-align: left;">
 ```scheme
 (define-syntax reset
 (syntax-rules ()
 ((reset . body)
 (call-with-prompt (default-prompt-tag)
 (lambda () . body)
 (lambda (cont f) (f cont))))))
 (define-syntax shift
 (syntax-rules ()
 ((shift k . body)
 (abort-to-prompt (default-prompt-tag)
 (lambda (cont)
 ((lambda (var) (reset . body))
 (lambda vals (reset (apply cont vals))))))
 ```
 `call-with-prompt` and `abort-to-prompt` subsume `shift` and `reset`. 
 Taken from [the Guile Scheme implementation](https://fossies.org/linux/guile/module/ice-9/control.scm).
 </div>
 </div>

 The operators `call-with-prompt` and `abort-to-prompt` are very convenient for the implementation of many control structures, like generators:

 ```scheme
 (define-syntax for/generator
 (syntax-rules ()
 ((_ name gen . body)
 (begin
 (define (work cont)
 (call-with-prompt
 'generator-tag
 cont
 (lambda (cont name) (begin . body)
 (work cont))))
 (work gen)))))
 (define (yield x) (abort-to-prompt 'generator-tag x))
 (for/generator x (lambda ()
 (yield 1)
 (yield 2)
 (yield 3))
 (display x) (display #\newline))
 ```

 Exception handlers and threading in terms of `shift` and `reset` are left as an exercise to the reader.

 But... why?
 -----------

 Control abstractions appeal to our---or at least mine---sense of beauty. Being able to implement control flow operations as part of the language is often touted as one of the superpowers that Haskell gets from its laziness and purity, and while that certainly is true, control operators let us model many, _many_ more control flow abstractions, namely those involving non-local exits and entries.

 Of course, all of these can be implemented in the language directly—JavaScript, for example, has `async`/`await`, stackless generators, _and_ exceptions. However, this is not an advantage. These significantly complicate the implementation of the language (as opposed to having a single pair of operators that's not much more complicated to implement than regular exception handlers) while also significantly _diminishing_ its expressive power! For example, using our definition of generators above, the Scheme code on the right does what you expect, but the JavaScript code on the left only yields `20`.


 <div class="mathpar">
 <div>
 ```scheme
 ((lambda ()
 ((lambda ()
 (yield 10)))
 (yield 20)))
 ```
 </div>
 <div>
 ```javascript
 (function*() {
 (function*() {
 yield 10;
 })
 yield 20;
 })();
 ```
 </div>
 </div>

 Delimited continuations can also be used to power the implementation of algebraic effects systems, such as those present in the language Koka, which much lower overhead (both in terms of code size and speed) than the type-driven local CPS transformation that Koka presently uses.

 Language implementations which provide delimited control operators can also be extended with effect system support post-hoc, in a library, with an example being the [Eff] library for Haskell and the associated [GHC proposal] to add delimited control operators (`prompt` and `control`).

 [Eff]: https://github.com/hasura/eff
 [GHC proposal]: https://github.com/ghc-proposals/ghc-proposals/pull/313/

 [^1]: In reality it's because I'm lazy and type setting so that it works properly both with KaTeX and with scripting disabled takes far too many keystrokes. Typing some code is easier.

 [^2]: People have pointed out to me that "abortive continuation" is a bit oxymoronic, but I guess it's been brought to you by the same folks who brought you "clopen set".
--- a/pages/posts/2020-09-09-typing-proof.md
+++ b/pages/posts/2020-09-09-typing-proof.md
@ -0,0 +1,162 @@
 ---
 title: "This Sentence is False, or: On Natural Language, Typing and Proof"
 date: September 9th, 2020
 ---

 The Liar's paradox is often the first paradox someone dealing with logic, even in an informal setting, encounters. It is _intuitively_ paradoxical: how can a sentence be both true, and false? This contradicts (ahem) the law of non-contradiction, that states that "no proposition is both true and false", or, symbolically, $\neg (A \land \neg A)$. Appealing to symbols like that gives us warm fuzzy feelings, because, _of course, the algebra doesn't lie!_

 There's a problem with that the appeal to symbols, though. And it's nothing to do with non-contradiction: It's to do with well-formedness. How do you accurately translate the "this sentence is false" sentence into a logical formula? We can try by giving it a name, say $L$ (for liar), and state that $L$ must represent some logical formula. Note that the equality symbol $=$ here is _not_ a member of the logic we're using to express $L$, it's a symbol of this discourse. It's _meta_logical.

 $$ L = \dots $$

 But what should fill in the dots? $L$ is the sentence we're symbolising, so "this sentence" must mean $L$. Saying "X is false" can be notated in a couple of equivalent ways, such as $\neg X$ or $X \to \bot$. We'll go with the latter: it's a surprise tool that will help us later. Now we know how to fill in the dots: It's $L \to \bot$.

 <details>
 <summary>Truth tables demonstrating the equivalence between $\neg A$ and $A \to \bot$, if you are classically inclined.</summary>
 <div class="mathpar">
 <table>
 <tr>
 <th> $A$ </th>
 <th> $\neg A$ </th>
 </tr>
 <tr><td>$\top$</td><td>$\bot$</td></tr>
 <tr><td>$\bot$</td><td>$\top$</td></tr>
 </table>
 <table>
 <tr>
 <th> $A$ </th>
 <th> $A\to\bot$ </th>
 </tr>
 <tr><td>$\top$</td><td>$\bot$</td></tr>
 <tr><td>$\bot$</td><td>$\top$</td></tr>
 </table>
 </div>
 </details>

 But wait. If $L = L \to \bot$, then $L = (L \to \bot) \to \bot$, and also $L = ((L \to \bot) \to \bot) \to \bot$, and so... forever. There is no finite, well-formed formula of first-order logic that represents the sentence "This sentence is false", thus, assigning a truth value to it is meaningless: Saying "This sentence is false" is true is just as valid as saying that it's false, both of those are as valid as saying "$\neg$ is true".

 Wait some more, though: we're not done. It's known, by the [Curry-Howard isomorphism], that logical systems correspond to type systems. Therefore, if we can find a type-system that assigns a meaning to our sentence $L$, then there _must_ exist a logical system that can express $L$, and so, we can decide its truth!

 Even better, we don't need to analyse the truth of $L$ logically, we can do it type-theoretically: if we can build an inhabitant of $L$, then it is true; If we can build an inhabitant of $\neg L$, then it's false; And otherwise, I'm just not smart enough to do it.

 So what is the smallest type system that lets us assign a meaning to $L$?

 # A system of equirecursive types: $\lambda_{\text{oh no}}$[^1]

 [^1]: The reason for the name will become obvious soon enough.

 We do not need a complex type system to express $L$: a simple extension over the basic simply-typed lambda calculus $\lambda_{\to}$ will suffice. No fancy higher-ranked or dependent types here, sorry!

 As a refresher, the simply-typed lambda calculus has _only_:

 * A set of base types $\mathbb{B}$,
 * Function types $\tau \to \sigma$,
 * For each base type $b \in \mathbb{B}$, a set of base terms $\mathbb{T}_b$,
 * Variables $v$,
 * Lambda abstractions $\lambda v. e$, and
 * Application $e\ e'$.

 <details>
 <summary>Type assignment rules for the basic $\lambda_{\to}$ calculus.</summary>
 <div class="math-paragraph">
 <div>
 $$\frac{x : \tau \in \Gamma}{\Gamma \vdash x : \tau}$$
 </div>
 <div>
 $$\frac{b \in \mathbb{B} \quad x \in \mathbb{T}_{b}}{\Gamma \vdash x : b}$$
 </div>
 <div>
 $$\frac{\Gamma, x : \sigma \vdash e : \tau}{\Gamma \vdash \lambda x. e : \sigma \to \tau}$$
 </div>
 <div>
 $$\frac{\Gamma, e : \sigma \to \tau \quad \Gamma \vdash e' : \sigma}{\Gamma \vdash e\ e' : \tau}$$
 </div>
 </div>
 </details>

 First of all, we'll need a type to represent the logical proposition $\bot$. This type is empty: It has no type formers. Its elimination rule corresponds to the principle of explosion, and we write it $\mathtt{absurd}$. The inference rule:

 <div class="math-paragraph">
 $$\frac{\Gamma \vdash e : \bot}{\mathtt{absurd}\ e : A}$$
 </div>

 We're almost there. What we need now is a type former that serves as a solution for equations of the form $v = ... v ...$. That's right: we're just _inventing_ a solution to this class of equations---maths!

 These are the _equirecursive_ types, $\mu a. \tau$. The important part here is _equi_: these types are entirely indistinguishable from their unrollings. Formally, we extend the set of type formers with type variables $a$ and $\mu$-types $\mu a. \tau$, where $\mu a$ acts as a binder for $a$.

 Since we invented $\mu$ types as a solution for equations of the form $a = \tau$, we have that $\mu a. \tau = \tau[\mu a.\tau/a]$, where $\tau[\sigma{}/a]$ means "substitute $\sigma{}$ everywhere $a$ occurs in $\tau$". The typing rules express this identity, saying that anywhere a term might have one as a type, the other works too:

 <div class="math-paragraph">
 <div>
 $$\frac{\Gamma \vdash e : \tau[\mu a.\tau / a]}{\Gamma \vdash e : \mu a. \tau}$$
 </div>
 <div>
 $$\frac{\Gamma \vdash e : \mu a.\tau}{\Gamma \vdash e : \tau[\mu a. \tau / a]}$$
 </div>
 </div>

 Adding these rules, along with the one for eliminating $\bot$, to the $\lambda_{\to}$ calculus nets us the system $\lambda_{\text{oh no}}$. With it, one can finally formulate a representation for our $L$-sentence: it's $\mu a. a \to \bot$.

 There exists a closed term of this type, namely $\lambda k. k\ k$, which means: The "this sentence is false"-sentence is true. We can check this fact ourselves, or, more likely, use a type checker that supports equirecursive types. For example, OCaml with the `-rectypes` compiler option does.

 We'll first define the empty type `void` and the type corresponding to $L$:

 <div class="math-paragraph">
 ~~~~{.ocaml}
 type void ;;
 type l = ('a -> void) as 'a ;;
 ~~~~
 </div>

 Now we can define our proof of $L$, called `yesl`, and check that it has the expected type:

 <div class="math-paragraph">
 ~~~~{.ocaml}
 let yesl: l = fun k -> k k ;;
 ~~~~
 </div>

 However. This same function is also a proof that... $\neg L$. Check it out:

 <div class="math-paragraph">
 ~~~~{.ocaml}
 let notl (x : l) : void = x x ;;
 ~~~~
 </div>

 # I am Bertrand Russell

 Bertrand Russell (anecdotally) once proved, starting from $1 = 0$, that he was the Pope. I am also the Pope, as it turns out, since I have on hand a proof that $L$ and $\neg L$, in violation of non-contradiction; By transitivity, I am Bertrand Russell. <span style="float: right; display: inline-block;"> $\blacksquare$ </span>

 Alright, maybe I'm not Russell (drat). But I am, however, a trickster. I tricked you! You thought that this post was going to be about a self-referential sentence, but it was actually about typed programming language design (not very shocking, I know). It's a demonstration of how recursive types (in any form) are logically inconsistent, and of how equirecursive types _are wrong_.

 The logical inconsistency, we all deal with, on a daily basis. It comes with Turing completeness, and it annoys me to no end every single time I accidentally do `let x = ... x ...`{.haskell}. I _really_ wish I had a practical, total functional programming language to use for my day-to-day programming, and this non-termination _everywhere_ is a great big blotch on Haskell's claim of purity.

 The kind of recursive types you get in Haskell is _fine_. They're not _great_ if you like the propositions-as-types interpretation, since it's trivial to derive a contradiction from them, but they're good enough for programming that implementing a positivity checker to ensure your definitions are strictly inductive isn't generally worth the effort.

 Unless your language claims to have "zero runtime errors", in which case, if you implement isorecursive types instead of inductive types, you are _wrong_. See: Elm. God damn it.

 <details>
 <summary>So much for "no runtime errors"... I guess spinning forever on the client side is acceptable.</summary>
 <div class="flex-list">

 ```elm
 -- Elm
 type Void = Void Void
 type Omega = Omega (Omega -> Void)

 yesl : Omega
 yesl = Omega (\(Omega x) -> x (Omega x))

 notl : Omega -> Void
 notl (Omega x) = x (Omega x)
 ```

 </div>
 </details>

 Equirecursive types, however, are a totally different beast. They are _basically_ useless. Sure, you might not have to write a couple of constructors, here and there... at the cost of _dramatically_ increasing the set of incorrect programs that your type system accepts. Suddenly, typos will compile fine, and your program will just explode at runtime (more likely: fail to terminate). Isn't this what type systems are meant to prevent?

 Thankfully, very few languages implement equirecursive types. OCaml is the only one I know of, and it's gated behind a compiler flag. However, that's a footgun that should _not_ be there.

 [Curry-Howard isomorphism]: https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
--- a/pages/posts/2020-10-30-reflecting-equality.md
+++ b/pages/posts/2020-10-30-reflecting-equality.md
@ -0,0 +1,264 @@
 ---
 title: Reflections on Equality
 date: November 1st, 2020
 ---

 When shopping for a dependent type theory, many factors should be taken into consideration: how inductive data is represented (inductive schemas vs W-types), how inductive data _computes_ (eliminators vs case trees), how types of types are represented (universes à la Tarski vs à la Russell). However, the most important is their treatment of equality.

 Conor McBride, a prominent figure in type theory research, noted in [a reddit comment] that you should never trust a type theorist who has not changed their mind about equality (I'm paraphrasing). Recently, I've embarked on a journey to improve my credibility (or, at least, get out of the "instantly discarded opinion" pool): I've changed my mind about equality. 

 # What's the fuss about?

 Equality is very prevalent when using dependently typed languages, whether as frameworks for writing mathematical proofs or for writing verified computer programs. Most properties of mathematical operators are expressed as equalities which they should respect. For example, a semigroup is a set $S$ with an _associative_ $\times$ operator. The property of associativity just means the operator respects the equality $a \times (b \times c) \equiv (a \times b) \times c$!

 However, the equality relation which can be expressed with proofs is not the only equality which a dependently-typed system needs to consider. There's also the _judgemental_ equality, that is, which terms are always identified independently of their semantics. For example, $a + b$ and $b + a$ are _propositionally_ equal, which can be shown by writing an inductive proof of this fact, but they're _judgmentally_ different, because they have different term structure.

 There are two 'main' traditions of Martin-Löf dependent type theory: the intensional type theories are as in the paragraph above, but the extensional type theories make me a liar. Extensional type theory is obtained by adding a rule of _equality reflection_, which collapses the distinction between propositional and judgemental equality: whenever there exists a proof of an equality between terms $x$ and $y$, they're considered judgmentally equal.

 Adding equality reflection makes a type system more expressive with respect to equality: for example, in extensional type theories, one can derive the rule of _function extensionality_, which says two functions are equal when they are equal pointwise. However, equality reflection also makes a type system _less_ expressive with respect to equality: there is only one way for two things to be equal!

 Moreover, equality reflection complicates _type checking_ to an unacceptable degree. Rather than being able to check the validity of a proof by comparing a term against a known type, an entire typing derivation is necessary as input to the type checker. To see why, consider the following derivation:

 <figure>
 <div>
 $$
 \cfrac{
 \cfrac{
 \cfrac{}{\mathop{\mathop{\vdash}} (+) \mathop{:} \mathbb{N} \to \mathbb{N} \to \mathbb{N}}
 \quad
 \cfrac{
 \text{no} \mathop{:} \bot\ \mathop{\mathop{\vdash}} \mathtt{"foo"} \mathop{:} \text{Str}
 \quad
 \cfrac{
 \cfrac{
 \text{no} \mathop{:} \bot\ \mathop{\mathop{\vdash}} \text{no} \mathop{:} \bot
 }{
 \text{no} \mathop{:} \bot\ \mathop{\mathop{\vdash}} \mathrm{absurd}(\text{no}) \mathop{:} \text{Str} \equiv \mathbb{N}
 }
 }{ \text{no} \mathop{:} \bot\ \mathop{\mathop{\vdash}} \text{Str} = \mathbb{N} }
 }{ \text{no} \mathop{:} \bot\ \mathop{\mathop{\vdash}} \mathtt{"foo"} \mathop{:} \mathbb{N} }
 \quad
 \cfrac{}{\mathop{\mathop{\vdash}} 2 \mathop{:} \mathbb{N}}
 }{ \text{no} \mathop{:} \bot \mathop{\mathop{\vdash}} (2 + \mathtt{"foo"}) \mathop{:} \mathbb{N} }
 }{ \mathop{\mathop{\vdash}} \lambda \text{no} \to (2 + \mathtt{"foo"}) : \bot \to \mathbb{N} }
 $$
 </div>
 <figcaption>If the context contains an element of the empty type, every term needs to be accepted</figcaption>
 </figure>

 Here, the context contains an element of the empty type, written $\bot$. It's _comparatively_ easy for the type checker to see that in this case, the context we're working under is absurd, and any equality should be accepted. However, there are many such empty types: $\mathrm{Fin}(0)$, for example. Consider the type family $\mathrm{SAT}$, indexed by a Boolean clause, such that $\mathrm{SAT}(c)$ reduces to $\top$ when $c$ is satisfiable and $\bot$ otherwise. How would you type-check the program $\lambda x \to 2 + \mathtt{"foo"}$ at type $\mathrm{SAT}(c) \to \mathbb{N}$, where $c$ is some adversarially-chosen, arbitrarily complex expression? How would you type check it at type $\mathrm{Halts}(m) \to \mathbb{N}$?

 In contrast, Intensional Type Theory, or ITT for short, treats equality as if it were any other type. In ITT, equality is inductively generated by the constructor $\mathrm{refl}_x$ for any element $x$ of a type $A$, which leads to an induction principle saying that, if

 - $A$ is a type, and
 - $C$ is a proposition indexed by $x, y : A$ and $p : x \equiv_{A} y$, and
 - $p_{\mathrm{refl}}$ is a proof of $C(x, x, \mathrm{refl_{x}})$, then

 we can deduce, for all $x, y : A$ and $p : x \equiv_{A} y$, that $C(x, y, p)$ holds.

 Given this operator, generally called axiom J (since "J" is the letter after **I**dentity, another word for "equality"), we can derive many of the properties of equality: transitivity (given $x \equiv y$ and $y \equiv z$, get $x \equiv z$) and symmetry (given $x \equiv y$, get $y \equiv x$) make $\equiv$ an _equivalence relation_, and substitutivity (assuming $P(x)$ and $x \equiv y$, get $P(y)$) justifies calling it "equality".

 However, axiom J is both weaker _and_ stronger than equality reflection: for one, it doesn't let us prove that functions are equal when they are pointwise equal, which leads to several complications. However, it also doesn't let us prove that all equalities are equal to $\mathrm{refl}$, which lets us strengthen equality by postulating, for example,

 ## The univalence axiom of Voevodsky

 The "tagline" for the univalence axiom, which lies at the center of Homotopy Type Theory (HoTT), is that "equality is equivalent to equivalence". More specifically, given a function $f : A \to B$, together with a proof that $f$ has left and right inverses, univalence gives us an equality $\mathrm{ua}(f)$ such that transporting "along" this path is the same as applying $f$.

 For example, we could define the "usual" unary naturals $\mathbb{N}$ (which are easy to use for proving but terrible computationally) and _binary_ naturals $\mathbb{N}_2$ (which have more efficient computational behaviour at the cost of more complicated structure), demonstrate an equivalence $\mathrm{peano2Binary} : \mathbb{N} \cong \mathbb{N}_2$, then *transport* proofs about $\mathbb{N}$ to proofs about $\mathbb{N}_2$!

 A [recent paper] by Tabareau et al explores the consequences of strengthening a type theory with univalence together with _parametricity_, unlocking efficient and _automated_ (given the equivalence) transport between algebraic structures of types.

 <details>
 <summary> A note on terminology </summary>
 The HoTT interpretation of "types as topological spaces" leads us to interpret the type of equalities as the type of _paths_ in a space. From this, we get some terminology: instead of saying "cast $x$ with the equality $e$", we can equivalently say "transport $x$ along the path $p$".

 Using the "path" terminology in a context with unicity of equality proofs is a bit misleading, but the terminology does not break down (a set-truncated system is just one where all paths are loops). Because of this, I'll use "path" and "equality" interchangeably. Sorry if this causes any confusion.
 </details>

 The undecidability of type checking ETT and the comparative weakness of ITT has led _many_ researchers to consider the following question:

 > Can we have: 
 > 
 > * Decidable type checking 
 > * A "more extensional" equality 
 > * Good computational behaviour 
 > 
 > All at the same time?

 Turns out, the answer is yes!

 # Observational Equality

 One early positive answer is that of Observational Type Theory, presented in [a 2007 paper] by Altenkirch, McBride, and Swierstra. The basic idea is that, instead of defining the type $a \equiv_{A} b$ as an inductive family of types, we define it so that equality _computes_ on the structure of $A$, $a$ and $b$ to _reduce_ to tractable forms. Observational type theory (OTT, from now on) has two _universes_ (types whose elements are types), $\mathrm{Prop}$ and $\mathrm{Set}$, such that $\mathrm{Prop} : \mathrm{Set}$ and $\mathrm{Set} : \mathrm{Set}$[^1]

 The elements of $\mathrm{Prop}$ are taken to be _propositions_, not in the sense of propositions-as-types, but in the sense of HoTT. Propositions are the types $T$ for which, given $x, y : T$, one has $x \equiv y$: they're types with at most one element. Some propositions are $\top$, the trivially true proposition, and $\bot$, the empty proposition.

 Given $A : u$, and some $B : v$ with one variable $x : A$ free (where $u$ and $v$ are possibly distinct universes), we can form the type $\prod_{x : A} B$ of _dependent products_ from $A$ to $B$. If $v$ is in $\mathrm{Prop}$, then the dependent product also lives in $\mathrm{Prop}$. Otherwise, it lives in $\mathrm{Set}$. Moreover, we can also form the type $\sum_{x : A} B$ of _dependent sums_ of $A$ and $B$, which always lives in $\mathrm{Set}$.

 Given a type $A$ and two elements $a, b : A$, we can form the _proposition_ $a \equiv_{A} b$. Note the emphasis on the word proposition here! Since equivalence is a proposition, we have uniqueness of equality proofs by definition: there's at most one way for things to be equal, conflicting with univalence. So we get _some_ extensionality, namely of functions, but not for arbitrary types. Given types <span class=together>$A$ and $B$,</span> a proof $p : A \equiv B$ and $x : A$, we have the term $\mathrm{coe}(A, B, P, x) : B$, which represents the *coe*rcion of $x$ along the path $p$.

 Here is where my presentation of observational equality starts to differentiate from the paper's: McBride et al use _heterogeneous_ equality, i.e. a 4-place relation $(x : A) \equiv (y : B)$, where $A$ and $B$ are potentially distinct types. But! Their system only allows you to _use_ an equality when $A \equiv B$. The main motivation for heterogeneous equality is to "bunch up" as many equalities as possible to be eliminated all in one go, since coercion in their system does not compute. However, if coercion computes normally, then we don't need to do this "bunching": one can just use coercion normally.

 The key idea of OTT is to identify as "equal" objects which support the same _observations_: for functions, observation is _application_; for pairs, it's projection, etc. This is achieved by making the definition of equality acts as a "pattern matching function" on the structure of terms and types. For example, there is a rule which says an equality between functions is a function that returns equalities:

 <figure>
 <div>
 $$
 \cfrac{}{f \equiv_{(x : A) \to B(x)} g \longrightarrow (x : A) \to (f\ x) \equiv_{B(x)} (g\ x)}
 $$
 </div>
 <figcaption>Equality of functions is extensional by definition</figcaption>
 </figure>

 So, not only do we have a term `funext` of type `((x : A) → f x == g x) → f == g` but one with a stronger type, namely `((x : A) → f x == g x) == (f == g)`, and that term is.. `refl`!

 OTT is appropriate, in my opinion, for doing set-level mathematics: where types have no "interesting" equality structure. However, it breaks down at higher _h_-levels, where there is interesting structure to be found in the equalities between elements of types. This is because OTT, by placing the $\equiv$ type in its universe of propositions, validates the principle of uniqueness of identity proofs, which says any two proofs of the same equality are themselves equal. UIP conflicts with the univalence axiom of Homotopy Type Theory, by (to use the HoTT terminology) saying that all types are sets.

 <span class="theorem paragraph-marker">**Theorem**</span>. Suppose there exists one universe, $\mathscr{U}$, which contains the type of Booleans. Assuming univalence, the type $a \equiv_{\mathscr{U}} b$ is not a proposition.

 <span class="paragraph-marker">**Proof**</span>. The function $\mathrm{not} : 2 \to 2$, which maps $\mathtt{tt}$ to $\mathtt{ff}$ and vice-versa, is an equivalence, being its own left and right inverses. Thus, by univalence, we have a path $\mathrm{ua}(\mathrm{not}) : 2 \equiv_{\mathscr{U}} 2$.

 To see that this path is different from $\mathrm{refl}_2$, consider its behaviour with respect to transport: $\mathrm{transp}(\mathrm{refl}_2, \mathtt{tt}) \equiv tt$ but $\mathrm{transp}(\mathrm{ua}(\mathrm{not}), \mathtt{tt}) \equiv \mathtt{ff}$. Since $\mathtt{tt}$ is different from $\mathtt{ff}$, it follows that $\mathrm{ua}(\mathrm{not})$ is different from $\mathrm{refl}_2$. <span class=qed>$\blacksquare$</span>

 So, if having univalence is desirable, OTT is off the table. However, the previous example of transporting proofs between equivalent types of natural numbers might not have convinced you that HoTT is indeed an interesting field of study, and univalence might seem mostly like a novelty, a shiny thing to pursue for its own sake (it certainly did to me, at first). So why _is_ HoTT interesting?

 # HoTT

 Between 2012 and 2013, a special year of research took place in the Institute for Advanced Studies to develop a type theory that can be used as a foundation for mathematics "at large". Their result: the book *Homotopy Type Theory: Univalent Foundations for Mathematics*. The IAS Special Year on Univalent Foundations would have been interesting even if it hadn't started a new branch of type theory, just from the participants: Thierry Coquand, Thorsten Altenkirch, Andrej Bauer, Per Martin-Löf and, of course, the late Vladimir Voevodsky.

 HoTT's main contribution to the field, in my (lay) opinion, is the interpretation of _types as spaces_: by interpreting types as homotopy theoretical spaces, a semantics for types with more interesting "equality structure", so to speak, arises. In the "classical" intensional type theory of Agda and friends, and indeed the theory of OTT commented on above, equality is a _proposition_. Agda (without the `--without-K` option) accepts the following proof:

 ```agda
 uip : (A : Set) (x y : A) (p q : x ≡ y) → p ≡ q
 uip A x .x refl refl = refl
 ```

 Apart from ruling out univalence, UIP rules out another very interesting class of types which can be found in HoTT: the _higher inductive_ types, which contain constructors for _equalities_ as well as for values.

 The simplest higher inductive type is the interval, which has two "endpoints" (`i0` and `i1`) and a path between them:

 ```agda
 data I : Type where
 i0 i1 : I
 seg : i0 ≡ i1
 ```

 The names $i_0$, $i_1$ and $\mathrm{seg}$ were chosen to remind the reader of a line *seg*ment between a pair of points. Therefore, we may represent the type $\mathbb{I}$ as a diagram, with discrete points representing $i_0$ and $i_1$, and a line, labelled $\mathrm{seg}$, connecting them.

 <figure>
 <img style="height: 90px" src="/diagrams/eq/interval.svg" />
 <figcaption>A diagrammatic representation of the type `I`</figcaption>
 </figure>

 The real power of the `I` type comes from its induction principle, which says that, given a proposition $P : \mathbb{I} \to \mathrm{Type}$, if:

 * There exists a pair of proofs $pi_0 : P(i_0)$ and $pi_1 : P(i_1)$, and
 * $pi_0$ and $pi_1$ are equal "with respect to" the path $\mathrm{seg}$, then

 $P$ holds for every element of the interval. However, that second constraint, which relates the two proofs, needs a bit of explaining. What does it mean for two elements to be equal with respect _to a path_? Well, the "obvious" interpretation would be that we require a proof $p\mathrm{seg} : pi_0 \equiv pi_1$. However, this isn't well-typed! The type of $pi_0$ is $P(i_0)$ and the type of $pi_1$ is $P(i_1)$, so we need a way to make them equal.

 This is where the path $\mathrm{seg}$ comes in to save the day. Since it states $i_0$ and $i_1$ are equal, we can transport the proof $pi_0$ _along_ the path $\mathrm{seg}$ to get an inhabitant of the type $P(i_1)$, which makes our desired equality $pi_0$ between $pi_1$ _with respect to_ $\mathrm{seg}$ come out as $\mathrm{transp}(P, \mathrm{seg}, pi_0) \equiv pi_1$, which _is_ well-typed.

 That's fine, I hear you say, but there is a question: how is the interval type _useful_? It certainly looks as though if it were useless, considering it's just got one element pretending to be two! However, using the interval higher inductive type, we can actually _prove_ functional extensionality, the principle that says two functions are equal when they're equal pointwise, everywhere. The proof below can be found, in a more presentable manner, in [the HoTT book], section 6.3.

 <span class="theorem paragraph-marker">**Theorem**</span>. If $f$ and $g$ are two functions between $A$ and $B$ such that $f(x) \equiv g(x)$ for all elements $x : A$, then $f \equiv g$.

 <span class="paragraph-marker">**Proof**</span>. Call the proof we were given $p : \prod_{(x : A)} f(x) \equiv g(x)$ We define, for all $x : A$, the function $p^\prime_{x} : \mathbb{I} \to B$ by induction on $I$. Let $p^\prime_{x}(i_0) = f(x)$, $p^\prime_{x}(i_1) = g(x)$. The equality between these terms is given by $p^\prime_{x}(\mathrm{seg}) = p(x)$.

 Now, define $q : \mathbb{I} \to A \to B$ by $q(i) = \lambda x. p^\prime_x(i)$. We have that $q(i_0)$ is the function $\lambda x. p^\prime_{x}(i_0)$, which is defined to be $\lambda x. f(x)$, which is $\eta$-equal to $f$. Similarly, $q(i_1)$ is equal to $g$, and thus, $q(\mathrm{seg}) : f \equiv g$. <span class="qed">$\blacksquare$</span>

 Isn't that _cool_? By augmenting our inductive types with the ability to additionally specify equalities between elements, we get a proof of function extensionality! I think that's pretty cool. Of course, if HITs were limited to structures like the interval, spheres, and other abstract mathematical things, they wouldn't be very interesting for programmers. However, the ability to endow types with additional equalities is _also_ useful when doing down-to-earth programming! A [2017 paper] by Basold et al explores three applications of HITs to programming, in addition to containing an accessible introduction to HoTT in general.

 Another very general higher inductive type, one that might be more obviously useful, is the general type of _quotients_. Whenever $A$ is a type and $R$ is a binary, _propositional_ relation between members of $A$, we can form the quotient type $A/R$, which is given by the following constructors[^2]:

 * $\mathrm{intro}$ says that, for each $x : A$, we can make an element of $A/R$, and
 * $\mathrm{quot}$ which gives, for each $x, y : A$ which are related by $R$, an equality between $\mathrm{intro}(x)$ and $\mathrm{intro}(y)$.

 The induction principle for quotients, which is far too complicated to include here (but can be derived mechanically from the specification given above and the knowledge of "equal with respect to some path" from the section on the interval), says roughly that we can pattern-match on $A/R$ if and only the function we're defining does not distinguish between elements related by $R$.

 This type is very general! For example, given a type of naturals $\mathbb{N}$ and a two-place relation $\mathrm{mod2}$ which holds for numbers congruent modulo 2, we can form the quotient type $\mathbb{N}/\mathrm{mod2}$ of naturals mod 2. Functions (say, $f$) defined on this type must then respect the relation that, whenever $x \equiv y \mod 2$, $f(x) \equiv f(y)$.

 All of this talk about HoTT, and in fact the book itself, though, neglected to mention one thing. What is the _computational content_ of the univalence axiom? What are the reduction rules for matching on higher inductive types? How do we take a proof, written in the language of HoTT, and run it? The Book does not address this, and in fact, it's still a half-open problem, and has been since 2013. Computing in the presence of all these paths, paths between paths, ad infinitum is mighty complicated.

 # Cubical TT

 The challenge of making a computational HoTT did not stop Cohen et al, who in [a 2016 paper] presented _Cubical Type Theory_, which, after three years of active research, provides a way to compute in the presence of univalence. There's just one problem, though: cubical type theory is _hella complicated_.

 The core idea is simple enough: we extend type theory with a set of names $\mathbb{I}$, with points $0$ and $1$ and operations $\vee$, $\wedge$, and $1 - r$, which behave like a de Morgan algebra. To represent equalities, the type $\mathrm{Path}\ A\ t\ u$ is introduced, together with a "name abstraction" operation $\langle i \rangle\ t$ and "path application" $t\ r$, where $r$ is an element of the interval.

 <div class="mathpar">
 <figure>
 <div>
 $$
 \frac{\Gamma, i : \mathbb{I} \vdash t : A}{\Gamma \vdash \langle i \rangle\ t : \mathrm{Path}\ A\ t[0/i]\ t[1/i]}
 $$
 </div>
 </figure>
 <figcaption>Path formation</figcaption>
 <figure>
 <div>
 $$
 \frac{\Gamma, t : \mathrm{Path}\ A\ a\ b\quad\Gamma \vdash r : \mathbb{I}}{\Gamma \vdash t\ r : A}
 $$
 </div>
 </figure>
 <figcaption>Path elimination</figcaption>
 </div>

 The intuition, the authors say, is that a term with $n$ variables of $\mathbb{I}$-type free corresponds to an $n$-dimensional cube.

 <table>
 <tr>
 <td>$\cdot \vdash A : \mathrm{Type}$</td>
 <td class=image><img style="height: 30px;" alt="0 dimensional cube" src="/diagrams/eq/0cube.svg" /></td>
 </tr>
 <tr>
 <td>$i : \mathbb{I} \vdash A : \mathrm{Type}$</td>
 <td class=image><img style="height: 32px;" alt="1 dimensional cube" src="/diagrams/eq/1cube.svg" /></td>
 </tr>
 <tr>
 <td>$i, j : \mathbb{I} \vdash A : \mathrm{Type}$</td>
 <td class=image><img style="height: 120px;" alt="2 dimensional cube" src="/diagrams/eq/2cube.svg" /></td>
 </tr>
 </table>

 This is about where anyone's "intuition" for Cubical Type Theory, especially my own, flies out the window. Specifically, using abstraction and the de Morgan algebra on names, we can define operations such as reflexivity ($\langle i \rangle a : \mathrm{Path}\ A\ a\ a$), symmetry ($\lambda p. \langle i \rangle p\ (1 - i) : \mathrm{Path}\ A\ a\ b \to \mathrm{Path}\ A\ b\ a$), congruence, and even function extensionality, which has a delightfully simple proof: $\lambda p. \langle i \rangle\ \lambda x. p\ x\ i$.

 However, to transport along these paths, the paper defines a "face lattice", which consists of constraints on elements of the interval, uses that to define "systems", which are arbitrary restrictions of cubes; From systems, one can define "composition", which compute the lid of an open box (yeah, I don't get it either), "Kan filling", and finally, transport. Since the authors give a semantics of Cubical Type Theory in a previously well-established model of cubical sets, I'll just.. take their word on this.

 The [Cubical Agda documentation] has a section explaining a generalised transport operation `transp` and the regular transport operation `transport`. I recommend that you go check _that_ out, since explaining each is beyond my powers. However, this transport operation _does_ let us prove that the J induction principle for equalities also holds for these cubical paths, and from that we can define all of the other nice operations!

 Cubical Agda, a proof assistant based on Cubical Type Theory, exports a library which provides all of HoTT's primitive notions (The identity type, transport, the J rule, function extensionality, univalence), that compute properly. Furthermore, it supports higher inductive types! However, as I understand it, these can not be compiled into an executable program yet. This is because the `transp` operation, fundamental to computation in the presence of path types, is defined on the structure of the type we're transporting over, and type structure is not preserved when compiling.

 # So What?

 Even after all this explanation of fancy equality relations, you might still be unconvinced. I certainly was, for a while. But I'd argue that, if you care about typed programming enough to be interested in dependent types _at all_, you should be interested in, at least, the quotient inductive types of OTT, if not the more general higher inductive types of HoTT.

 The reason for this is simple: inductive types let you restrict how elements of a type are _formed_. Quotient inductive types let you restrict, in a principled way, how elements of a type are _used_. Whereas in languages without quotients, like Haskell or even non-cubical Agda, one is forced to use the module system to hide the inductive structure of a type if they wish to prevent unauthorized fiddling with structure, in a language with quotients, we can have the type checker enforce, internally, that these invariants are maintained.

 Just like quantitative type theory gives programmers a way to reason about resource usage, and efficiently implement mutable structures in a referentially-transparent way, I strongly believe that quotient types, and even univalent parametricity (when we figure out how to compile that) are the "next step forward" in writing reliable software using types as a verification method.

 However, dependent types are not the only verification method! Indeed, there are a number of usability problems to solve with dependent types for them to be adopted by the mainstream. A grim fact that everyone who wants reliable software has to face every day is that most programmers are out there using _JavaScript_, and that the most popular typed language released recently is _Go_.[^3]

 So I leave you, dear reader, with this question: what can we do, as researchers and implementors, to make dependently typed languages more user-friendly? If you are not a researcher, and you have tried a dependently typed language, what are pain points you have encountered? And if you haven't used a dependently typed language, why not?

 <div class="special-thanks">
 With special thanks to

 * [My friend V for helping with my supbar my English](https://anomalous.eu/)
 * [My friend shikhin for proof-reading the mathematics.](https://twitter.com/idraumr)
 </div>

 [^1]: This is a simplified presentation that uses a single, inconsistent universe (Girard's paradox applies). The actual presentation uses a stratified, predicative hierarchy of $\mathrm{Set}_i$ universes to avoid this paradox.

 [^2]: The presentation of quotients in the HoTT book also contains a _0-truncation_ constructor, which has to do with limiting quotients to work on sets only. The details are, IMO, out of scope for this post; So check out section 6.10 of the book to get all of them.

 [^3]: Please read the italics on this paragraph as derision.

 [a 2007 paper]: http://www.cs.nott.ac.uk/~psztxa/publ/obseqnow.pdf
 [2017 paper]: https://www.researchgate.net/publication/315794623_Higher_Inductive_Types_in_Programming
 [recent paper]: https://arxiv.org/abs/1909.05027
 [a 2016 paper]: https://arxiv.org/abs/1611.02108
 [a reddit comment]: https://www.reddit.com/r/haskell/comments/y8kca/generalizednewtypederiving_is_very_very_unsafe/c5tawm8/
 [the HoTT book]: https://homotopytypetheory.org/book/
 [Cubical Agda documentation]: https://agda.readthedocs.io/en/v2.6.0/language/cubical.html
--- a/pages/posts/2021-01-15-induction.md
+++ b/pages/posts/2021-01-15-induction.md
@ -0,0 +1,637 @@
 ---
 title: On Induction
 date: January 15th, 2021
 ---

 <!--
 battle plan:
 - motivate induction via lists
 - close enough to naturals that we can appeal to people's intuition about those
 - a general schema for normal induction (easy enough)
 - handwave about induction-induction (some syntax?) and induction-recursion (a universe?)
 - handwave quotient & higher induction-induction
 -->

 [Last time] on this... thing... I update _very occasionally_, I talked about possible choices for representing equality in type theory. Equality is very important, since many properties of programs and mathematical operators are stated as equalities (e.g., in the definition of a group). However, expressing properties is useless if we can't prove them, and this is where inductive types come in.

 [Last time]: /posts/reflections-on-equality.html

 Inductive types allow users to extend their type theories with new types, generated by _constructors_, which respect an _induction principle_. Constructors are conceptually simple: they provide a way of *construct*ing elements of that type, like the name implies. The induction principle, though, requires a bit more thought.

 The only inductive type
 -----------------------

 Since this is a blog post about type theory, I am required, by law, to start this discussion about inductive types with the most boring one: the set of all natural numbers, $\mathbb{N}$. The set $\mathbb{N}$ (to be read, and written, `Nat`, from now on) is both uninteresting enough that the discussion can focus on the induction aspect, but also non-trivial enough for some complications to arise.

 The type `Nat`{.dt} is generated by two constructors, one for `zero`{.dt}, and one for the `suc`{.dt}cessor of another number. We can represent this in Agda as in the code block below. Taken together, the signature for the type former (`Nat : Set`{.agda}) and the signatures of all the constructors make up the complete specification of the inductive type, called (confusingly) a signature. Looking at only these we can figure out its fundamental property—its induction principle.

 ```agda
 data Nat : Set where
 zero : Nat
 suc : Nat → Nat
 ```

 Before we consider the full induction principle, it's useful to consider a simply-typed restriction, called the _recursor_. Every inductive type has a recursor, but this name makes the most sense when talking about natural numbers, because it operationally models primitive recursion. The recursor for the natural numbers is a (dependent) function with the following parameters:

 - A _motive_, the type we elminate into;
 - A _method_ for the constructor `zero`, that is, an element of `A`, and
 - A _method_ for the constructor `succ`, which is a function from `A → A`.

 To put it into code:

 ```
 foldNat : (A : Type) → A → (A → A) → Nat → A
 ```

 Furthermore, the recursor has, as anything in type theory, computational behaviour. That is, when applied to all of its arguments, `foldNat` evaluates. This evaluation is recursive, but pay attention to the structure: we only ever apply `foldNat` to values "smaller" (contained in) the data we started with.

 ```agda
 foldNat : (A : Type) → A → (A → A) → Nat → A
 foldNat A z s zero = z
 foldNat A z s (suc x) = s (foldNat A z s x)
 ```

 To see how one derives the recursor from the signature, we would have to take a detour through category theory. While a complete semantic argument is preferable, for now, some handwaving is in order. To cite my sources: this presentation of algebras was given in [Kaposi 2020], a very well-written paper which you should check out if you want to understand how algebras work for higher inductive types.

 [Kaposi 2020]: https://arxiv.org/pdf/1902.00297.pdf

 Take a **`Nat`{.dt}-algebra** to be a dependent triple `(C : Set) × C × (C → C)`{.agda}. The type `C` is known as the _carrier_ of the algebra. From this type of algebras we can define a type family of _`Nat`{.dt}-algebra homomorphisms_ between two algebras, which are structure-preserving maps between them. This definition is a bit complicated, so it's in a box:

 ```agda
 Alg : Set₁
 Alg = Σ Set₀ λ Nat → Σ Nat λ _ → (Nat → Nat)

 Morphism : Alg → Alg → Set
 Morphism (N0 , z0 , s0) (N1 , z1 , s1) =
 Σ (N0 → N1) λ NM →
 Σ (NM z0 ≡ z1) λ _ →
 ((n : N0) → NM (s0 n) ≡ s1 (NM n)) 
 ```

 A morphism between algebras $(N_0, z_0, s_0)$ and $(N_1, z_1, s_1)$ consists of a map $N^M : N_0 \to N_1$ between their carriers together with data proving that $N^M$ maps the objects in $N_0$ to the "right" objects in $N_1$.

 Suppose for a second that we have a "special" `Nat`{.dt}-algebra, denoted `Nat*`{.dt}. The statement that there exists a recursion principle for the `Nat`{.dt}ural numbers is then a function with the type boxed below.

 ```
 recursion : (α : Alg) → Morphism Nat* α
 ```

 To borrow some more terminology from our category theorist friends, it's stating that `Nat*`{.dt} is _weakly initial_ in the category of `Nat`{.dt}-algebras: For every other algebra `α` we have a homomorphism `Nat* → α`. It turns out that, if our type theory has inductive types, we can implement this function! The initial algebra is given by `(Nat, zero, suc)` and the `recursion` principle by the function below:

 ```agda
 Nat* : Alg
 Nat* = (Nat, zero, suc)

 recursion : (α : Alg) → Morphism Nat* α
 recursion (N0 , z0 , s0) = map , refl , λ n → refl where
 map : Nat → N0
 map zero = z0
 map (suc x) = s0 (map x)
 ```

 In particular, to be very needlessly formal, "every inductive type is the _initial algebra_ of some strictly-positive endofunctor." It's no surprise, then, that we can give such an initial algebra for the natural numbers in Agda, a theory with inductive types! The "shape" of this functor depends on the constructors of the inductive type, but the general principle is the same: Data representing the type (the carrier) together with data for every constructor, with the inductive type "replaced" by the carrier.


 And then some more
 ------------------

 A trivial inductive type we can discuss is the unit type, or top type:

 ```agda
 data Unit : Set where
 point : Unit
 ```

 Let's speedrun through the definition of `Unit`{.dt}-algebras, `Unit`{.dt}-algebra homomorphisms, and the initial `Unit`{.dt}-algebra. The name `point`{.dt} was picked for the constructor to be indicative of these structures: `Unit`{.dt} is the _initial pointed type_. A pointed type `T` is a type for which we have a point `p : T`—oops, there's our algebra type! It's `(T : Set) × T`.

 _Wait, what? Really?_, I hear you ask. You proceed: _An algebra for the `Unit` type is just a pointed type?_ Yup, my dear reader: the only data we need to eliminate from `Unit` is the type we're eliminating into (the carrier `C`) and a value in `C`, that we map our `point` to!

 The family of types between unit types can also be specified in Agda, but I'm absolutely sure you can work it out: It's a function $U^M : U_0 \to U_1$ such that $U^M p_0 \equiv p_1$.

 ```agda
 Unit-Alg : Set₁
 Unit-Alg = Σ Set λ Unit → Unit

 Unit-Morphism : Unit-Alg → Unit-Alg → Set
 Unit-Morphism (U0 , p0) (U1 , p1) = Σ (U0 → U1) λ UM → UM p0 ≡ p1
 ```

 Our definition for Unit-recursion is laughable. It's so trivial that I'm going to go a bit further, and instead of proving _weak_ initiality as we did for the naturals, prove _initiality_: There exists a **unique** map from `(Unit, point)` to any other algebra. For this, we need a notion of uniqueness. Contractibility will do: A type is contractible iff it's pointed and, for every other element, there exists an equality between the point and that element. Check out the box:

 ```agda
 isContr : Set → Set
 isContr T = Σ T λ center → (other : T) → other ≡ center
 ```

 Or, this is where I _would_ put a nice box together with an Agda-checked proof that `(Unit , point)` is initial... if I had one! Agda does not have a strong enough notion of equality for us to prove this. In particular, Agda out-of-the-box has no _function extensionality_ principle (see my post on equality). However, we _can_ postulate one, and after writing some equality-manipulation functions, write that proof.

 <details>
 <summary>Equality stuff</summary>

 ```agda
 postulate
 funext : {ℓ ℓ' : _}
 {A : Set ℓ} {B : A → Set ℓ'}
 (f g : (x : A) → B x)
 → ((x : A) → f x ≡ g x) → f ≡ g

 subst : {ℓ ℓ' : _}
 {A : Set ℓ} (B : A → Set ℓ')
 {x y : A}
 → x ≡ y → B x → B y
 subst B refl x = x

 pairPath : {ℓ ℓ' : _}
 {A : Set ℓ} {B : A → Set ℓ'}
 {x y : A}
 {e : B x} {e' : B y}
 (p : x ≡ y)
 → subst B p e ≡ e' → (x , e) ≡ (y , e')
 pairPath refl refl = refl

 _∘_ : {ℓ : _} {A : Set ℓ} {x y z : A} → y ≡ z → x ≡ y → x ≡ z
 refl ∘ refl = refl

 UIP : {ℓ : _} {A : Set ℓ} {x y : A} (p q : x ≡ y) → p ≡ q
 UIP refl refl = refl
 ```

 </details>

 I'll be the first to admit that all this equality stuff, _especially_ the postulate, is a bit gross. However, it's all justifiable: In particular, the setoid model of type theory validates all of MLTT + funext + UIP, so we're in the clear. The `pairPath` function has a very complicated type: it defines the setoid (or groupoid!) structure of the $\sum$-types.

 If you can intuit that an equality between `(a, b) ≡ (c, d)` consists of a pair of equalities `(a ≡ c) × (b ≡ d)`, `pairPath` is that, but dependent. Since the second components of the pairs have types depending on the first element, we need to coerce `e` along the path between `x ≡ y` to get an element `subst B p e : B y` that we can compare with `e'`.

 ```agda
 Unit-initiality : (α : Unit-Alg)
 → isContr (Unit-Morphism (Unit , point) α)
 Unit-initiality (U0 , p0) = (map , refl) , contract where
 map : Unit → U0
 map point = p0

 contract : (other : Unit-Morphism (Unit , point) (U0 , p0))
 → other ≡ (map , refl)
 contract ( fun , p ) =
 pairPath
 (funext fun map (λ { point → p }))
 (UIP _ _)
 ```

 With funext, we can also prove `Nat-initiality`, the equivalent statement about natural numbers. Left as an exercise to the reader, though!

 Upgrading your recursion: displayed algebras
 --------------------------------------------

 Just like we can go from regular pairs to dependent pairs by complicating things, we can complicate the recursor to get an _induction principle_, which uniquely characterises each inductive type. From an algebra (the input to the recursor), we build a **displayed algebra**, which is a logical predicate over the algebra's carrier together with proofs for each of its methods. Let's go back to the natural numbers for a second, since those are more interesting than the unit type.

 Given a $\mathbb{N}$-algebra $\alpha = (N, z, s)$, we define the type of displayed $\mathbb{N}$-algebras over $\alpha$ to be $\sum(N^D : N \to \mathrm{Set}) \sum(z^D : N^D z) (\prod(n : N) N^D n \to N^D (s\ n))$. That is, we "upgrade" the carrier $N$ to a predicate on carriers $N \to \mathrm{Set}$, $z$ gets upgraded to a proof of $N^D z$, and $s$ gets upgraded to a proof that $N^D (s\ n)$ follows from $N^D n$. Check out the box:

 ```agda
 Nat-Displayed : (α : Nat-Alg) → Set₁
 Nat-Displayed (N , z , s) =
 Σ (N → Set) λ Nd →
 Σ (Nd z) λ _ ->
 (n : N) → Nd n → Nd (s n)
 ```

 Now we can finally connect the idea of "inductive types" back to the idea of "induction" that some of us got familiar with in a high school proofs class, namely over the natural numbers:

 > Suppose we have a property of the natural numbers, $P$. If:
 >
 > - $P$ holds for $0$, and
 > - Assuming P holds for n, P holds for $n + 1$, then
 >
 > $P$ holds for every natural number.

 This is the same thing we have encoded in the displayed algebras over $(N, z, s)$! Since a predicate is, type-theoretically, a family of types, we interpret our $P$ as $N^D : N \to \mathrm{Set}$. A predicate holds for a value iff you have an inhabitant of the predicate applied to that value, so our proofs become terms of the right type. The universal quantifier for $n$ becomes a dependent function, and the implication a regular function.

 The final piece of our complicated terminology puzzle is the idea of a **section** of a displayed algebra over an algebra, a sentence so utterly convoluted that I wish I had never written it. Just like displayed algebras complicate the idea of algebras, sections complicate algebra homomorphisms. Just like a homomorphism has a map between the algebras' carriers, a section has a dependent map from algebra's carrier to the predicate of the algebra displayed over that one. The dependency structure doesn't make a lot of sense written out, so check out the code:

 ```agda
 Nat-Section : (α : Nat-Alg) → Nat-Displayed α → Set
 Nat-Section (N , z , s ) (Nd , zd , sd ) =
 Σ ((n : N) → Nd n) λ Ns →
 Σ (Ns z ≡ zd) λ _ →
 ((n : N) → Ns (s n) ≡ sd n (Ns n))
 ```

 The first component of a section is the induced function generated by the motives packaged together by the displayed algebra $(N^D, z^D, s^D)$. The second two components are _reduction rules_, packaged as propositional equalities! The second component, for instance, specifies that $N^S$ (the function) applied to the $z$ero of our algebra returns the method $z^D$.

 The existence of an induction principle is packaged up by saying that any algebra displayed over the initial one has a section. In code, it's a dependent map `Induction : (M : Nat-Displayed Nat*) → Section M`{.agda}. We can implement that in Agda like in the box below, but because the `map` obeys the computation rules automatically, none of the proof components are incredibly interesting—they're both trivial proofs.

 ```agda
 Nat-induction : (M : Nat-Displayed Nat*) → Nat-Section Nat* M
 Nat-induction (Nd , zd , sd) = map , refl , λ s → refl where
 map : (n : Nat) → Nd n
 map zero = zd
 map (suc x) = sd x (map x)
 ```

 As an _incredibly_ convoluted example we can use all our algebra machinery to implement.. drumroll, please... addition!

 ```agda
 add : Nat → Nat → Nat
 add = (Nat-induction displayed) ₁ where
 displayed : Nat-Displayed Nat*
 displayed = (λ n → Nat → Nat)
 , (λ z → z)
 , λ _ k z → suc (k z) 

 _ : add (suc (suc zero)) (suc (suc zero))
 ≡ suc (suc (suc (suc zero)))
 _ = refl
 ```

 Again using our trivial example as a bit more practice before we move on, let's talk displayed algebras and sections for the Unit type. They're both quite easy. Assuming $(U, p)$ is our algebra, the displayed algebra ends up with a predicate $U^D : U → \mathrm{Set}$ together with a proof $p^D : U\ p$. Sections are also quite easy, since there's only one "propositional reduction rule" to give.

 ```agda
 Unit-Displayed : Unit-Alg → Set₁
 Unit-Displayed (U , p) = Σ (U → Set) λ UD → UD p

 Unit-Section : (α : Unit-Alg) → Unit-Displayed α → Set
 Unit-Section (U , p) (UD , pD) =
 Σ ((x : U) → UD x) λ US →
 US p ≡ pD
 ```

 Agda once more makes the proofs for writing `Unit-Induction` trivial, so I'll leave both its type and implementation as an exercise for the reader.

 You saw it coming: Vectors
 --------------------------

 Both of the exceedingly interesting types we looked at above were simple, since they both just exist in a universe, `Set₀`. Now we up the difficulty considerably by adding both _parameters_ and _indices_. Both are arguments to the type itself, but they differ in how they can be used in the constructors. Again, since I am writing about dependent types, I'm obligated by law to mention this example.. fixed-length lists, or vectors. These are _parametrised_ by a type $A$ of elements and _indexed_ by a number $n : \mathbb{N}$, the length.

 ```agda
 data Vec (A : Set₀) : Nat → Set₀ where
 nil : Vec A zero
 cons : (n : Nat) → A → Vec A n → Vec A (suc n)
 ```

 Parameters, at least in Agda, are introduced before the `:` in the type signature. Indices come later, but both can be dependent. Parameters have to be the same for every constructor (we only ever mention `Vec A`), but the `Nat`ural can vary between the constructors. One introduces a vector of length zero, and one increments the length of a smaller vector.

 The type of algebras for vectors is a tad more interesting, so let's take a look. Since `Vec` is parametrised by `A`, so is `Vec-Alg`. We don't speak of general "vector algebras", only "vector-of-A algebras", so to speak. Since the natural number is an index, it becomes an argument to our carrier type. Both of the "constructor" data are applied to their indices, and since the `A` is bound as an argument to the algebra function, we can refer to it in the type of `cons` (the third component).

 ```agda
 Vec-Alg : Set₀ → Set₁
 Vec-Alg A =
 Σ (Nat → Set₀) λ Vec →
 Σ (Vec zero) λ nil →
 {- cons : -} (n : Nat) → A → Vec n → Vec (suc n)
 ```

 The type of homomorphisms for `Vec A`-algebras is mechanically derived from the type above by starting from a map `(n : Nat) → V0 n → V1 n` (where `V0`, `V1` are the carriers of the "source" and "target" algebras) and imposing the necessary conditions.

 ```agda
 Vec-Morphism : (A : Set₀) → Vec-Alg A → Vec-Alg A → Set₀
 Vec-Morphism A (V0 , n0 , c0) (V1 , n1 , c1) =
 Σ ((n : Nat) → V0 n → V1 n) λ VM →
 Σ (VM zero n0 ≡ n1) λ _ →
 ((n : Nat) (a : A) (xs : V0 n)
 → VM (suc n) (c0 n a xs) ≡ c1 n a (VM n xs))
 ```

 Just like in the Nat-algebra morphisms, we have two cases, one of which requires exchanging our map with a constructor—the successor/cons case. It's mostly the same, except for the `A` parameter we have to thread everywhere, and all the indices we have to respect. And, just like back then, assuming funext, we have an initial `Vec A`-algebra given by `(Vec A, nil, cons)`. The proof is full of fiddly details[^1], but it's again justified by the setoid model, with only `funext` needing to be postulated.

 ```agda
 Vec-initiality : (A : Set) (α : Vec-Alg A)
 → isContr (Vec-Morphism A (Vec A , nil , cons) α)
 Vec-initiality A (V0 , n0 , c0) = (map , resp) , contract where
 map : (n : Nat) → Vec A n → V0 n
 map zero nil = n0
 map (suc n) (cons .n a xs) = c0 n a (map n xs)

 resp = refl , λ n a x → refl
 ```

 Above we provide the map from `Vec A n` to the algebra `α`'s carrier, `V0`, and prove that it `resp`{.kw}ects the equalities imposed by `Vec A`-homomorphisms. Since Agda has pattern matching built in, these equalities are trivial (`refl`{.agda}). Our proof continues upside-down: The interesting thing here is the `map'≡map` equality. Skip the noise: keep reading after the code.

 ```{.agda .continues}
 contract : (other : Vec-Morphism A (Vec A , nil , cons)
 (V0 , n0 , c0))
 → other ≡ (map , refl , λ n a xs → refl)
 contract (map' , nM , cM)
 = pairPath
 map'≡map
 (pairPath
 (UIP _ _)
 (funext3 _ _ (λ n a xs → UIP _ _))) 
 where
 map'~map : (n : Nat) (xs : Vec A n) → map' n xs ≡ map n xs
 map'~map .zero nil = nM
 map'~map .(suc n) (cons n x xs) =
 subst
 (λ e → map' (suc n) (cons n x xs) ≡ c0 n x e)
 (map'~map n xs)
 (cM n x xs)

 map'≡map = funext2 _ _ map'~map
 ```

 We build the `map'≡map`{.va} equality by an appeal to `funext2`{.va}, a helper defined in terms of our `funext`{.op} postulate to reduce the noise a tad. Again, I want to stress that this is a failure of Agda: There is a family of semantic models of type theory in which equality in function types is pointwise _by definition_, including the setoid model, which would be very convenient here since we could keep our appeals to `UIP`{.op}. Anything that validates `funext`{.op} would do, though, including Cubical Agda.

 Other than that, the proof is standard: Everything we need is given by the `nM`{.va} and `cM`{.va} equalities of the `other`{.va} morphism we're contracting. In the inductive step, the case for `(cons n x xs)`, we have a path `cM n x xs : map' (suc n) (cons n x xs) ≡ c0 n x (map' n xs)`. Since we want the `map' n xs` on the right-hand side to be `map n xs`, we `subst`{.op} it away using the path `map'~map n xs : map' n xs ≡ map n xs` obtained by a recursive application of `map'~map`{.fn}.

 Now we turn to dependent elimination of vectors, or induction. For this we need to calculate the type of displayed algebras over a given `Vec A`-algebra. It's mechanical: The `V` of our algebra gets upgraded to a family of predicates `P : (n : Nat) → V n → Set₀`. The "constructor data" given by `n , c` become "proof data" of a type extending the `Vec A`-algebra.

 ```agda
 Vec-Displayed : (A : Set₀) → Vec-Alg A → Set₁
 Vec-Displayed A (V , z , c) =
 Σ ((n : Nat) → V n → Set₀) λ P →
 Σ (P zero z) λ nil →
 {- cons -} (n : Nat) (x : A) (tail : V n)
 → P n tail → P (suc n) (c n x tail)
 ```

 In the `cons` case, the algebra has access both to the `tail` of type `V n` _and_ the inductive assumption `P n tail`. This represents, operationally, a choice between recurring or not.

 You know the drill by now: after displayed algebras, algebra sections. Assume an algebra `α = (V, nil, cons)` and a displayed algebra `(P, nD, cD)` over `α`. The first component will be a dependent function of type `(n : Nat) (x : V n) → P n x`, and the second and third components will be propositional equalities representing reduction rules. Since the vectors and natural numbers are similar in structure, we'll end up with similar-looking reduction rules, just noisier. Here they are:

 ```agda
 Vec-Section : (A : Set₀) (α : Vec-Alg A) → Vec-Displayed A α → Set
 Vec-Section A (V , n , c) (P , nD , cD) =
 Σ ((n : Nat) (x : V n) → P n x) λ map →
 Σ (map zero n ≡ nD) λ _ →
 ( (n : Nat) (x : A) (tl : V n)
 → map (suc n) (c n x tl) ≡ cD n x tl (map n tl))
 ```

 They're not pretty, so take a minute to internalise them. Again, we have the dependent `map`{.op}, together with a propositional equality which says `map zero n` evaluates to the `nD` datum of our displayed map. The third component specifies that `map (suc n)` defers to the `cD` component and recurs in the tail. It's not complicated conceptually, but it is complex to write down. Finally, the induction principle for natural numbers says that any displayed algebra over the initial `(Vec A , nil , cons)` has a section. Again, Agda trivialises the equalities:

 ```agda
 Vec-Induction : (A : Set₀)
 (α : Vec-Displayed A (Vec A , nil , cons))
 → Vec-Section A (Vec A , nil , cons) α
 Vec-Induction A (P , nD , cD) = map , refl , λ n a xs → refl where
 map : (n : Nat) (xs : Vec A n) → P n xs
 map .zero nil = nD
 map .(suc n) (cons n x xs) = cD n x xs (map n xs)
 ```

 I bet you've never seen types like these
 ----------------------------------------

 This is a bet I'm willing to take. Unless you've gone looking for ways to formalise semantics of inductive types before, it's not very likely for you to have come across this algebra machinery before. A far more common way of dealing with inductive data types is dependent pattern matching:

 ```agda
 add : Nat → Nat → Nat
 add zero n = n
 add (suc x) n = suc (x + n)

 map : {n : Nat} {A B : Set₀} → (A → B) → Vec A n → Vec B n
 map f nil = nil
 map f (cons x xs) = cons (f x) (map f xs)
 ```

 However, there is a very good reason not to work directly with pattern matching in a formalisation. That reason can be found on page 24 of [this paper] by Cockx et al. Take a minute to recover and we can continue talking. A more tractable presentation of inductive types is directly with induction principles, instead of taking this detour through category theory. For instance, the natural numbers:

 ```agda
 Nat-induction : (P : Nat → Set)
 → P zero
 → ((n : Nat) → P n → P (suc n))
 → (n : Nat) → P n
 Nat-induction P pz ps zero = pz
 Nat-induction P pz ps (suc n) = ps n (Nat-induction P pz ps)
 ```

 It turns out that this presentation, and the one based on algebras I've been going on about, are actually equivalent! Very plainly so. If you unfold the type of `Nat-Induction` (the one about algebras), and do some gratuitous renaming, you get this:

 ```agda
 Nat-Induction :
 (M : Σ (Nat → Set)
 λ P → Σ (P zero)
 λ _ → (n : Nat) → P n → P (suc n)
 )
 → Σ ((n : Nat) → M ₁ n)
 λ Nat-ind → Σ (Nat-ind zero ≡ M ₂ ₁)
 λ _ → (n : Nat) → Nat-ind (suc n) = M ₂ ₂ n (Nat-ind n)
 ```

 It's ugly, especially with all the subscript projections, but if we apply some good ol' currying we can recover this type, by transforming (the dependent analogue of) `A × B × C → D` with `A → B → C → D`:

 ```agda
 Nat-Induction : (P : Nat → Set)
 (pzero : P zero)
 (psuc : (n : Nat) → P n → P (suc n))
 → Σ ((n : Nat) → P n)
 λ ind → Σ (ind zero ≡ pzero)
 λ _ → (n : Nat) → ind (suc n) ≡ psuc n (ind n)
 ```

 I've gone and done some more renaming. `P` is a name for `M ₁`, `pzero` is `M ₂ ₁`, and `psuc` is `M ₂ ₂`. Again, just to emphasise what the contents of "a displayed algebra section over the initial algebra" turn out to be:

 - The first component is **a function from the data type to a predicate**,
 - The $n$ following components are **propositional equalities representing reduction rules**, for each constructor, recurring as appropriate.

 If you'll allow me one of _those_ asides, this is just incredibly cool to me. The fact we can start from an inductive signature and derive not only the recursor, but from that derive the motives and methods of induction, and from _that_ derive exactly the behaviour of the induced map for a particular bundle of motives and methods? It feels.. right. Like this is what induction was meant to be. Not some needlessly formal underpinning for pattern matching, like I used to think of it as, but as distinguished, rich mathematical objects determined exactly by their constructors.

 Complicating it further: Induction-induction
 --------------------------------------------

 We've seen, in the past 2 thousand-something words, how to build algebras, algebra homomorphisms, displayed algebras and algebra sections for inductive types, both indexed and not. Now, we'll complicate it further: Induction-induction allows the formation of two inductive families of types $A : \mathrm{Set}$ and $B : A \to \mathrm{Set}$ _together_, such that the constructors of A can refer to those of B and vice-versa.

 The classic example is defining a type together with an inductively-defined predicate on it, for instance defining sorted lists together with a "less than all elements" predicate in one big induction. However, in the interest of brevity, I'll consider a simpler example: A syntax for contexts and Π-types in type theory. We have one base type, `ι`, which is valid in any context, and a type for dependent products `Π`. If `σ` is a type in `Γ` and `τ` a type in the context `Γ, σ`, then `Π σ τ` is also a type in `Γ`.

 ```agda
 data Ctx : Set
 data Ty : Ctx → Set

 data Ctx where
 stop : Ctx
 pop : (Γ : Ctx) → Ty Γ → Ctx

 data Ty where
 ι : {Γ : Ctx} → Ty Γ
 Π : {Γ : Ctx} (σ : Ty Γ) (τ : Ty (pop Γ σ)) → Ty Γ
 ```

 Here I'm using Agda's forward-declarationthe definition of their algebras feature to specify the signatures of `Ctx` and `Ty` before its constructors. This is because the constructors of `Ctx` mention the type `Ty`, and the type _of_ `Ty` mentions `Ctx`, so there's no way to untangle them other than this.

 When talking about our standard set of categorical gizmos for inspecting values of inductive type, it's important to note that, just like we can't untangle the definitions of `Ctx` and `Ty`, we can't untangle their algebras either. Instead of speaking of `Ctx`-algebras or `Ty`-algebras, we can only talk of `Ctx-Ty`-algebras.[^2] Let's think through the algebras first, since the rest are derived from that.

 For our `Nat`-algebras, we had as a carrier an element of `Set₀`. For the `Vec`-algebras, we needed a carrier which was an element of `Nat → Set₀`. Now, since we have two types, one of which is indexed, we can't describe their carriers in isolation: We have a _telescope_ of carriers $Σ (\mathrm{Ty}^A : \mathrm{Set}_0) Σ (\mathrm{Ctx}^A : \mathrm{Ty}^A \to \mathrm{Set}_0)$ over which the type of the methods is quantified. Let's go through them in order.

 - `stop : Ctx` gives rise to a method $\mathrm{stop}^A : \mathrm{Ctx}^A$,
 - `pop : (Γ : Ctx) → Ty Γ → Ctx` generates a method $\mathrm{pop}^A : (Γ^A : \mathrm{Ctx}^A) → \mathrm{Ty}^A\ Γ^A → \mathrm{Ctx}^A$
 - `ι : {Γ : Ctx} → Ty Γ` leads us to jot down a method $\iota^A : \{Γ^A : \mathrm{Ctx}^A\} → \mathrm{Ty}^A\ \Gamma^A$
 - `Π : {Γ : Ctx} (σ : Ty Γ) (τ : Ty (pop Γ σ)) → Ty Γ` finally gives us a method with the hell-of-a-type
 $\Pi^A : \{\Gamma^A : \mathrm{Ctx}^A\} (\sigma^A : \mathrm{Ty}^A\ \Gamma) (\tau : \mathrm{Ty}^A (\mathrm{pop}^A\ \Gamma^A\ \sigma^A) → \mathrm{Ty}^A\ \Gamma^A)$

 Let's go back to Agda-land, where I will write exactly the same thing but with syntax somehow even less convenient than LaTeX. Just as a reminder, `Σ A λ x → B` is how I've been writing $\sum(x : A) B$.

 ```agda
 Ctx-Ty-Alg : Set₁
 Ctx-Ty-Alg =
 Σ Set₀ λ Ctx →
 Σ (Ctx → Set₀) λ Ty →
 Σ Ctx λ stop →
 Σ ((Γ : Ctx) → Ty Γ → Ctx) λ pop →
 Σ ({Γ : Ctx} → Ty Γ) λ ι →
 ({Γ : Ctx} (σ : Ty Γ) (τ : Ty (pop Γ σ)) → Ty Γ)
 ```

 The type of homomorphisms for these algebras are the same as the ones we've seen before, except for the fact they're way more complicated. Both of the carrier components still become functions, and all of the method components still become equalities which must be respected, except now there's more of them.

 ```{.agda tag=Suffering}
 Ctx-Ty-Morphism : Ctx-Ty-Alg → Ctx-Ty-Alg → Set₀
 Ctx-Ty-Morphism
 (C0 , T0 , s0 , p0 , i0 , f0)
 (C1 , T1 , s1 , p1 , i1 , f1)
 =
 Σ (C0 → C1) λ Ctx →
 Σ ((x : C0) → T0 x → T1 (Ctx x)) λ Ty →

 -- Constructor data for Ctx
 Σ (Ctx s0 ≡ s1) λ stop →
 Σ ( (x : C0) (ty : T0 x)
 → Ctx (p0 x ty) ≡ p1 (Ctx x) (Ty x ty))
 λ pop →

 -- Constructor data for Ty
 Σ ({Γ : C0} → Ty Γ (i0 {Γ}) ≡ i1 {Ctx Γ}) λ iota →
 ( {Γ : C0} (σ : T0 Γ) (τ : T0 (p0 Γ σ))
 → Ty Γ (f0 {Γ} σ τ)
 ≡ f1 (Ty Γ σ) (subst T1 (pop Γ σ) (Ty (p0 Γ σ) τ)))
 ```

 Ok, I lied. There's more than just the usual "more stuff" complication. In the case for `Π` (nameless, the last component), we need to compare `f0 σ τ` with `f1 (Ty Γ σ) (Ty (p0 Γ σ) τ)`. Read past the symbols: We need to make sure that the `Ty` operation maps `Π` types to `Π` types. But, there's a catch! `Ty (p0 Γ σ) τ)` has type `T1 (Ctx (p0 Γ σ))` (i.e., assemble the context in `C0` with `p0`, then translate to `C1` with `T1`), but `f1` wants something in `T1 (p1 (Ctx Γ) (Ty Γ σ))` (assemble the context in `C1` with translated components).

 We know these types are equal though, the equation `pop` says _just that_! Agda isn't that clever, though (thankfully), so we have to manually cast along the path `pop Γ σ` to make these types line up. Since we have so many equations, we definitely would've ended up with at least one dependent path.[^3]

 I'll pass on proving strict initiality in the interest of brevity, settling for the weak variant. Recall that initiality means we have a distinguished `Ctx-Ty`-algebra, given by the type formers and constructors, from which we can make a morphism to any other algebra. In types:

 ```agda
 Ctx-Ty-Initial : (M : Ctx-Ty-Alg) → Ctx-Ty-Morphism Ctx-Ty* M
 Ctx-Ty-Initial (C0 , T0 , s0 , p0 , i0 , f0)
 = C , T , refl , (λ x ty → refl) , refl , λ σ τ → refl
 where
 C : Ctx → C0
 T : (x : Ctx) → Ty x → T0 (C x)

 C stop = s0
 C (pop c t) = p0 (C c) (T c t)

 T γ ι = i0 {C γ}
 T γ (Π σ τ) = f0 (T γ σ) (T (pop γ σ) τ)
 ```

 I want to make clear that, while this looks like a bloody mess, it was incredibly simple to implement. See the equation `T γ (Π σ τ) = ...`? I didn't write that. I didn't _need_ to. Check out the type of the last component of `Ctx-Ty-Morphism Ctx-Ty* M`. It's literally just saying what the right-hand-side of `T γ (Π σ τ)` needs to be for `(C, T)` to be the morphism part of a **homo**morphism. And the homo (ahem) part is trivial! It's all `refl`s again (are you noticing a trend?).

 Elevating it: Higher Inductive Types
 ------------------------------------

 The algebra approach isn't limited to the `Set`-level mathematics we've been doing up to now, and it scales very simply to types with path constructors in addition to point constructors. For this part, we unfortunately can't _implement_ any of the proofs in standard Agda, especially Agda `--with-K` that we've been using up to now, but we can still talk about their types. Let's start with the second simplest higher inductive type: Not the circle, but the interval.

 The interval has two endpoints, `l` and `r`, and a line `seg`{.op}ment between them. It's a contractible type, so it's equivalent to the Unit type we've seen before, but it's.. more. The existence of the interval type implies funext, and we'll show that using algebras.

 ```agda
 data I : Type₀ where
 l r : I
 seg : i0 ≡ i1
 ```

 The type of algebras for the interval is also simple. We have a carrier, $I^A$, two points $l^A : I^A$ and $r^A : I^A$, and an _equality_ $seg^A : l^A \equiv r^A$. Wait, an equality? Yup! Since the enpoinds `l` and `r` are equal, so must be whatever they map to. But, since we're in HoTT-land now, this equality doesn't necessarily need to be trivial, as we'll see in a second.

 ```agda
 I-Alg : Type₁
 I-Alg = Σ Type₀ λ I → Σ I λ l → Σ I λ r → l ≡ r
 ```

 The type of algebra homomorphisms, like before, encompasses a map together with some propositional reductions of that map. We have three "standard" components `I`, `l`, `r`, which are just like for the type of booleans, and a mystery fourth component which expresses the right coherence condition.

 ```agda
 I-Alg-Morphism : I-Alg → I-Alg → Type
 I-Alg-Morphism (I0 , l0 , r0 , seg0) (I1 , l1 , r1 , seg1) = 
 Σ (I0 → I1) λ I →
 Σ (I l0 ≡ l1) λ l →
 Σ (I r0 ≡ r1) λ r →
 ```

 Now the type of the fourth component is interesting. We want `seg0` and `seg1` to be "equal" in some appropriate sense of equality. But they have totally different types! `seg0 : l0 ≡I0 r0` and `seg1 : l1 ≡I1 r1`. It's easy enough to fix the type of `seg0` to be a path in `I0`: `ap I seg0` is a path in `I1` between `I l0` and `I r0`. Out of the pan, into the fire, though. Now the endpoints don't match up!

 Can we fix `I l0` and `I r0` in the endpoints of `seg0`? The answer, it turns out, is yes. We can use path _transitivity_ to alter both endpoints. `r` correctly lets us go from `I r0` to `r1`, but `l` is wrong—it takes `l1` to `I r0`. We want that backwards, so we apply _symmetry_ here.

 ```agda
 (r ∘ (ap I seg0 ∘ sym l)) ≡ seg1
 ```

 Now, I'll reproduce an argument from the HoTT book, which proves function extensionality follows from the interval type and its eliminator. But we'll do it with algebras. First, we need to postulate (since Agda is weak), that there exists a weakly initial `I`-algebra. This'll play the part of our data type. In reality, there's a couple more details, but we can ignore those, right?

 <details>
 <summary>We can't.</summary>

 Instead of just full-on postulating the existence of an `I`-algebra and its initiality, I'll define the type `I` (lacking its `seg`) normally, postulate `seg`, then postulate the coherence condition in the definition of `I-Recursion`. This simplifies some proofs since it means `I-Recursion` will compute definitionally on point constructors.

 ```agda
 data I : Type where
 l r : I

 postulate
 seg : l ≡ r

 I* : I-Alg
 I* = (I , l , r , seg)

 I-Recursion : (α : I-Alg) → I-Alg-Morphism I* α
 I-Recursion (I0 , l0 , r0 , seg0) = go , refl , refl , subst (λ e → e ≡ seg0) (∘refl (ap go seg)) sorry where
 go : I → I0
 go l = l0
 go r = r0

 postulate
 sorry : ap go seg ≡ seg0
 ```

 There's a bit of ugly equality-wrangling still, but it's fine. All that matters is that it type checks, I suppose.

 </details>

 Now, the argument. We want a function that, given $f, g : A \to B$ and a homotopy $p : \prod(x : A) \to f(x) \equiv g(x)$, produces a path $f \equiv g$. We define a family of functions $h_x : I \to B$ given a $x : A$, which maps `l` to `f(x)`, `r` to `g(x)`, and in the "`seg` case", returns `p(x)`. The algebra is simple:

 ```agda
 I→funext : {A B : Type} (f g : A → B) (hom : (x : A) → f x ≡ g x) → f ≡ g
 I→funext {A} {B} f g p = ? where
 h : A → I → B
 h x = (I-Recursion (B , f x , g x , p x)) ₁
 ```

 And for my next trick, I'll define the function `h' = flip h`. Or, in Agda terms, `h' = λ i x → h x i`, a function from `I → A → B`. We have a path between the two endpoints of the segment, so we also have a path between the two "endpoinds" of this function, which we can calculate:

 ```{.agda tag="Mmm, substitution"}
 ap h' seg : (λ i x → h x i) l ≡ (λ i x → h x i) r -- type of ap
 = (λ x → h x l) ≡ (λ x → h x r) -- β-reduce
 = (λ x → f x) ≡ (λ x → g x) -- computation for h
 = f ≡ g -- η-reduce
 ```

 This concludes our proof:

 ```agda
 I→funext : {A B : Type} (f g : A → B) (hom : (x : A) → f x ≡ g x) → f ≡ g
 I→funext {A} {B} f g p = ap h' seg where
 h : A → I → B
 h x = (I-Recursion (B , f x , g x , p x)) ₁

 h' : I → A → B
 h' i x = h x i
 ```

 This concludes our post
 -----------------------

 God, this was a long one. Four thousand words! And a bit more, with this conclusion.

 I've wanted to write about inductive types for a hecking long time now, ever since the day I finished the equality post. However, coming by motivations in the past year has been.. hard, for everyone. So it's good that I finally managed to it out there! _77 days later_. God. I might write some more type theory in the future, but don't hold your breath! 77 days is like, 36 thousand times more than you could do that for.

 I ended up writing about algebras instead of eliminators or pattern matching because they seamlessly scale up even to higher induction-induction, which ends up having super complicated eliminators, far too much for me to derive by hand (especially early in the AMs, which is when most of this post was written).

 <div class="special-thanks">
 With special thanks to the proofreader:

 * [My friend Jonathan](https://squiddev.cc)
 </div>

 [this paper]: https://dl.acm.org/doi/10.1145/3236770

 [^1]: And, full disclosure, took me almost an hour to write at 2 AM...
 [^2]: The best part of this presentation is that it makes painfully clear the infernal way that everything in type theory depends on everything else.
 [^3]: Please forgive my HoTT accent.
--- a/site.hs
+++ b/site.hs
@ -0,0 +1,321 @@
 {-# LANGUAGE BangPatterns #-}
 {-# LANGUAGE MultiWayIf #-}
 {-# LANGUAGE OverloadedStrings #-}

 import qualified Data.ByteString.Lazy.Char8 as BS
 import Data.Functor

 import Control.Concurrent
 import Control.Exception
 import Control.DeepSeq (rnf)
 import Control.Monad

 import Text.Pandoc.Highlighting
 import Text.Pandoc.Options
 import Text.Pandoc.Definition
 import Text.Sass.Functions
 import Text.Pandoc.Walk (query, walkM)

 import Hakyll.Core.Compiler
 import Hakyll.Web.Sass
 import Hakyll

 import qualified Skylighting as Sky

 import Data.ByteString.Lazy.Char8 (pack, unpack)
 import qualified Network.URI.Encode as URI (encode)

 import System.Environment
 import System.Process
 import System.Exit
 import System.IO

 import qualified Data.Text as T
 import qualified Data.Text.Encoding as T
 import Hakyll.Core.Compiler.Internal
 import Data.List
 import Data.Char
 import qualified Data.Map.Strict as Map
 import Data.Monoid

 import Debug.Trace
 import Data.Maybe

 readerOpts :: ReaderOptions
 readerOpts = def { readerExtensions = pandocExtensions
 , readerIndentedCodeClasses = ["amulet"] }

 writerOptions :: Compiler WriterOptions
 writerOptions = do
 syntaxMap <- loadAllSnapshots "syntax/*.xml" "syntax"
 <&> foldr (Sky.addSyntaxDefinition . itemBody) Sky.defaultSyntaxMap

 pure $ defaultHakyllWriterOptions
 { writerExtensions = extensionsFromList
 [ Ext_tex_math_dollars
 , Ext_tex_math_double_backslash
 , Ext_latex_macros
 ] <> writerExtensions defaultHakyllWriterOptions
 , writerSyntaxMap = syntaxMap
 , writerHighlightStyle = Just kate
 }

 rssfeed :: FeedConfiguration
 rssfeed
 = FeedConfiguration { feedTitle = "Abigail's Blag: Latest articles"
 , feedDescription = ""
 , feedAuthorName = "Abigail Magalhães"
 , feedAuthorEmail = "[email protected]"
 , feedRoot = "https://abby.how"
 }

 conf :: Configuration
 conf = def { destinationDirectory = ".site"
 , storeDirectory = ".store"
 , tmpDirectory = ".store/tmp"
 , deployCommand = "./sync" }

 tikzFilter :: Block -> Compiler Block
 tikzFilter (CodeBlock (id, "tikzpicture":extraClasses, namevals) contents) =
 (imageBlock . T.pack . ("data:image/svg+xml;utf8," <>) . URI.encode . filter (/= '\n') . T.unpack . itemBody <$>) $
 makeItem contents
 >>= loadAndApplyTemplate (fromFilePath "templates/tikz.tex") (bodyField "body") . fmap T.unpack
 >>= withItemBody (pure . BS.fromStrict . T.encodeUtf8
 >=> unixFilterLBS "rubber-pipe" ["--pdf"] 
 >=> unixFilterLBS "pdftocairo" ["-svg", "-", "-"] 
 >=> pure . T.decodeUtf8 . BS.toStrict)
 . fmap T.pack
 where imageBlock fname = Para [Image (id, "tikzpicture":extraClasses, namevals) [] (fname, "")]
 tikzFilter x = return x

 katexFilter :: Pandoc -> Compiler Pandoc
 katexFilter (Pandoc meta doc) = do
 id <- compilerUnderlying <$> compilerAsk
 t <- getMetadata id
 case lookupString "fastbuild" t of
 Just _ -> pure (Pandoc meta doc)
 Nothing -> Pandoc meta <$> walkM go doc
 where
 go :: Inline -> Compiler Inline
 go (Math kind math) = unsafeCompiler $ do
 let args =
 case kind of
 DisplayMath -> ["-Std"]
 InlineMath -> ["-St"]
 (contents, _) <- readProcessBS "node_modules/.bin/katex" args . BS.fromStrict . T.encodeUtf8 $ math
 pure . RawInline "html" . T.init . T.init . T.decodeUtf8 . BS.toStrict $ contents
 go x = pure x

 estimateReadingTime :: Pandoc -> Pandoc
 estimateReadingTime (Pandoc meta doc) = Pandoc meta doc' where
 wordCount = T.pack (show (getSum (query inlineLen doc)))

 inlineLen (Str s) = Sum (length (T.words s))
 inlineLen _ = mempty

 doc' = RawBlock "html" ("<span id=reading-length>" <> wordCount <> "</span>")
 : doc

 addLanguageTag :: Block -> Block
 addLanguageTag block@(CodeBlock (identifier, classes@(language:classes'), kv) text) = 
 Div
 ( mempty
 , "code-container":if haskv then "custom-tag":classes' else classes'
 , []
 )
 [Plain [Span (mempty, [], []) [Str tag]], block]
 where
 language' = case T.uncons language of
 Nothing -> mempty
 Just (c, cs) -> T.cons (toUpper c) cs
 tag = fromMaybe language' (lookup "tag" kv)
 haskv = fromMaybe False (True <$ lookup "tag" kv)

 addLanguageTag block@(CodeBlock (identifier, [], kv) text) = Div (mempty, ["code-container"], []) [block]

 addLanguageTag x = x

 sassImporter :: SassImporter
 sassImporter = SassImporter 0 go where
 go "normalize" _ = do
 c <- readFile "node_modules/normalize.css/normalize.css"
 pure [ SassImport { importPath = Nothing
 , importAbsolutePath = Nothing
 , importSource = Just c
 , importSourceMap = Nothing
 } ]
 go _ _ = pure []

 main :: IO ()
 main = (*>) (setEnv "AMC_LIBRARY_PATH" "/usr/lib/amuletml/lib/") $ hakyllWith conf $ do
 let compiler = do
 wops <- writerOptions
 pandocCompilerWithTransformM readerOpts wops $
 walkM tikzFilter
 >=> katexFilter
 >=> pure . estimateReadingTime
 >=> walkM (pure . addLanguageTag)

 match "static/**/*" $ do
 route idRoute
 compile copyFileCompiler

 match "css/**/*" $ do
 route idRoute
 compile copyFileCompiler

 match "css/*.css" $ do
 route idRoute
 compile copyFileCompiler

 match "css/*.scss" $ do
 route $ setExtension "css"
 compile $ sassCompilerWith def { sassOutputStyle = SassStyleCompressed
 , sassImporters = Just [ sassImporter ]
 }

 match "diagrams/**/*.tex" $ do
 route $ setExtension "svg"
 compile $ getResourceBody
 >>= loadAndApplyTemplate "templates/tikz.tex" (bodyField "body")
 >>= withItemBody (return . pack 
 >=> unixFilterLBS "rubber-pipe" ["--pdf"]
 >=> unixFilterLBS "pdftocairo" ["-svg", "-", "-"]
 >=> return . unpack)


 match "pages/posts/*" $ do
 route $ metadataRoute pathFromTitle

 compile $ compiler
 >>= loadAndApplyTemplate "templates/post.html" postCtx
 >>= saveSnapshot "content"
 >>= loadAndApplyTemplate "templates/default.html" postCtx
 >>= relativizeUrls

 create ["archive.html"] $ do
 route idRoute
 compile $ do
 posts <- recentFirst =<< loadAll "posts/*"
 let archiveCtx =
 listField "posts" postCtx (return posts) <>
 constField "title" "Archives" <>
 defaultContext
 makeItem ""
 >>= loadAndApplyTemplate "templates/archive.html" archiveCtx
 >>= loadAndApplyTemplate "templates/default.html" archiveCtx
 >>= relativizeUrls

 match "pages/*.html" $ do
 route $ gsubRoute "pages/" (const "")
 compile $ do
 posts <- fmap (take 5) . recentFirst =<< loadAll "posts/*"
 let indexCtx =
 listField "posts" postCtx (return posts) <>
 constField "title" "Home" <>
 defaultContext
 getResourceBody
 >>= applyAsTemplate indexCtx
 >>= loadAndApplyTemplate "templates/default.html" indexCtx
 >>= relativizeUrls

 match "pages/*.md" $ do
 route $ gsubRoute "pages/" (const "") <> setExtension "html"
 compile $ compiler
 >>= loadAndApplyTemplate "templates/default.html" defaultContext
 >>= relativizeUrls

 match "syntax/*.xml" $ compile $ do
 path <- toFilePath <$> getUnderlying
 contents <- itemBody <$> getResourceBody
 debugCompiler ("Loaded syntax definition from " ++ show path)
 res <- unsafeCompiler (Sky.parseSyntaxDefinitionFromString path contents)
 _ <- saveSnapshot "syntax" =<< case res of
 Left e -> fail e
 Right x -> makeItem x
 makeItem contents

 match "templates/*" $ compile templateBodyCompiler

 create ["feed.xml"] $ do
 route idRoute
 compile $ do
 let feedCtx = postCtx <> bodyField "description"
 posts <- (take 10 <$>) . recentFirst =<< loadAllSnapshots "posts/*" "content"
 renderRss rssfeed feedCtx posts

 postCtx :: Context String
 postCtx =
 dateField "date" "%B %e, %Y"
 <> defaultContext

 readProcessBS :: FilePath -> [String] -> BS.ByteString -> IO (BS.ByteString, String)
 readProcessBS path args input =
 let process = (proc path args)
 { std_in = CreatePipe
 , std_out = CreatePipe
 , std_err = CreatePipe
 }
 in withCreateProcess process $ \stdin stdout stderr ph ->
 case (stdin, stdout, stderr) of
 (Nothing, _, _) -> fail "Failed to get a stdin handle."
 (_, Nothing, _) -> fail "Failed to get a stdout handle."
 (_, _, Nothing) -> fail "Failed to get a stderr handle."
 (Just stdin, Just stdout, Just stderr) -> do
 out <- BS.hGetContents stdout
 err <- hGetContents stderr

 withForkWait (evaluate $ rnf out) $ \waitOut ->
 withForkWait (evaluate $ rnf err) $ \waitErr -> do
 -- Write input and close.
 BS.hPutStr stdin input
 hClose stdin

 -- wait on the output
 waitOut
 waitErr

 hClose stdout
 hClose stderr

 -- wait on the process
 ex <- waitForProcess ph
 case ex of
 ExitSuccess -> pure (out, err)
 ExitFailure ex -> fail (err ++ "Exited with " ++ show ex)

 where
 withForkWait :: IO () -> (IO () -> IO a) -> IO a
 withForkWait async body = do
 waitVar <- newEmptyMVar :: IO (MVar (Either SomeException ()))
 mask $ \restore -> do
 tid <- forkIO $ try (restore async) >>= putMVar waitVar
 let wait = takeMVar waitVar >>= either throwIO return
 restore (body wait) `onException` killThread tid

 pathFromTitle :: Metadata -> Routes
 pathFromTitle meta =
 let
 declaredCategory =
 case lookupString "category" meta of
 Just s -> ((s ++ "/") ++)
 Nothing -> ("posts/" <>)

 !titleString =
 case lookupString "title" meta of
 Just s -> s
 Nothing -> error "post has no title?"
 
 title = filter (/= "") . map (filter isAlphaNum . map toLower) . words $ titleString

 (category, title') =
 if | "or" `elem` title -> (declaredCategory, takeWhile (/= "or") title)
 | ["a", "quickie"] `isPrefixOf` title -> (("quick/" ++), drop 2 title)
 | otherwise -> (declaredCategory, title)
 in
 case lookupString "path" meta of
 Just p -> constRoute (category (p <> ".html"))
 Nothing -> constRoute (category (intercalate "-" title' <> ".html"))

 foldMapM :: (Monad w, Monoid m, Foldable f) => (a -> w m) -> f a -> w m
 foldMapM k = foldr (\x y -> do { m <- k x; (m <>) <$> y }) (pure mempty)
--- a/stack.yaml
+++ b/stack.yaml
@ -0,0 +1,6 @@
 resolver: lts-16.20

 extra-deps:
 - hakyll-sass-0.2.4@sha256:4d2fbd8b63f5ef15483fc6dda09e10eefd63b4f873ad38dec2a3607eb504a8ba,939
 - hsass-0.8.0@sha256:05fb3d435dbdf9f66a98db4e1ee57a313170a677e52ab3a5a05ced1fc42b0834,2899
 - hlibsass-0.1.10.1@sha256:08db56c633e9a83a642d8ea57dffa93112b092d05bf8f3b07491cfee9ee0dfa5,2565
--- a/stack.yaml.lock
+++ b/stack.yaml.lock
@ -0,0 +1,33 @@
 # This file was autogenerated by Stack.
 # You should not edit this file by hand.
 # For more information, please see the documentation at:
 # https://docs.haskellstack.org/en/stable/lock_files

 packages:
 - completed:
 hackage: hakyll-sass-0.2.4@sha256:4d2fbd8b63f5ef15483fc6dda09e10eefd63b4f873ad38dec2a3607eb504a8ba,939
 pantry-tree:
 size: 217
 sha256: c03e74e71d010f009b8d972efc31fbd6dd25183e6d9afbec55f4b7f0d4a74b47
 original:
 hackage: hakyll-sass-0.2.4@sha256:4d2fbd8b63f5ef15483fc6dda09e10eefd63b4f873ad38dec2a3607eb504a8ba,939
 - completed:
 hackage: hsass-0.8.0@sha256:05fb3d435dbdf9f66a98db4e1ee57a313170a677e52ab3a5a05ced1fc42b0834,2899
 pantry-tree:
 size: 1448
 sha256: b25aeb947cb4e0b550f8a6f226d06503ef0edcb54712ad9cdd4fb2b05bf16c7c
 original:
 hackage: hsass-0.8.0@sha256:05fb3d435dbdf9f66a98db4e1ee57a313170a677e52ab3a5a05ced1fc42b0834,2899
 - completed:
 hackage: hlibsass-0.1.10.1@sha256:08db56c633e9a83a642d8ea57dffa93112b092d05bf8f3b07491cfee9ee0dfa5,2565
 pantry-tree:
 size: 11229
 sha256: 39b62f1f3f30c5a9e12f9c6a040d6863edb5ce81951452e649152a18145ee1bc
 original:
 hackage: hlibsass-0.1.10.1@sha256:08db56c633e9a83a642d8ea57dffa93112b092d05bf8f3b07491cfee9ee0dfa5,2565
 snapshots:
 - completed:
 size: 532177
 url: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/16/20.yaml
 sha256: 0e14ba5603f01e8496e8984fd84b545a012ca723f51a098c6c9d3694e404dc6d
 original: lts-16.20
--- a/static/Parser.hs
+++ b/static/Parser.hs
@ -0,0 +1,140 @@
 {-# LANGUAGE LambdaCase #-}
 module Parser
 ( Parser()
 , module X
 , Parser.any
 , satisfy
 , string
 , digit
 , number
 , spaces
 , reserved
 , lexeme
 , (<?>)
 , runParser
 , between ) where

 import Control.Applicative as X
 import Control.Monad as X

 import Data.Char

 newtype Parser a
 = Parser { parse :: String -> Either String (a, String) }

 runParser :: Parser a -> String -> Either String a
 runParser (Parser p) s = fst <$> p s

 (<?>) :: Parser a -> String -> Parser a
 p <?> err = p <|> fail err
 infixl 2 <?>

 instance Functor Parser where
 fn `fmap` (Parser p) = Parser go where
 go st = case p st of
 Left e -> Left e
 Right (res, str') -> Right (fn res, str')

 instance Applicative Parser where
 pure x = Parser $ \str -> Right (x, str)
 (Parser p) <*> (Parser p') = Parser go where
 go st = case p st of
 Left e -> Left e
 Right (fn, st') -> case p' st' of
 Left e' -> Left e'
 Right (v, st'') -> Right (fn v, st'')

 instance Alternative Parser where
 empty = fail "nothing"
 (Parser p) <|> (Parser p') = Parser go where
 go st = case p st of
 Left _ -> p' st
 Right x -> Right x

 instance Monad Parser where
 return = pure
 (Parser p) >>= f = Parser go where
 go s = case p s of
 Left e -> Left e
 Right (x, s') -> parse (f x) s'
 fail m = Parser go where
 go = Left . go'
 go' [] = "expected " ++ m ++ ", got to the end of stream"
 go' (x:xs) = "expected " ++ m ++ ", got '" ++ x:"'"
 

 any :: Parser Char
 any = Parser go where
 go [] = Left "any: end of file"
 go (x:xs) = Right (x,xs)

 satisfy :: (Char -> Bool) -> Parser Char
 satisfy f = do
 x <- Parser.any
 if f x
 then return x
 else fail "a solution to the function"


 char :: Char -> Parser Char
 char c = satisfy (c ==) <?> "literal " ++ [c]

 oneOf :: String -> Parser Char
 oneOf s = satisfy (`elem` s) <?> "one of '" ++ s ++ "'"

 string :: String -> Parser String
 string [] = return []
 string (x:xs) = do
 char x
 string xs
 return $ x:xs

 natural :: Parser Integer
 natural = read <$> some (satisfy isDigit)

 lexeme :: Parser a -> Parser a
 lexeme = (<* spaces)

 reserved :: String -> Parser String
 reserved = lexeme . string

 spaces :: Parser String
 spaces = many $ oneOf " \n\r"

 digit :: Parser Char
 digit = satisfy isDigit

 number :: Parser Int
 number = do
 s <- string "-" <|> empty
 cs <- some digit
 return $ read (s ++ cs)

 between :: Parser b -> Parser c -> Parser a -> Parser a
 between o c x = o *> x <* c

 contents :: Parser a -> Parser a
 contents x = spaces *> x <* spaces

 sep :: Parser b -> Parser a -> Parser [a]
 sep s c = sep1 s c <|> return []

 sep1 :: Parser b -> Parser a -> Parser [a]
 sep1 s c = do
 x <- c
 xs <- many $ s >> c
 return $ x:xs

 option :: a -> Parser a -> Parser a
 option x p = p <|> return x

 optionMaybe :: Parser a -> Parser (Maybe a)
 optionMaybe p = option Nothing $ Just <$> p

 optional :: Parser a -> Parser ()
 optional p = void p <|> return ()

 eof :: Parser ()
 eof = Parser go where
 go (x:_) = Left $ "expected eof, got '" ++ x:"'"
 go [] = Right ((), [])
--- a/static/Parser.hs.html
+++ b/static/Parser.hs.html
@ -0,0 +1,239 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 <title>~/Projects/blag/static/Parser.hs.html</title>
 <meta name="Generator" content="Vim/7.4">
 <meta name="plugin-version" content="vim7.4_v2">
 <meta name="syntax" content="haskell">
 <meta name="settings" content="use_css,pre_wrap,no_foldcolumn,expand_tabs,prevent_copy=t">
 <meta name="colorscheme" content="onedark">
 <style type="text/css">
 <!--
 pre { white-space: pre-wrap; font-family: 'Iosevka', monospace; color: #ABB2BF; background-color: #282C34; }
 body { font-family: 'Iosevka', monospace; color: #ABB2BF; background-color: #282C34; }
 * { font-size: 1em; }
 input { border: none; margin: 0; padding: 0; font-family: 'Iosevka', monospace; }
 input[size='1'] { width: 1em; width: 1ch; }
 input[size='2'] { width: 2em; width: 2ch; }
 input[size='3'] { width: 3em; width: 3ch; }
 input[size='4'] { width: 4em; width: 4ch; }
 input[size='5'] { width: 5em; width: 5ch; }
 input[size='6'] { width: 6em; width: 6ch; }
 input[size='7'] { width: 7em; width: 7ch; }
 input[size='8'] { width: 8em; width: 8ch; }
 input[size='9'] { width: 9em; width: 9ch; }
 input[size='10'] { width: 10em; width: 10ch; }
 input[size='11'] { width: 11em; width: 11ch; }
 input[size='12'] { width: 12em; width: 12ch; }
 input[size='13'] { width: 13em; width: 13ch; }
 input[size='14'] { width: 14em; width: 14ch; }
 input[size='15'] { width: 15em; width: 15ch; }
 input[size='16'] { width: 16em; width: 16ch; }
 input[size='17'] { width: 17em; width: 17ch; }
 input[size='18'] { width: 18em; width: 18ch; }
 input[size='19'] { width: 19em; width: 19ch; }
 input[size='20'] { width: 20em; width: 20ch; }
 #oneCharWidth, #oneEmWidth, #oneInputWidth { padding: 0; margin: 0; position: absolute; left: -999999px; visibility: hidden; }
 .em5 input[size='1'] { width: 0.05em; } .em5 input[size='2'] { width: 0.1em; } .em5 input[size='3'] { width: 0.15em; } .em5 input[size='4'] { width: 0.2em; } .em5 input[size='5'] { width: 0.25em; } .em5 input[size='6'] { width: 0.3em; } .em5 input[size='7'] { width: 0.35em; } .em5 input[size='8'] { width: 0.4em; } .em5 input[size='9'] { width: 0.45em; } .em5 input[size='10'] { width: 0.5em; } .em5 input[size='11'] { width: 0.55em; } .em5 input[size='12'] { width: 0.6em; } .em5 input[size='13'] { width: 0.65em; } .em5 input[size='14'] { width: 0.7em; } .em5 input[size='15'] { width: 0.75em; } .em5 input[size='16'] { width: 0.8em; } .em5 input[size='17'] { width: 0.85em; } .em5 input[size='18'] { width: 0.9em; } .em5 input[size='19'] { width: 0.95em; } .em5 input[size='20'] { width: 1.0em; }
 .em10 input[size='1'] { width: 0.1em; } .em10 input[size='2'] { width: 0.2em; } .em10 input[size='3'] { width: 0.3em; } .em10 input[size='4'] { width: 0.4em; } .em10 input[size='5'] { width: 0.5em; } .em10 input[size='6'] { width: 0.6em; } .em10 input[size='7'] { width: 0.7em; } .em10 input[size='8'] { width: 0.8em; } .em10 input[size='9'] { width: 0.9em; } .em10 input[size='10'] { width: 1.0em; } .em10 input[size='11'] { width: 1.1em; } .em10 input[size='12'] { width: 1.2em; } .em10 input[size='13'] { width: 1.3em; } .em10 input[size='14'] { width: 1.4em; } .em10 input[size='15'] { width: 1.5em; } .em10 input[size='16'] { width: 1.6em; } .em10 input[size='17'] { width: 1.7em; } .em10 input[size='18'] { width: 1.8em; } .em10 input[size='19'] { width: 1.9em; } .em10 input[size='20'] { width: 2.0em; }
 .em15 input[size='1'] { width: 0.15em; } .em15 input[size='2'] { width: 0.3em; } .em15 input[size='3'] { width: 0.45em; } .em15 input[size='4'] { width: 0.6em; } .em15 input[size='5'] { width: 0.75em; } .em15 input[size='6'] { width: 0.9em; } .em15 input[size='7'] { width: 1.05em; } .em15 input[size='8'] { width: 1.2em; } .em15 input[size='9'] { width: 1.35em; } .em15 input[size='10'] { width: 1.5em; } .em15 input[size='11'] { width: 1.65em; } .em15 input[size='12'] { width: 1.8em; } .em15 input[size='13'] { width: 1.95em; } .em15 input[size='14'] { width: 2.1em; } .em15 input[size='15'] { width: 2.25em; } .em15 input[size='16'] { width: 2.4em; } .em15 input[size='17'] { width: 2.55em; } .em15 input[size='18'] { width: 2.7em; } .em15 input[size='19'] { width: 2.85em; } .em15 input[size='20'] { width: 3.0em; }
 .em20 input[size='1'] { width: 0.2em; } .em20 input[size='2'] { width: 0.4em; } .em20 input[size='3'] { width: 0.6em; } .em20 input[size='4'] { width: 0.8em; } .em20 input[size='5'] { width: 1.0em; } .em20 input[size='6'] { width: 1.2em; } .em20 input[size='7'] { width: 1.4em; } .em20 input[size='8'] { width: 1.6em; } .em20 input[size='9'] { width: 1.8em; } .em20 input[size='10'] { width: 2.0em; } .em20 input[size='11'] { width: 2.2em; } .em20 input[size='12'] { width: 2.4em; } .em20 input[size='13'] { width: 2.6em; } .em20 input[size='14'] { width: 2.8em; } .em20 input[size='15'] { width: 3.0em; } .em20 input[size='16'] { width: 3.2em; } .em20 input[size='17'] { width: 3.4em; } .em20 input[size='18'] { width: 3.6em; } .em20 input[size='19'] { width: 3.8em; } .em20 input[size='20'] { width: 4.0em; }
 .em25 input[size='1'] { width: 0.25em; } .em25 input[size='2'] { width: 0.5em; } .em25 input[size='3'] { width: 0.75em; } .em25 input[size='4'] { width: 1.0em; } .em25 input[size='5'] { width: 1.25em; } .em25 input[size='6'] { width: 1.5em; } .em25 input[size='7'] { width: 1.75em; } .em25 input[size='8'] { width: 2.0em; } .em25 input[size='9'] { width: 2.25em; } .em25 input[size='10'] { width: 2.5em; } .em25 input[size='11'] { width: 2.75em; } .em25 input[size='12'] { width: 3.0em; } .em25 input[size='13'] { width: 3.25em; } .em25 input[size='14'] { width: 3.5em; } .em25 input[size='15'] { width: 3.75em; } .em25 input[size='16'] { width: 4.0em; } .em25 input[size='17'] { width: 4.25em; } .em25 input[size='18'] { width: 4.5em; } .em25 input[size='19'] { width: 4.75em; } .em25 input[size='20'] { width: 5.0em; }
 .em30 input[size='1'] { width: 0.3em; } .em30 input[size='2'] { width: 0.6em; } .em30 input[size='3'] { width: 0.9em; } .em30 input[size='4'] { width: 1.2em; } .em30 input[size='5'] { width: 1.5em; } .em30 input[size='6'] { width: 1.8em; } .em30 input[size='7'] { width: 2.1em; } .em30 input[size='8'] { width: 2.4em; } .em30 input[size='9'] { width: 2.7em; } .em30 input[size='10'] { width: 3.0em; } .em30 input[size='11'] { width: 3.3em; } .em30 input[size='12'] { width: 3.6em; } .em30 input[size='13'] { width: 3.9em; } .em30 input[size='14'] { width: 4.2em; } .em30 input[size='15'] { width: 4.5em; } .em30 input[size='16'] { width: 4.8em; } .em30 input[size='17'] { width: 5.1em; } .em30 input[size='18'] { width: 5.4em; } .em30 input[size='19'] { width: 5.7em; } .em30 input[size='20'] { width: 6.0em; }
 .em35 input[size='1'] { width: 0.35em; } .em35 input[size='2'] { width: 0.7em; } .em35 input[size='3'] { width: 1.05em; } .em35 input[size='4'] { width: 1.4em; } .em35 input[size='5'] { width: 1.75em; } .em35 input[size='6'] { width: 2.1em; } .em35 input[size='7'] { width: 2.45em; } .em35 input[size='8'] { width: 2.8em; } .em35 input[size='9'] { width: 3.15em; } .em35 input[size='10'] { width: 3.5em; } .em35 input[size='11'] { width: 3.85em; } .em35 input[size='12'] { width: 4.2em; } .em35 input[size='13'] { width: 4.55em; } .em35 input[size='14'] { width: 4.9em; } .em35 input[size='15'] { width: 5.25em; } .em35 input[size='16'] { width: 5.6em; } .em35 input[size='17'] { width: 5.95em; } .em35 input[size='18'] { width: 6.3em; } .em35 input[size='19'] { width: 6.65em; } .em35 input[size='20'] { width: 7.0em; }
 .em40 input[size='1'] { width: 0.4em; } .em40 input[size='2'] { width: 0.8em; } .em40 input[size='3'] { width: 1.2em; } .em40 input[size='4'] { width: 1.6em; } .em40 input[size='5'] { width: 2.0em; } .em40 input[size='6'] { width: 2.4em; } .em40 input[size='7'] { width: 2.8em; } .em40 input[size='8'] { width: 3.2em; } .em40 input[size='9'] { width: 3.6em; } .em40 input[size='10'] { width: 4.0em; } .em40 input[size='11'] { width: 4.4em; } .em40 input[size='12'] { width: 4.8em; } .em40 input[size='13'] { width: 5.2em; } .em40 input[size='14'] { width: 5.6em; } .em40 input[size='15'] { width: 6.0em; } .em40 input[size='16'] { width: 6.4em; } .em40 input[size='17'] { width: 6.8em; } .em40 input[size='18'] { width: 7.2em; } .em40 input[size='19'] { width: 7.6em; } .em40 input[size='20'] { width: 8.0em; }
 .em45 input[size='1'] { width: 0.45em; } .em45 input[size='2'] { width: 0.9em; } .em45 input[size='3'] { width: 1.35em; } .em45 input[size='4'] { width: 1.8em; } .em45 input[size='5'] { width: 2.25em; } .em45 input[size='6'] { width: 2.7em; } .em45 input[size='7'] { width: 3.15em; } .em45 input[size='8'] { width: 3.6em; } .em45 input[size='9'] { width: 4.05em; } .em45 input[size='10'] { width: 4.5em; } .em45 input[size='11'] { width: 4.95em; } .em45 input[size='12'] { width: 5.4em; } .em45 input[size='13'] { width: 5.85em; } .em45 input[size='14'] { width: 6.3em; } .em45 input[size='15'] { width: 6.75em; } .em45 input[size='16'] { width: 7.2em; } .em45 input[size='17'] { width: 7.65em; } .em45 input[size='18'] { width: 8.1em; } .em45 input[size='19'] { width: 8.55em; } .em45 input[size='20'] { width: 9.0em; }
 .em50 input[size='1'] { width: 0.5em; } .em50 input[size='2'] { width: 1.0em; } .em50 input[size='3'] { width: 1.5em; } .em50 input[size='4'] { width: 2.0em; } .em50 input[size='5'] { width: 2.5em; } .em50 input[size='6'] { width: 3.0em; } .em50 input[size='7'] { width: 3.5em; } .em50 input[size='8'] { width: 4.0em; } .em50 input[size='9'] { width: 4.5em; } .em50 input[size='10'] { width: 5.0em; } .em50 input[size='11'] { width: 5.5em; } .em50 input[size='12'] { width: 6.0em; } .em50 input[size='13'] { width: 6.5em; } .em50 input[size='14'] { width: 7.0em; } .em50 input[size='15'] { width: 7.5em; } .em50 input[size='16'] { width: 8.0em; } .em50 input[size='17'] { width: 8.5em; } .em50 input[size='18'] { width: 9.0em; } .em50 input[size='19'] { width: 9.5em; } .em50 input[size='20'] { width: 10.0em; }
 .em55 input[size='1'] { width: 0.55em; } .em55 input[size='2'] { width: 1.1em; } .em55 input[size='3'] { width: 1.65em; } .em55 input[size='4'] { width: 2.2em; } .em55 input[size='5'] { width: 2.75em; } .em55 input[size='6'] { width: 3.3em; } .em55 input[size='7'] { width: 3.85em; } .em55 input[size='8'] { width: 4.4em; } .em55 input[size='9'] { width: 4.95em; } .em55 input[size='10'] { width: 5.5em; } .em55 input[size='11'] { width: 6.05em; } .em55 input[size='12'] { width: 6.6em; } .em55 input[size='13'] { width: 7.15em; } .em55 input[size='14'] { width: 7.7em; } .em55 input[size='15'] { width: 8.25em; } .em55 input[size='16'] { width: 8.8em; } .em55 input[size='17'] { width: 9.35em; } .em55 input[size='18'] { width: 9.9em; } .em55 input[size='19'] { width: 10.45em; } .em55 input[size='20'] { width: 11.0em; }
 .em60 input[size='1'] { width: 0.6em; } .em60 input[size='2'] { width: 1.2em; } .em60 input[size='3'] { width: 1.8em; } .em60 input[size='4'] { width: 2.4em; } .em60 input[size='5'] { width: 3.0em; } .em60 input[size='6'] { width: 3.6em; } .em60 input[size='7'] { width: 4.2em; } .em60 input[size='8'] { width: 4.8em; } .em60 input[size='9'] { width: 5.4em; } .em60 input[size='10'] { width: 6.0em; } .em60 input[size='11'] { width: 6.6em; } .em60 input[size='12'] { width: 7.2em; } .em60 input[size='13'] { width: 7.8em; } .em60 input[size='14'] { width: 8.4em; } .em60 input[size='15'] { width: 9.0em; } .em60 input[size='16'] { width: 9.6em; } .em60 input[size='17'] { width: 10.2em; } .em60 input[size='18'] { width: 10.8em; } .em60 input[size='19'] { width: 11.4em; } .em60 input[size='20'] { width: 12.0em; }
 .em65 input[size='1'] { width: 0.65em; } .em65 input[size='2'] { width: 1.3em; } .em65 input[size='3'] { width: 1.95em; } .em65 input[size='4'] { width: 2.6em; } .em65 input[size='5'] { width: 3.25em; } .em65 input[size='6'] { width: 3.9em; } .em65 input[size='7'] { width: 4.55em; } .em65 input[size='8'] { width: 5.2em; } .em65 input[size='9'] { width: 5.85em; } .em65 input[size='10'] { width: 6.5em; } .em65 input[size='11'] { width: 7.15em; } .em65 input[size='12'] { width: 7.8em; } .em65 input[size='13'] { width: 8.45em; } .em65 input[size='14'] { width: 9.1em; } .em65 input[size='15'] { width: 9.75em; } .em65 input[size='16'] { width: 10.4em; } .em65 input[size='17'] { width: 11.05em; } .em65 input[size='18'] { width: 11.7em; } .em65 input[size='19'] { width: 12.35em; } .em65 input[size='20'] { width: 13.0em; }
 .em70 input[size='1'] { width: 0.7em; } .em70 input[size='2'] { width: 1.4em; } .em70 input[size='3'] { width: 2.1em; } .em70 input[size='4'] { width: 2.8em; } .em70 input[size='5'] { width: 3.5em; } .em70 input[size='6'] { width: 4.2em; } .em70 input[size='7'] { width: 4.9em; } .em70 input[size='8'] { width: 5.6em; } .em70 input[size='9'] { width: 6.3em; } .em70 input[size='10'] { width: 7.0em; } .em70 input[size='11'] { width: 7.7em; } .em70 input[size='12'] { width: 8.4em; } .em70 input[size='13'] { width: 9.1em; } .em70 input[size='14'] { width: 9.8em; } .em70 input[size='15'] { width: 10.5em; } .em70 input[size='16'] { width: 11.2em; } .em70 input[size='17'] { width: 11.9em; } .em70 input[size='18'] { width: 12.6em; } .em70 input[size='19'] { width: 13.3em; } .em70 input[size='20'] { width: 14.0em; }
 .em75 input[size='1'] { width: 0.75em; } .em75 input[size='2'] { width: 1.5em; } .em75 input[size='3'] { width: 2.25em; } .em75 input[size='4'] { width: 3.0em; } .em75 input[size='5'] { width: 3.75em; } .em75 input[size='6'] { width: 4.5em; } .em75 input[size='7'] { width: 5.25em; } .em75 input[size='8'] { width: 6.0em; } .em75 input[size='9'] { width: 6.75em; } .em75 input[size='10'] { width: 7.5em; } .em75 input[size='11'] { width: 8.25em; } .em75 input[size='12'] { width: 9.0em; } .em75 input[size='13'] { width: 9.75em; } .em75 input[size='14'] { width: 10.5em; } .em75 input[size='15'] { width: 11.25em; } .em75 input[size='16'] { width: 12.0em; } .em75 input[size='17'] { width: 12.75em; } .em75 input[size='18'] { width: 13.5em; } .em75 input[size='19'] { width: 14.25em; } .em75 input[size='20'] { width: 15.0em; }
 .em80 input[size='1'] { width: 0.8em; } .em80 input[size='2'] { width: 1.6em; } .em80 input[size='3'] { width: 2.4em; } .em80 input[size='4'] { width: 3.2em; } .em80 input[size='5'] { width: 4.0em; } .em80 input[size='6'] { width: 4.8em; } .em80 input[size='7'] { width: 5.6em; } .em80 input[size='8'] { width: 6.4em; } .em80 input[size='9'] { width: 7.2em; } .em80 input[size='10'] { width: 8.0em; } .em80 input[size='11'] { width: 8.8em; } .em80 input[size='12'] { width: 9.6em; } .em80 input[size='13'] { width: 10.4em; } .em80 input[size='14'] { width: 11.2em; } .em80 input[size='15'] { width: 12.0em; } .em80 input[size='16'] { width: 12.8em; } .em80 input[size='17'] { width: 13.6em; } .em80 input[size='18'] { width: 14.4em; } .em80 input[size='19'] { width: 15.2em; } .em80 input[size='20'] { width: 16.0em; }
 .em85 input[size='1'] { width: 0.85em; } .em85 input[size='2'] { width: 1.7em; } .em85 input[size='3'] { width: 2.55em; } .em85 input[size='4'] { width: 3.4em; } .em85 input[size='5'] { width: 4.25em; } .em85 input[size='6'] { width: 5.1em; } .em85 input[size='7'] { width: 5.95em; } .em85 input[size='8'] { width: 6.8em; } .em85 input[size='9'] { width: 7.65em; } .em85 input[size='10'] { width: 8.5em; } .em85 input[size='11'] { width: 9.35em; } .em85 input[size='12'] { width: 10.2em; } .em85 input[size='13'] { width: 11.05em; } .em85 input[size='14'] { width: 11.9em; } .em85 input[size='15'] { width: 12.75em; } .em85 input[size='16'] { width: 13.6em; } .em85 input[size='17'] { width: 14.45em; } .em85 input[size='18'] { width: 15.3em; } .em85 input[size='19'] { width: 16.15em; } .em85 input[size='20'] { width: 17.0em; }
 .em90 input[size='1'] { width: 0.9em; } .em90 input[size='2'] { width: 1.8em; } .em90 input[size='3'] { width: 2.7em; } .em90 input[size='4'] { width: 3.6em; } .em90 input[size='5'] { width: 4.5em; } .em90 input[size='6'] { width: 5.4em; } .em90 input[size='7'] { width: 6.3em; } .em90 input[size='8'] { width: 7.2em; } .em90 input[size='9'] { width: 8.1em; } .em90 input[size='10'] { width: 9.0em; } .em90 input[size='11'] { width: 9.9em; } .em90 input[size='12'] { width: 10.8em; } .em90 input[size='13'] { width: 11.7em; } .em90 input[size='14'] { width: 12.6em; } .em90 input[size='15'] { width: 13.5em; } .em90 input[size='16'] { width: 14.4em; } .em90 input[size='17'] { width: 15.3em; } .em90 input[size='18'] { width: 16.2em; } .em90 input[size='19'] { width: 17.1em; } .em90 input[size='20'] { width: 18.0em; }
 .em95 input[size='1'] { width: 0.95em; } .em95 input[size='2'] { width: 1.9em; } .em95 input[size='3'] { width: 2.85em; } .em95 input[size='4'] { width: 3.8em; } .em95 input[size='5'] { width: 4.75em; } .em95 input[size='6'] { width: 5.7em; } .em95 input[size='7'] { width: 6.65em; } .em95 input[size='8'] { width: 7.6em; } .em95 input[size='9'] { width: 8.55em; } .em95 input[size='10'] { width: 9.5em; } .em95 input[size='11'] { width: 10.45em; } .em95 input[size='12'] { width: 11.4em; } .em95 input[size='13'] { width: 12.35em; } .em95 input[size='14'] { width: 13.3em; } .em95 input[size='15'] { width: 14.25em; } .em95 input[size='16'] { width: 15.2em; } .em95 input[size='17'] { width: 16.15em; } .em95 input[size='18'] { width: 17.1em; } .em95 input[size='19'] { width: 18.05em; } .em95 input[size='20'] { width: 19.0em; }
 .em100 input[size='1'] { width: 1.0em; } .em100 input[size='2'] { width: 2.0em; } .em100 input[size='3'] { width: 3.0em; } .em100 input[size='4'] { width: 4.0em; } .em100 input[size='5'] { width: 5.0em; } .em100 input[size='6'] { width: 6.0em; } .em100 input[size='7'] { width: 7.0em; } .em100 input[size='8'] { width: 8.0em; } .em100 input[size='9'] { width: 9.0em; } .em100 input[size='10'] { width: 10.0em; } .em100 input[size='11'] { width: 11.0em; } .em100 input[size='12'] { width: 12.0em; } .em100 input[size='13'] { width: 13.0em; } .em100 input[size='14'] { width: 14.0em; } .em100 input[size='15'] { width: 15.0em; } .em100 input[size='16'] { width: 16.0em; } .em100 input[size='17'] { width: 17.0em; } .em100 input[size='18'] { width: 18.0em; } .em100 input[size='19'] { width: 19.0em; } .em100 input[size='20'] { width: 20.0em; }
 input.Folded { cursor: default; }
 .Conditional { color: #C678DD; }
 .Operator { color: #C678DD; }
 .Keyword { color: #E06C75; }
 .String { color: #98C379; }
 .Identifier { color: #E06C75; }
 .haskellType { color: #61AFEF; }
 .Structure { color: #E5C07B; }
 .Number { color: #D19A66; }
 -->
 </style>

 <script type='text/javascript'>
 <!--

 /* simulate a "ch" unit by asking the browser how big a zero character is */
 function FixCharWidth() {
 /* get the hidden element which gives the width of a single character */
 var goodWidth = document.getElementById("oneCharWidth").clientWidth;
 /* get all input elements, we'll filter on class later */
 var inputTags = document.getElementsByTagName("input");
 var ratio = 5;
 var inputWidth = document.getElementById("oneInputWidth").clientWidth;
 var emWidth = document.getElementById("oneEmWidth").clientWidth;
 if (inputWidth > goodWidth) {
 while (ratio < 100*goodWidth/emWidth && ratio < 100) {
 ratio += 5;
 }
 document.getElementById("vimCodeElement").className = "em"+ratio;
 }
 }

 -->
 </script>
 </head>
 <body onload='FixCharWidth();'>
 <!-- hidden divs used by javascript to get the width of a char -->
 <div id='oneCharWidth'>0</div>
 <div id='oneInputWidth'><input size='1' value='0'></div>
 <div id='oneEmWidth' style='width: 1em;'></div>
 <pre id='vimCodeElement'>
 {-# LANGUAGE LambdaCase #-}
 <span class="Structure">module</span> <span class="haskellType">Parser</span>
 ( <span class="haskellType">Parser</span>()
 , <span class="Structure">module</span> <span class="haskellType">X</span>
 , <span class="haskellType">Parser</span><span class="Operator">.</span>any
 , satisfy
 , string
 , digit
 , number
 , spaces
 , reserved
 , lexeme
 , (<span class="Operator">&lt;?&gt;</span>)
 , runParser
 , between ) <span class="Structure">where</span>

 <span class="Structure">import</span> <span class="haskellType">Control</span><span class="Operator">.</span><span class="haskellType">Applicative</span> <span class="Structure">as</span> <span class="haskellType">X</span>
 <span class="Structure">import</span> <span class="haskellType">Control</span><span class="Operator">.</span><span class="haskellType">Monad</span> <span class="Structure">as</span> <span class="haskellType">X</span>

 <span class="Structure">import</span> <span class="haskellType">Data</span><span class="Operator">.</span><span class="haskellType">Char</span>

 <span class="Structure">newtype</span> <span class="haskellType">Parser</span> a
 <span class="Operator">=</span> <span class="haskellType">Parser</span> { <span class="Identifier">parse</span> <span class="Operator">::</span> <span class="haskellType">String</span> <span class="Operator">-&gt;</span> <span class="haskellType">Either</span> <span class="haskellType">String</span> (a, <span class="haskellType">String</span>) }

 <span class="Identifier">runParser</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">String</span> <span class="Operator">-&gt;</span> <span class="haskellType">Either</span> <span class="haskellType">String</span> a
 runParser (<span class="haskellType">Parser</span> p) s <span class="Operator">=</span> fst <span class="Operator">&lt;$&gt;</span> p s

 (<span class="Operator">&lt;?&gt;</span>) <span class="Operator">::</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">String</span> <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a
 p <span class="Operator">&lt;?&gt;</span> err <span class="Operator">=</span> p <span class="Operator">&lt;|&gt;</span> fail err
 <span class="Keyword">infixl</span> <span class="Number">2</span> <span class="Operator">&lt;?&gt;</span>

 <span class="Structure">instance</span> <span class="haskellType">Functor</span> <span class="haskellType">Parser</span> <span class="Structure">where</span>
 fn <span class="Operator">`fmap`</span> (<span class="haskellType">Parser</span> p) <span class="Operator">=</span> <span class="haskellType">Parser</span> go <span class="Structure">where</span>
 go st <span class="Operator">=</span> <span class="Keyword">case</span> p st <span class="Keyword">of</span>
 <span class="haskellType">Left</span> e <span class="Operator">-&gt;</span> <span class="haskellType">Left</span> e
 <span class="haskellType">Right</span> (res, str') <span class="Operator">-&gt;</span> <span class="haskellType">Right</span> (fn res, str')

 <span class="Structure">instance</span> <span class="haskellType">Applicative</span> <span class="haskellType">Parser</span> <span class="Structure">where</span>
 pure x <span class="Operator">=</span> <span class="haskellType">Parser</span> <span class="Operator">$</span> <span class="Operator">\</span>str <span class="Operator">-&gt;</span> <span class="haskellType">Right</span> (x, str)
 (<span class="haskellType">Parser</span> p) <span class="Operator">&lt;*&gt;</span> (<span class="haskellType">Parser</span> p') <span class="Operator">=</span> <span class="haskellType">Parser</span> go <span class="Structure">where</span>
 go st <span class="Operator">=</span> <span class="Keyword">case</span> p st <span class="Keyword">of</span>
 <span class="haskellType">Left</span> e <span class="Operator">-&gt;</span> <span class="haskellType">Left</span> e
 <span class="haskellType">Right</span> (fn, st') <span class="Operator">-&gt;</span> <span class="Keyword">case</span> p' st' <span class="Keyword">of</span>
 <span class="haskellType">Left</span> e' <span class="Operator">-&gt;</span> <span class="haskellType">Left</span> e'
 <span class="haskellType">Right</span> (v, st'') <span class="Operator">-&gt;</span> <span class="haskellType">Right</span> (fn v, st'')

 <span class="Structure">instance</span> <span class="haskellType">Alternative</span> <span class="haskellType">Parser</span> <span class="Structure">where</span>
 empty <span class="Operator">=</span> fail <span class="String">&quot;nothing&quot;</span>
 (<span class="haskellType">Parser</span> p) <span class="Operator">&lt;|&gt;</span> (<span class="haskellType">Parser</span> p') <span class="Operator">=</span> <span class="haskellType">Parser</span> go <span class="Structure">where</span>
 go st <span class="Operator">=</span> <span class="Keyword">case</span> p st <span class="Keyword">of</span>
 <span class="haskellType">Left</span> <span class="Operator">_</span> <span class="Operator">-&gt;</span> p' st
 <span class="haskellType">Right</span> x <span class="Operator">-&gt;</span> <span class="haskellType">Right</span> x

 <span class="Structure">instance</span> <span class="haskellType">Monad</span> <span class="haskellType">Parser</span> <span class="Structure">where</span>
 return <span class="Operator">=</span> pure
 (<span class="haskellType">Parser</span> p) <span class="Operator">&gt;&gt;=</span> f <span class="Operator">=</span> <span class="haskellType">Parser</span> go <span class="Structure">where</span>
 go s <span class="Operator">=</span> <span class="Keyword">case</span> p s <span class="Keyword">of</span>
 <span class="haskellType">Left</span> e <span class="Operator">-&gt;</span> <span class="haskellType">Left</span> e
 <span class="haskellType">Right</span> (x, s') <span class="Operator">-&gt;</span> parse (f x) s'
 fail m <span class="Operator">=</span> <span class="haskellType">Parser</span> go <span class="Structure">where</span>
 go <span class="Operator">=</span> <span class="haskellType">Left</span> <span class="Operator">.</span> go'
 go' [] <span class="Operator">=</span> <span class="String">&quot;expected &quot;</span> <span class="Operator">++</span> m <span class="Operator">++</span> <span class="String">&quot;, got to the end of stream&quot;</span>
 go' (x<span class="Operator">:</span>xs) <span class="Operator">=</span> <span class="String">&quot;expected &quot;</span> <span class="Operator">++</span> m <span class="Operator">++</span> <span class="String">&quot;, got '&quot;</span> <span class="Operator">++</span> x<span class="Operator">:</span><span class="String">&quot;'&quot;</span>


 <span class="Identifier">any</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> <span class="haskellType">Char</span>
 any <span class="Operator">=</span> <span class="haskellType">Parser</span> go <span class="Structure">where</span>
 go [] <span class="Operator">=</span> <span class="haskellType">Left</span> <span class="String">&quot;any: end of file&quot;</span>
 go (x<span class="Operator">:</span>xs) <span class="Operator">=</span> <span class="haskellType">Right</span> (x,xs)

 <span class="Identifier">satisfy</span> <span class="Operator">::</span> (<span class="haskellType">Char</span> <span class="Operator">-&gt;</span> <span class="haskellType">Bool</span>) <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> <span class="haskellType">Char</span>
 satisfy f <span class="Operator">=</span> <span class="Keyword">do</span> x <span class="Operator">&lt;-</span> <span class="haskellType">Parser</span><span class="Operator">.</span>any
 <span class="Conditional">if</span> f x
 <span class="Conditional">then</span> return x
 <span class="Conditional">else</span> fail <span class="String">&quot;a solution to the function&quot;</span>


 <span class="Identifier">char</span> <span class="Operator">::</span> <span class="haskellType">Char</span> <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> <span class="haskellType">Char</span>
 char c <span class="Operator">=</span> satisfy (c <span class="Operator">==</span>) <span class="Operator">&lt;?&gt;</span> <span class="String">&quot;literal &quot;</span> <span class="Operator">++</span> [c]

 <span class="Identifier">oneOf</span> <span class="Operator">::</span> <span class="haskellType">String</span> <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> <span class="haskellType">Char</span>
 oneOf s <span class="Operator">=</span> satisfy (<span class="Operator">`elem`</span> s) <span class="Operator">&lt;?&gt;</span> <span class="String">&quot;one of '&quot;</span> <span class="Operator">++</span> s <span class="Operator">++</span> <span class="String">&quot;'&quot;</span>

 <span class="Identifier">string</span> <span class="Operator">::</span> <span class="haskellType">String</span> <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> <span class="haskellType">String</span>
 string [] <span class="Operator">=</span> return []
 string (x<span class="Operator">:</span>xs) <span class="Operator">=</span> <span class="Keyword">do</span> char x
 string xs
 return <span class="Operator">$</span> x<span class="Operator">:</span>xs

 <span class="Identifier">natural</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> <span class="haskellType">Integer</span>
 natural <span class="Operator">=</span> read <span class="Operator">&lt;$&gt;</span> some (satisfy isDigit)

 <span class="Identifier">lexeme</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a
 lexeme <span class="Operator">=</span> (<span class="Operator">&lt;*</span> spaces)

 <span class="Identifier">reserved</span> <span class="Operator">::</span> <span class="haskellType">String</span> <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> <span class="haskellType">String</span>
 reserved <span class="Operator">=</span> lexeme <span class="Operator">.</span> string

 <span class="Identifier">spaces</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> <span class="haskellType">String</span>
 spaces <span class="Operator">=</span> many <span class="Operator">$</span> oneOf <span class="String">&quot; \n\r&quot;</span>

 <span class="Identifier">digit</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> <span class="haskellType">Char</span>
 digit <span class="Operator">=</span> satisfy isDigit

 <span class="Identifier">number</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> <span class="haskellType">Int</span>
 number <span class="Operator">=</span> <span class="Keyword">do</span>
 s <span class="Operator">&lt;-</span> string <span class="String">&quot;-&quot;</span> <span class="Operator">&lt;|&gt;</span> empty
 cs <span class="Operator">&lt;-</span> some digit
 return <span class="Operator">$</span> read (s <span class="Operator">++</span> cs)

 <span class="Identifier">between</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> b <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> c <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a
 between o c x <span class="Operator">=</span> o <span class="Operator">*&gt;</span> x <span class="Operator">&lt;*</span> c

 <span class="Identifier">contents</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a
 contents x <span class="Operator">=</span> spaces <span class="Operator">*&gt;</span> x <span class="Operator">&lt;*</span> spaces

 <span class="Identifier">sep</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> b <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> [a]
 sep s c <span class="Operator">=</span> sep1 s c <span class="Operator">&lt;|&gt;</span> return []

 <span class="Identifier">sep1</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> b <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> [a]
 sep1 s c <span class="Operator">=</span> <span class="Keyword">do</span> x <span class="Operator">&lt;-</span> c
 xs <span class="Operator">&lt;-</span> many <span class="Operator">$</span> s <span class="Operator">&gt;&gt;</span> c
 return <span class="Operator">$</span> x<span class="Operator">:</span>xs

 <span class="Identifier">option</span> <span class="Operator">::</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> a
 option x p <span class="Operator">=</span> p <span class="Operator">&lt;|&gt;</span> return x

 <span class="Identifier">optionMaybe</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> (<span class="haskellType">Maybe</span> a)
 optionMaybe p <span class="Operator">=</span> option <span class="haskellType">Nothing</span> <span class="Operator">$</span> <span class="haskellType">Just</span> <span class="Operator">&lt;$&gt;</span> p

 <span class="Identifier">optional</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> a <span class="Operator">-&gt;</span> <span class="haskellType">Parser</span> ()
 optional p <span class="Operator">=</span> void p <span class="Operator">&lt;|&gt;</span> return ()

 <span class="Identifier">eof</span> <span class="Operator">::</span> <span class="haskellType">Parser</span> ()
 eof <span class="Operator">=</span> <span class="haskellType">Parser</span> go <span class="Structure">where</span>
 go (x<span class="Operator">:_</span>) <span class="Operator">=</span> <span class="haskellType">Left</span> <span class="Operator">$</span> <span class="String">&quot;expected eof, got '&quot;</span> <span class="Operator">++</span> x<span class="Operator">:</span><span class="String">&quot;'&quot;</span>
 go [] <span class="Operator">=</span> <span class="haskellType">Right</span> ((), [])
 </pre>
 </body>
 </html>
 <!-- vim: set foldmethod=manual : -->
--- a/static/default.css
+++ b/static/default.css
@ -0,0 +1,10 @@
 body{color:black;font-size:16px;margin:0px auto 0px
 auto;width:80%;font-family:Fira Sans, sans-serif}div#header{border-bottom:2px
 solid black;margin-bottom:30px;padding:12px 0px 12px 0px}div#logo
 a{color:black;float:left;font-size:18px;font-weight:bold;font-family:Iosevka,
 Iosevka Term, Fira Mono, Inconsolata, monospace;text-decoration:none}div >
 span.kw{color:#007020}div > span.type{color:#902000}div#header
 #navigation{text-align:right}div#header #navigation
 a{color:black;font-size:18px;font-weight:bold;margin-left:12px;text-decoration:none;text-transform:uppercase}div#footer{border-top:solid
 2px black;color:#555;font-size:12px;margin-top:30px;padding:12px 0px 12px
 0px;text-align:right}div#content{text-align:justify;text-justify:inter-word}h1{font-size:24px}h2{font-size:20px}div.info{color:#555;font-size:14px;font-style:italic}
--- a/static/demorgan-1.ml.html
+++ b/static/demorgan-1.ml.html
@ -0,0 +1,100 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 <title>~/Projects/blag/demorgan-1.ml.html</title>
 <meta name="Generator" content="Vim/8.0">
 <meta name="plugin-version" content="vim8.1_v1">
 <meta name="syntax" content="amulet">
 <meta name="settings" content="use_css,pre_wrap,no_foldcolumn,expand_tabs,prevent_copy=t">
 <meta name="colorscheme" content="onedark">
 <style type="text/css">
 <!--
 pre { white-space: pre-wrap; font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 body { font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 * { font-size: 1em; }
 input { border: none; margin: 0; padding: 0; font-family: 'Iosevka','Iosevka Term', monospace; }
 input[size='1'] { width: 1em; width: 1ch; }
 input[size='2'] { width: 2em; width: 2ch; }
 input[size='3'] { width: 3em; width: 3ch; }
 input[size='4'] { width: 4em; width: 4ch; }
 input[size='5'] { width: 5em; width: 5ch; }
 input[size='6'] { width: 6em; width: 6ch; }
 input[size='7'] { width: 7em; width: 7ch; }
 input[size='8'] { width: 8em; width: 8ch; }
 input[size='9'] { width: 9em; width: 9ch; }
 input[size='10'] { width: 10em; width: 10ch; }
 input[size='11'] { width: 11em; width: 11ch; }
 input[size='12'] { width: 12em; width: 12ch; }
 input[size='13'] { width: 13em; width: 13ch; }
 input[size='14'] { width: 14em; width: 14ch; }
 input[size='15'] { width: 15em; width: 15ch; }
 input[size='16'] { width: 16em; width: 16ch; }
 input[size='17'] { width: 17em; width: 17ch; }
 input[size='18'] { width: 18em; width: 18ch; }
 input[size='19'] { width: 19em; width: 19ch; }
 input[size='20'] { width: 20em; width: 20ch; }
 #oneCharWidth, #oneEmWidth, #oneInputWidth { padding: 0; margin: 0; position: absolute; left: -999999px; visibility: hidden; }
 .em5 input[size='1'] { width: 0.05em; } .em5 input[size='2'] { width: 0.1em; } .em5 input[size='3'] { width: 0.15em; } .em5 input[size='4'] { width: 0.2em; } .em5 input[size='5'] { width: 0.25em; } .em5 input[size='6'] { width: 0.3em; } .em5 input[size='7'] { width: 0.35em; } .em5 input[size='8'] { width: 0.4em; } .em5 input[size='9'] { width: 0.45em; } .em5 input[size='10'] { width: 0.5em; } .em5 input[size='11'] { width: 0.55em; } .em5 input[size='12'] { width: 0.6em; } .em5 input[size='13'] { width: 0.65em; } .em5 input[size='14'] { width: 0.7em; } .em5 input[size='15'] { width: 0.75em; } .em5 input[size='16'] { width: 0.8em; } .em5 input[size='17'] { width: 0.85em; } .em5 input[size='18'] { width: 0.9em; } .em5 input[size='19'] { width: 0.95em; } .em5 input[size='20'] { width: 1.0em; }
 .em10 input[size='1'] { width: 0.1em; } .em10 input[size='2'] { width: 0.2em; } .em10 input[size='3'] { width: 0.3em; } .em10 input[size='4'] { width: 0.4em; } .em10 input[size='5'] { width: 0.5em; } .em10 input[size='6'] { width: 0.6em; } .em10 input[size='7'] { width: 0.7em; } .em10 input[size='8'] { width: 0.8em; } .em10 input[size='9'] { width: 0.9em; } .em10 input[size='10'] { width: 1.0em; } .em10 input[size='11'] { width: 1.1em; } .em10 input[size='12'] { width: 1.2em; } .em10 input[size='13'] { width: 1.3em; } .em10 input[size='14'] { width: 1.4em; } .em10 input[size='15'] { width: 1.5em; } .em10 input[size='16'] { width: 1.6em; } .em10 input[size='17'] { width: 1.7em; } .em10 input[size='18'] { width: 1.8em; } .em10 input[size='19'] { width: 1.9em; } .em10 input[size='20'] { width: 2.0em; }
 .em15 input[size='1'] { width: 0.15em; } .em15 input[size='2'] { width: 0.3em; } .em15 input[size='3'] { width: 0.45em; } .em15 input[size='4'] { width: 0.6em; } .em15 input[size='5'] { width: 0.75em; } .em15 input[size='6'] { width: 0.9em; } .em15 input[size='7'] { width: 1.05em; } .em15 input[size='8'] { width: 1.2em; } .em15 input[size='9'] { width: 1.35em; } .em15 input[size='10'] { width: 1.5em; } .em15 input[size='11'] { width: 1.65em; } .em15 input[size='12'] { width: 1.8em; } .em15 input[size='13'] { width: 1.95em; } .em15 input[size='14'] { width: 2.1em; } .em15 input[size='15'] { width: 2.25em; } .em15 input[size='16'] { width: 2.4em; } .em15 input[size='17'] { width: 2.55em; } .em15 input[size='18'] { width: 2.7em; } .em15 input[size='19'] { width: 2.85em; } .em15 input[size='20'] { width: 3.0em; }
 .em20 input[size='1'] { width: 0.2em; } .em20 input[size='2'] { width: 0.4em; } .em20 input[size='3'] { width: 0.6em; } .em20 input[size='4'] { width: 0.8em; } .em20 input[size='5'] { width: 1.0em; } .em20 input[size='6'] { width: 1.2em; } .em20 input[size='7'] { width: 1.4em; } .em20 input[size='8'] { width: 1.6em; } .em20 input[size='9'] { width: 1.8em; } .em20 input[size='10'] { width: 2.0em; } .em20 input[size='11'] { width: 2.2em; } .em20 input[size='12'] { width: 2.4em; } .em20 input[size='13'] { width: 2.6em; } .em20 input[size='14'] { width: 2.8em; } .em20 input[size='15'] { width: 3.0em; } .em20 input[size='16'] { width: 3.2em; } .em20 input[size='17'] { width: 3.4em; } .em20 input[size='18'] { width: 3.6em; } .em20 input[size='19'] { width: 3.8em; } .em20 input[size='20'] { width: 4.0em; }
 .em25 input[size='1'] { width: 0.25em; } .em25 input[size='2'] { width: 0.5em; } .em25 input[size='3'] { width: 0.75em; } .em25 input[size='4'] { width: 1.0em; } .em25 input[size='5'] { width: 1.25em; } .em25 input[size='6'] { width: 1.5em; } .em25 input[size='7'] { width: 1.75em; } .em25 input[size='8'] { width: 2.0em; } .em25 input[size='9'] { width: 2.25em; } .em25 input[size='10'] { width: 2.5em; } .em25 input[size='11'] { width: 2.75em; } .em25 input[size='12'] { width: 3.0em; } .em25 input[size='13'] { width: 3.25em; } .em25 input[size='14'] { width: 3.5em; } .em25 input[size='15'] { width: 3.75em; } .em25 input[size='16'] { width: 4.0em; } .em25 input[size='17'] { width: 4.25em; } .em25 input[size='18'] { width: 4.5em; } .em25 input[size='19'] { width: 4.75em; } .em25 input[size='20'] { width: 5.0em; }
 .em30 input[size='1'] { width: 0.3em; } .em30 input[size='2'] { width: 0.6em; } .em30 input[size='3'] { width: 0.9em; } .em30 input[size='4'] { width: 1.2em; } .em30 input[size='5'] { width: 1.5em; } .em30 input[size='6'] { width: 1.8em; } .em30 input[size='7'] { width: 2.1em; } .em30 input[size='8'] { width: 2.4em; } .em30 input[size='9'] { width: 2.7em; } .em30 input[size='10'] { width: 3.0em; } .em30 input[size='11'] { width: 3.3em; } .em30 input[size='12'] { width: 3.6em; } .em30 input[size='13'] { width: 3.9em; } .em30 input[size='14'] { width: 4.2em; } .em30 input[size='15'] { width: 4.5em; } .em30 input[size='16'] { width: 4.8em; } .em30 input[size='17'] { width: 5.1em; } .em30 input[size='18'] { width: 5.4em; } .em30 input[size='19'] { width: 5.7em; } .em30 input[size='20'] { width: 6.0em; }
 .em35 input[size='1'] { width: 0.35em; } .em35 input[size='2'] { width: 0.7em; } .em35 input[size='3'] { width: 1.05em; } .em35 input[size='4'] { width: 1.4em; } .em35 input[size='5'] { width: 1.75em; } .em35 input[size='6'] { width: 2.1em; } .em35 input[size='7'] { width: 2.45em; } .em35 input[size='8'] { width: 2.8em; } .em35 input[size='9'] { width: 3.15em; } .em35 input[size='10'] { width: 3.5em; } .em35 input[size='11'] { width: 3.85em; } .em35 input[size='12'] { width: 4.2em; } .em35 input[size='13'] { width: 4.55em; } .em35 input[size='14'] { width: 4.9em; } .em35 input[size='15'] { width: 5.25em; } .em35 input[size='16'] { width: 5.6em; } .em35 input[size='17'] { width: 5.95em; } .em35 input[size='18'] { width: 6.3em; } .em35 input[size='19'] { width: 6.65em; } .em35 input[size='20'] { width: 7.0em; }
 .em40 input[size='1'] { width: 0.4em; } .em40 input[size='2'] { width: 0.8em; } .em40 input[size='3'] { width: 1.2em; } .em40 input[size='4'] { width: 1.6em; } .em40 input[size='5'] { width: 2.0em; } .em40 input[size='6'] { width: 2.4em; } .em40 input[size='7'] { width: 2.8em; } .em40 input[size='8'] { width: 3.2em; } .em40 input[size='9'] { width: 3.6em; } .em40 input[size='10'] { width: 4.0em; } .em40 input[size='11'] { width: 4.4em; } .em40 input[size='12'] { width: 4.8em; } .em40 input[size='13'] { width: 5.2em; } .em40 input[size='14'] { width: 5.6em; } .em40 input[size='15'] { width: 6.0em; } .em40 input[size='16'] { width: 6.4em; } .em40 input[size='17'] { width: 6.8em; } .em40 input[size='18'] { width: 7.2em; } .em40 input[size='19'] { width: 7.6em; } .em40 input[size='20'] { width: 8.0em; }
 .em45 input[size='1'] { width: 0.45em; } .em45 input[size='2'] { width: 0.9em; } .em45 input[size='3'] { width: 1.35em; } .em45 input[size='4'] { width: 1.8em; } .em45 input[size='5'] { width: 2.25em; } .em45 input[size='6'] { width: 2.7em; } .em45 input[size='7'] { width: 3.15em; } .em45 input[size='8'] { width: 3.6em; } .em45 input[size='9'] { width: 4.05em; } .em45 input[size='10'] { width: 4.5em; } .em45 input[size='11'] { width: 4.95em; } .em45 input[size='12'] { width: 5.4em; } .em45 input[size='13'] { width: 5.85em; } .em45 input[size='14'] { width: 6.3em; } .em45 input[size='15'] { width: 6.75em; } .em45 input[size='16'] { width: 7.2em; } .em45 input[size='17'] { width: 7.65em; } .em45 input[size='18'] { width: 8.1em; } .em45 input[size='19'] { width: 8.55em; } .em45 input[size='20'] { width: 9.0em; }
 .em50 input[size='1'] { width: 0.5em; } .em50 input[size='2'] { width: 1.0em; } .em50 input[size='3'] { width: 1.5em; } .em50 input[size='4'] { width: 2.0em; } .em50 input[size='5'] { width: 2.5em; } .em50 input[size='6'] { width: 3.0em; } .em50 input[size='7'] { width: 3.5em; } .em50 input[size='8'] { width: 4.0em; } .em50 input[size='9'] { width: 4.5em; } .em50 input[size='10'] { width: 5.0em; } .em50 input[size='11'] { width: 5.5em; } .em50 input[size='12'] { width: 6.0em; } .em50 input[size='13'] { width: 6.5em; } .em50 input[size='14'] { width: 7.0em; } .em50 input[size='15'] { width: 7.5em; } .em50 input[size='16'] { width: 8.0em; } .em50 input[size='17'] { width: 8.5em; } .em50 input[size='18'] { width: 9.0em; } .em50 input[size='19'] { width: 9.5em; } .em50 input[size='20'] { width: 10.0em; }
 .em55 input[size='1'] { width: 0.55em; } .em55 input[size='2'] { width: 1.1em; } .em55 input[size='3'] { width: 1.65em; } .em55 input[size='4'] { width: 2.2em; } .em55 input[size='5'] { width: 2.75em; } .em55 input[size='6'] { width: 3.3em; } .em55 input[size='7'] { width: 3.85em; } .em55 input[size='8'] { width: 4.4em; } .em55 input[size='9'] { width: 4.95em; } .em55 input[size='10'] { width: 5.5em; } .em55 input[size='11'] { width: 6.05em; } .em55 input[size='12'] { width: 6.6em; } .em55 input[size='13'] { width: 7.15em; } .em55 input[size='14'] { width: 7.7em; } .em55 input[size='15'] { width: 8.25em; } .em55 input[size='16'] { width: 8.8em; } .em55 input[size='17'] { width: 9.35em; } .em55 input[size='18'] { width: 9.9em; } .em55 input[size='19'] { width: 10.45em; } .em55 input[size='20'] { width: 11.0em; }
 .em60 input[size='1'] { width: 0.6em; } .em60 input[size='2'] { width: 1.2em; } .em60 input[size='3'] { width: 1.8em; } .em60 input[size='4'] { width: 2.4em; } .em60 input[size='5'] { width: 3.0em; } .em60 input[size='6'] { width: 3.6em; } .em60 input[size='7'] { width: 4.2em; } .em60 input[size='8'] { width: 4.8em; } .em60 input[size='9'] { width: 5.4em; } .em60 input[size='10'] { width: 6.0em; } .em60 input[size='11'] { width: 6.6em; } .em60 input[size='12'] { width: 7.2em; } .em60 input[size='13'] { width: 7.8em; } .em60 input[size='14'] { width: 8.4em; } .em60 input[size='15'] { width: 9.0em; } .em60 input[size='16'] { width: 9.6em; } .em60 input[size='17'] { width: 10.2em; } .em60 input[size='18'] { width: 10.8em; } .em60 input[size='19'] { width: 11.4em; } .em60 input[size='20'] { width: 12.0em; }
 .em65 input[size='1'] { width: 0.65em; } .em65 input[size='2'] { width: 1.3em; } .em65 input[size='3'] { width: 1.95em; } .em65 input[size='4'] { width: 2.6em; } .em65 input[size='5'] { width: 3.25em; } .em65 input[size='6'] { width: 3.9em; } .em65 input[size='7'] { width: 4.55em; } .em65 input[size='8'] { width: 5.2em; } .em65 input[size='9'] { width: 5.85em; } .em65 input[size='10'] { width: 6.5em; } .em65 input[size='11'] { width: 7.15em; } .em65 input[size='12'] { width: 7.8em; } .em65 input[size='13'] { width: 8.45em; } .em65 input[size='14'] { width: 9.1em; } .em65 input[size='15'] { width: 9.75em; } .em65 input[size='16'] { width: 10.4em; } .em65 input[size='17'] { width: 11.05em; } .em65 input[size='18'] { width: 11.7em; } .em65 input[size='19'] { width: 12.35em; } .em65 input[size='20'] { width: 13.0em; }
 .em70 input[size='1'] { width: 0.7em; } .em70 input[size='2'] { width: 1.4em; } .em70 input[size='3'] { width: 2.1em; } .em70 input[size='4'] { width: 2.8em; } .em70 input[size='5'] { width: 3.5em; } .em70 input[size='6'] { width: 4.2em; } .em70 input[size='7'] { width: 4.9em; } .em70 input[size='8'] { width: 5.6em; } .em70 input[size='9'] { width: 6.3em; } .em70 input[size='10'] { width: 7.0em; } .em70 input[size='11'] { width: 7.7em; } .em70 input[size='12'] { width: 8.4em; } .em70 input[size='13'] { width: 9.1em; } .em70 input[size='14'] { width: 9.8em; } .em70 input[size='15'] { width: 10.5em; } .em70 input[size='16'] { width: 11.2em; } .em70 input[size='17'] { width: 11.9em; } .em70 input[size='18'] { width: 12.6em; } .em70 input[size='19'] { width: 13.3em; } .em70 input[size='20'] { width: 14.0em; }
 .em75 input[size='1'] { width: 0.75em; } .em75 input[size='2'] { width: 1.5em; } .em75 input[size='3'] { width: 2.25em; } .em75 input[size='4'] { width: 3.0em; } .em75 input[size='5'] { width: 3.75em; } .em75 input[size='6'] { width: 4.5em; } .em75 input[size='7'] { width: 5.25em; } .em75 input[size='8'] { width: 6.0em; } .em75 input[size='9'] { width: 6.75em; } .em75 input[size='10'] { width: 7.5em; } .em75 input[size='11'] { width: 8.25em; } .em75 input[size='12'] { width: 9.0em; } .em75 input[size='13'] { width: 9.75em; } .em75 input[size='14'] { width: 10.5em; } .em75 input[size='15'] { width: 11.25em; } .em75 input[size='16'] { width: 12.0em; } .em75 input[size='17'] { width: 12.75em; } .em75 input[size='18'] { width: 13.5em; } .em75 input[size='19'] { width: 14.25em; } .em75 input[size='20'] { width: 15.0em; }
 .em80 input[size='1'] { width: 0.8em; } .em80 input[size='2'] { width: 1.6em; } .em80 input[size='3'] { width: 2.4em; } .em80 input[size='4'] { width: 3.2em; } .em80 input[size='5'] { width: 4.0em; } .em80 input[size='6'] { width: 4.8em; } .em80 input[size='7'] { width: 5.6em; } .em80 input[size='8'] { width: 6.4em; } .em80 input[size='9'] { width: 7.2em; } .em80 input[size='10'] { width: 8.0em; } .em80 input[size='11'] { width: 8.8em; } .em80 input[size='12'] { width: 9.6em; } .em80 input[size='13'] { width: 10.4em; } .em80 input[size='14'] { width: 11.2em; } .em80 input[size='15'] { width: 12.0em; } .em80 input[size='16'] { width: 12.8em; } .em80 input[size='17'] { width: 13.6em; } .em80 input[size='18'] { width: 14.4em; } .em80 input[size='19'] { width: 15.2em; } .em80 input[size='20'] { width: 16.0em; }
 .em85 input[size='1'] { width: 0.85em; } .em85 input[size='2'] { width: 1.7em; } .em85 input[size='3'] { width: 2.55em; } .em85 input[size='4'] { width: 3.4em; } .em85 input[size='5'] { width: 4.25em; } .em85 input[size='6'] { width: 5.1em; } .em85 input[size='7'] { width: 5.95em; } .em85 input[size='8'] { width: 6.8em; } .em85 input[size='9'] { width: 7.65em; } .em85 input[size='10'] { width: 8.5em; } .em85 input[size='11'] { width: 9.35em; } .em85 input[size='12'] { width: 10.2em; } .em85 input[size='13'] { width: 11.05em; } .em85 input[size='14'] { width: 11.9em; } .em85 input[size='15'] { width: 12.75em; } .em85 input[size='16'] { width: 13.6em; } .em85 input[size='17'] { width: 14.45em; } .em85 input[size='18'] { width: 15.3em; } .em85 input[size='19'] { width: 16.15em; } .em85 input[size='20'] { width: 17.0em; }
 .em90 input[size='1'] { width: 0.9em; } .em90 input[size='2'] { width: 1.8em; } .em90 input[size='3'] { width: 2.7em; } .em90 input[size='4'] { width: 3.6em; } .em90 input[size='5'] { width: 4.5em; } .em90 input[size='6'] { width: 5.4em; } .em90 input[size='7'] { width: 6.3em; } .em90 input[size='8'] { width: 7.2em; } .em90 input[size='9'] { width: 8.1em; } .em90 input[size='10'] { width: 9.0em; } .em90 input[size='11'] { width: 9.9em; } .em90 input[size='12'] { width: 10.8em; } .em90 input[size='13'] { width: 11.7em; } .em90 input[size='14'] { width: 12.6em; } .em90 input[size='15'] { width: 13.5em; } .em90 input[size='16'] { width: 14.4em; } .em90 input[size='17'] { width: 15.3em; } .em90 input[size='18'] { width: 16.2em; } .em90 input[size='19'] { width: 17.1em; } .em90 input[size='20'] { width: 18.0em; }
 .em95 input[size='1'] { width: 0.95em; } .em95 input[size='2'] { width: 1.9em; } .em95 input[size='3'] { width: 2.85em; } .em95 input[size='4'] { width: 3.8em; } .em95 input[size='5'] { width: 4.75em; } .em95 input[size='6'] { width: 5.7em; } .em95 input[size='7'] { width: 6.65em; } .em95 input[size='8'] { width: 7.6em; } .em95 input[size='9'] { width: 8.55em; } .em95 input[size='10'] { width: 9.5em; } .em95 input[size='11'] { width: 10.45em; } .em95 input[size='12'] { width: 11.4em; } .em95 input[size='13'] { width: 12.35em; } .em95 input[size='14'] { width: 13.3em; } .em95 input[size='15'] { width: 14.25em; } .em95 input[size='16'] { width: 15.2em; } .em95 input[size='17'] { width: 16.15em; } .em95 input[size='18'] { width: 17.1em; } .em95 input[size='19'] { width: 18.05em; } .em95 input[size='20'] { width: 19.0em; }
 .em100 input[size='1'] { width: 1.0em; } .em100 input[size='2'] { width: 2.0em; } .em100 input[size='3'] { width: 3.0em; } .em100 input[size='4'] { width: 4.0em; } .em100 input[size='5'] { width: 5.0em; } .em100 input[size='6'] { width: 6.0em; } .em100 input[size='7'] { width: 7.0em; } .em100 input[size='8'] { width: 8.0em; } .em100 input[size='9'] { width: 9.0em; } .em100 input[size='10'] { width: 10.0em; } .em100 input[size='11'] { width: 11.0em; } .em100 input[size='12'] { width: 12.0em; } .em100 input[size='13'] { width: 13.0em; } .em100 input[size='14'] { width: 14.0em; } .em100 input[size='15'] { width: 15.0em; } .em100 input[size='16'] { width: 16.0em; } .em100 input[size='17'] { width: 17.0em; } .em100 input[size='18'] { width: 18.0em; } .em100 input[size='19'] { width: 19.0em; } .em100 input[size='20'] { width: 20.0em; }
 input.Folded { cursor: default; }
 .Operator { color: #C678DD; }
 .Constant { color: #56B6C2; }
 .Keyword { color: #E06C75; }
 -->
 </style>

 <script type='text/javascript'>
 <!--

 /* simulate a "ch" unit by asking the browser how big a zero character is */
 function FixCharWidth() {
 /* get the hidden element which gives the width of a single character */
 var goodWidth = document.getElementById("oneCharWidth").clientWidth;
 /* get all input elements, we'll filter on class later */
 var inputTags = document.getElementsByTagName("input");
 var ratio = 5;
 var inputWidth = document.getElementById("oneInputWidth").clientWidth;
 var emWidth = document.getElementById("oneEmWidth").clientWidth;
 if (inputWidth > goodWidth) {
 while (ratio < 100*goodWidth/emWidth && ratio < 100) {
 ratio += 5;
 }
 document.getElementById("vimCodeElement").className = "em"+ratio;
 }
 }

 -->
 </script>
 </head>
 <body onload='FixCharWidth();'>
 <!-- hidden divs used by javascript to get the width of a char -->
 <div id='oneCharWidth'>0</div>
 <div id='oneInputWidth'><input size='1' value='0'></div>
 <div id='oneEmWidth' style='width: 1em;'></div>
 <pre id='vimCodeElement'>
 <span class="Constant">Equiv</span> <span class="Keyword">(fun</span> <span class="Keyword">(</span><span class="Constant">Not</span> g<span class="Keyword">)</span> <span class="Keyword">-&gt;</span> <span class="Keyword">(</span><span class="Constant">Not</span> <span class="Keyword">(fun</span> b <span class="Keyword">-&gt;</span> g <span class="Keyword">(</span><span class="Constant">L</span> b<span class="Keyword">))</span><span class="Operator">,</span> <span class="Constant">Not</span> <span class="Keyword">(fun</span> c <span class="Keyword">-&gt;</span> g <span class="Keyword">(</span><span class="Constant">R</span> c<span class="Keyword">)))</span><span class="Operator">,</span> <span class="Keyword">fun</span> <span class="Keyword">((</span><span class="Constant">Not</span> h<span class="Keyword">)</span><span class="Operator">,</span> <span class="Keyword">(</span><span class="Constant">Not</span> g<span class="Keyword">))</span> <span class="Keyword">-&gt;</span> <span class="Constant">Not</span> <span class="Keyword">function</span>
 <span class="Operator">|</span> <span class="Keyword">(</span><span class="Constant">L</span> y<span class="Keyword">)</span> <span class="Keyword">-&gt;</span> h y
 <span class="Operator">|</span> <span class="Keyword">(</span><span class="Constant">R</span> a<span class="Keyword">)</span> <span class="Keyword">-&gt;</span> h <span class="Keyword">(</span>g a<span class="Keyword">))</span>
 </pre>
 </body>
 </html>
 <!-- vim: set foldmethod=manual : -->
--- a/static/doom.svg
+++ b/static/doom.svg
--- a/static/forth_machine.js
+++ b/static/forth_machine.js
@ -0,0 +1,119 @@
 let draw = SVG().addTo('#forth').size('100%', '100%')

 let stack_element = (container, text) => {
 let group = container.group()
 group.add(
 container.rect()
 .size(100, 25)
 .stroke('#000').fill('#ddd')
 .attr('stroke-width', 2));
 group.add(container.text(text).dmove((65 - text.length) / 2, -2));
 console.log(group);
 return group;
 }

 let the_code = [
 [ 'push', 2 ],
 [ 'push', 3 ],
 [ 'push', 4 ],
 [ 'mul' ],
 [ 'add' ]
 ]

 let the_stack = [], pc = 0, final = false;
 let stack_container = draw.nested().move(draw.width() - '10%', 0)
 let code_node = document.getElementById('code');

 let push_val = (int) => {
 let the_element =
 stack_element(stack_container, int.toString()).move(10, 0);
 the_element.animate(100, 0, 'now').move(10, 10);
 the_stack.forEach(elem => elem.svg.animate(100, 0, 'now').dy(25));
 the_stack.push({ svg: the_element, val: int });
 }

 let pop_val = () => {
 let item = the_stack.pop()
 item.svg.remove();
 the_stack.forEach(elem => elem.svg.dy(-25));
 return item.val;
 }

 let render_code = (code, pc) => {
 while (code_node.firstChild) {
 code_node.removeChild(code_node.firstChild);
 }
 let list = document.createElement('ul');
 list.style = 'list-style-type: none;';
 code.forEach((instruction, idx) => {
 let i_type = instruction[0];
 let li = document.createElement('li');

 if (idx == pc) {
 let cursor = document.createElement('span')
 cursor.innerText = '> ';
 cursor.classList.add('instruction-cursor');
 li.appendChild(cursor);
 }

 let type_field = document.createElement('span');
 type_field.innerText = i_type;
 type_field.classList.add('instruction');
 li.appendChild(type_field);
 for (let i = 1; i < instruction.length; i++) {
 li.append(' ');
 let operand_field = document.createElement('span');
 operand_field.innerText = instruction[i];
 operand_field.classList.add('operand');
 li.appendChild(operand_field);
 }
 list.appendChild(li);
 });
 code_node.appendChild(list);
 };

 let reset = () => {
 the_stack.forEach(e => e.svg.remove());
 the_stack = [];
 pc = 0;
 final = false;
 document.getElementById('step').disabled = false;
 render_code(the_code, 0);
 }

 let step = () => {
 if (!final) {
 const insn = the_code[pc++];
 switch (insn[0]) {
 case 'push':
 push_val(insn[1]);
 break;
 case 'add':
 if (the_stack.length < 2) {
 console.error("machine error");
 document.getElementById('step').disabled = true;
 } else {
 let x = pop_val(), y = pop_val();
 push_val(x + y);
 }
 break;
 case 'mul':
 if (the_stack.length < 2) {
 console.error("machine error");
 document.getElementById('step').disabled = true;
 } else {
 let x = pop_val(), y = pop_val();
 push_val(x * y);
 }
 break;
 }
 }
 render_code(the_code, pc);
 if (pc >= the_code.length) {
 console.log("final state");
 document.getElementById('step').disabled = true;
 final = true;
 }
 }

 render_code(the_code, pc);
--- a/static/generated_code.lua
+++ b/static/generated_code.lua
@ -0,0 +1,22 @@
 eq_3f_1 = setmetatable1(({["lookup"]=({})}), ({["__call"]=(function(temp_this, x, y)
 local temp_method
 local temp = temp_this["lookup"]
 if temp then
 local temp1 = temp[type1(x)]
 if temp1 then
 temp_method = temp1[type1(y)] or nil
 else
 temp_method = nil
 end
 else
 temp_method = nil
 end
 if not temp_method then
 if temp_this["default"] then
 temp_method = temp_this["default"]
 else
 error1("No matching method to call for " .. (type1(x) .. " ") .. (type1(y) .. " ") .. "\nthere are methods to call for " .. keys1(temp_this["lookup"]))
 end
 end
 return temp_method(x, y)
 end)}))
--- a/static/generated_code.lua.html
+++ b/static/generated_code.lua.html
@ -0,0 +1,124 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 <title>~/Projects/blag/static/generated_code.lua.html</title>
 <meta name="Generator" content="Vim/7.4">
 <meta name="plugin-version" content="vim7.4_v2">
 <meta name="syntax" content="lua">
 <meta name="settings" content="use_css,pre_wrap,no_foldcolumn,expand_tabs,prevent_copy=t">
 <meta name="colorscheme" content="onedark">
 <style type="text/css">
 <!--
 pre { white-space: pre-wrap; font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 body { font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 * { font-size: 1em; }
 input { border: none; margin: 0; padding: 0; font-family: 'Iosevka','Iosevka Term', monospace; }
 input[size='1'] { width: 1em; width: 1ch; }
 input[size='2'] { width: 2em; width: 2ch; }
 input[size='3'] { width: 3em; width: 3ch; }
 input[size='4'] { width: 4em; width: 4ch; }
 input[size='5'] { width: 5em; width: 5ch; }
 input[size='6'] { width: 6em; width: 6ch; }
 input[size='7'] { width: 7em; width: 7ch; }
 input[size='8'] { width: 8em; width: 8ch; }
 input[size='9'] { width: 9em; width: 9ch; }
 input[size='10'] { width: 10em; width: 10ch; }
 input[size='11'] { width: 11em; width: 11ch; }
 input[size='12'] { width: 12em; width: 12ch; }
 input[size='13'] { width: 13em; width: 13ch; }
 input[size='14'] { width: 14em; width: 14ch; }
 input[size='15'] { width: 15em; width: 15ch; }
 input[size='16'] { width: 16em; width: 16ch; }
 input[size='17'] { width: 17em; width: 17ch; }
 input[size='18'] { width: 18em; width: 18ch; }
 input[size='19'] { width: 19em; width: 19ch; }
 input[size='20'] { width: 20em; width: 20ch; }
 #oneCharWidth, #oneEmWidth, #oneInputWidth { padding: 0; margin: 0; position: absolute; left: -999999px; visibility: hidden; }
 .em5 input[size='1'] { width: 0.05em; } .em5 input[size='2'] { width: 0.1em; } .em5 input[size='3'] { width: 0.15em; } .em5 input[size='4'] { width: 0.2em; } .em5 input[size='5'] { width: 0.25em; } .em5 input[size='6'] { width: 0.3em; } .em5 input[size='7'] { width: 0.35em; } .em5 input[size='8'] { width: 0.4em; } .em5 input[size='9'] { width: 0.45em; } .em5 input[size='10'] { width: 0.5em; } .em5 input[size='11'] { width: 0.55em; } .em5 input[size='12'] { width: 0.6em; } .em5 input[size='13'] { width: 0.65em; } .em5 input[size='14'] { width: 0.7em; } .em5 input[size='15'] { width: 0.75em; } .em5 input[size='16'] { width: 0.8em; } .em5 input[size='17'] { width: 0.85em; } .em5 input[size='18'] { width: 0.9em; } .em5 input[size='19'] { width: 0.95em; } .em5 input[size='20'] { width: 1.0em; }
 .em10 input[size='1'] { width: 0.1em; } .em10 input[size='2'] { width: 0.2em; } .em10 input[size='3'] { width: 0.3em; } .em10 input[size='4'] { width: 0.4em; } .em10 input[size='5'] { width: 0.5em; } .em10 input[size='6'] { width: 0.6em; } .em10 input[size='7'] { width: 0.7em; } .em10 input[size='8'] { width: 0.8em; } .em10 input[size='9'] { width: 0.9em; } .em10 input[size='10'] { width: 1.0em; } .em10 input[size='11'] { width: 1.1em; } .em10 input[size='12'] { width: 1.2em; } .em10 input[size='13'] { width: 1.3em; } .em10 input[size='14'] { width: 1.4em; } .em10 input[size='15'] { width: 1.5em; } .em10 input[size='16'] { width: 1.6em; } .em10 input[size='17'] { width: 1.7em; } .em10 input[size='18'] { width: 1.8em; } .em10 input[size='19'] { width: 1.9em; } .em10 input[size='20'] { width: 2.0em; }
 .em15 input[size='1'] { width: 0.15em; } .em15 input[size='2'] { width: 0.3em; } .em15 input[size='3'] { width: 0.45em; } .em15 input[size='4'] { width: 0.6em; } .em15 input[size='5'] { width: 0.75em; } .em15 input[size='6'] { width: 0.9em; } .em15 input[size='7'] { width: 1.05em; } .em15 input[size='8'] { width: 1.2em; } .em15 input[size='9'] { width: 1.35em; } .em15 input[size='10'] { width: 1.5em; } .em15 input[size='11'] { width: 1.65em; } .em15 input[size='12'] { width: 1.8em; } .em15 input[size='13'] { width: 1.95em; } .em15 input[size='14'] { width: 2.1em; } .em15 input[size='15'] { width: 2.25em; } .em15 input[size='16'] { width: 2.4em; } .em15 input[size='17'] { width: 2.55em; } .em15 input[size='18'] { width: 2.7em; } .em15 input[size='19'] { width: 2.85em; } .em15 input[size='20'] { width: 3.0em; }
 .em20 input[size='1'] { width: 0.2em; } .em20 input[size='2'] { width: 0.4em; } .em20 input[size='3'] { width: 0.6em; } .em20 input[size='4'] { width: 0.8em; } .em20 input[size='5'] { width: 1.0em; } .em20 input[size='6'] { width: 1.2em; } .em20 input[size='7'] { width: 1.4em; } .em20 input[size='8'] { width: 1.6em; } .em20 input[size='9'] { width: 1.8em; } .em20 input[size='10'] { width: 2.0em; } .em20 input[size='11'] { width: 2.2em; } .em20 input[size='12'] { width: 2.4em; } .em20 input[size='13'] { width: 2.6em; } .em20 input[size='14'] { width: 2.8em; } .em20 input[size='15'] { width: 3.0em; } .em20 input[size='16'] { width: 3.2em; } .em20 input[size='17'] { width: 3.4em; } .em20 input[size='18'] { width: 3.6em; } .em20 input[size='19'] { width: 3.8em; } .em20 input[size='20'] { width: 4.0em; }
 .em25 input[size='1'] { width: 0.25em; } .em25 input[size='2'] { width: 0.5em; } .em25 input[size='3'] { width: 0.75em; } .em25 input[size='4'] { width: 1.0em; } .em25 input[size='5'] { width: 1.25em; } .em25 input[size='6'] { width: 1.5em; } .em25 input[size='7'] { width: 1.75em; } .em25 input[size='8'] { width: 2.0em; } .em25 input[size='9'] { width: 2.25em; } .em25 input[size='10'] { width: 2.5em; } .em25 input[size='11'] { width: 2.75em; } .em25 input[size='12'] { width: 3.0em; } .em25 input[size='13'] { width: 3.25em; } .em25 input[size='14'] { width: 3.5em; } .em25 input[size='15'] { width: 3.75em; } .em25 input[size='16'] { width: 4.0em; } .em25 input[size='17'] { width: 4.25em; } .em25 input[size='18'] { width: 4.5em; } .em25 input[size='19'] { width: 4.75em; } .em25 input[size='20'] { width: 5.0em; }
 .em30 input[size='1'] { width: 0.3em; } .em30 input[size='2'] { width: 0.6em; } .em30 input[size='3'] { width: 0.9em; } .em30 input[size='4'] { width: 1.2em; } .em30 input[size='5'] { width: 1.5em; } .em30 input[size='6'] { width: 1.8em; } .em30 input[size='7'] { width: 2.1em; } .em30 input[size='8'] { width: 2.4em; } .em30 input[size='9'] { width: 2.7em; } .em30 input[size='10'] { width: 3.0em; } .em30 input[size='11'] { width: 3.3em; } .em30 input[size='12'] { width: 3.6em; } .em30 input[size='13'] { width: 3.9em; } .em30 input[size='14'] { width: 4.2em; } .em30 input[size='15'] { width: 4.5em; } .em30 input[size='16'] { width: 4.8em; } .em30 input[size='17'] { width: 5.1em; } .em30 input[size='18'] { width: 5.4em; } .em30 input[size='19'] { width: 5.7em; } .em30 input[size='20'] { width: 6.0em; }
 .em35 input[size='1'] { width: 0.35em; } .em35 input[size='2'] { width: 0.7em; } .em35 input[size='3'] { width: 1.05em; } .em35 input[size='4'] { width: 1.4em; } .em35 input[size='5'] { width: 1.75em; } .em35 input[size='6'] { width: 2.1em; } .em35 input[size='7'] { width: 2.45em; } .em35 input[size='8'] { width: 2.8em; } .em35 input[size='9'] { width: 3.15em; } .em35 input[size='10'] { width: 3.5em; } .em35 input[size='11'] { width: 3.85em; } .em35 input[size='12'] { width: 4.2em; } .em35 input[size='13'] { width: 4.55em; } .em35 input[size='14'] { width: 4.9em; } .em35 input[size='15'] { width: 5.25em; } .em35 input[size='16'] { width: 5.6em; } .em35 input[size='17'] { width: 5.95em; } .em35 input[size='18'] { width: 6.3em; } .em35 input[size='19'] { width: 6.65em; } .em35 input[size='20'] { width: 7.0em; }
 .em40 input[size='1'] { width: 0.4em; } .em40 input[size='2'] { width: 0.8em; } .em40 input[size='3'] { width: 1.2em; } .em40 input[size='4'] { width: 1.6em; } .em40 input[size='5'] { width: 2.0em; } .em40 input[size='6'] { width: 2.4em; } .em40 input[size='7'] { width: 2.8em; } .em40 input[size='8'] { width: 3.2em; } .em40 input[size='9'] { width: 3.6em; } .em40 input[size='10'] { width: 4.0em; } .em40 input[size='11'] { width: 4.4em; } .em40 input[size='12'] { width: 4.8em; } .em40 input[size='13'] { width: 5.2em; } .em40 input[size='14'] { width: 5.6em; } .em40 input[size='15'] { width: 6.0em; } .em40 input[size='16'] { width: 6.4em; } .em40 input[size='17'] { width: 6.8em; } .em40 input[size='18'] { width: 7.2em; } .em40 input[size='19'] { width: 7.6em; } .em40 input[size='20'] { width: 8.0em; }
 .em45 input[size='1'] { width: 0.45em; } .em45 input[size='2'] { width: 0.9em; } .em45 input[size='3'] { width: 1.35em; } .em45 input[size='4'] { width: 1.8em; } .em45 input[size='5'] { width: 2.25em; } .em45 input[size='6'] { width: 2.7em; } .em45 input[size='7'] { width: 3.15em; } .em45 input[size='8'] { width: 3.6em; } .em45 input[size='9'] { width: 4.05em; } .em45 input[size='10'] { width: 4.5em; } .em45 input[size='11'] { width: 4.95em; } .em45 input[size='12'] { width: 5.4em; } .em45 input[size='13'] { width: 5.85em; } .em45 input[size='14'] { width: 6.3em; } .em45 input[size='15'] { width: 6.75em; } .em45 input[size='16'] { width: 7.2em; } .em45 input[size='17'] { width: 7.65em; } .em45 input[size='18'] { width: 8.1em; } .em45 input[size='19'] { width: 8.55em; } .em45 input[size='20'] { width: 9.0em; }
 .em50 input[size='1'] { width: 0.5em; } .em50 input[size='2'] { width: 1.0em; } .em50 input[size='3'] { width: 1.5em; } .em50 input[size='4'] { width: 2.0em; } .em50 input[size='5'] { width: 2.5em; } .em50 input[size='6'] { width: 3.0em; } .em50 input[size='7'] { width: 3.5em; } .em50 input[size='8'] { width: 4.0em; } .em50 input[size='9'] { width: 4.5em; } .em50 input[size='10'] { width: 5.0em; } .em50 input[size='11'] { width: 5.5em; } .em50 input[size='12'] { width: 6.0em; } .em50 input[size='13'] { width: 6.5em; } .em50 input[size='14'] { width: 7.0em; } .em50 input[size='15'] { width: 7.5em; } .em50 input[size='16'] { width: 8.0em; } .em50 input[size='17'] { width: 8.5em; } .em50 input[size='18'] { width: 9.0em; } .em50 input[size='19'] { width: 9.5em; } .em50 input[size='20'] { width: 10.0em; }
 .em55 input[size='1'] { width: 0.55em; } .em55 input[size='2'] { width: 1.1em; } .em55 input[size='3'] { width: 1.65em; } .em55 input[size='4'] { width: 2.2em; } .em55 input[size='5'] { width: 2.75em; } .em55 input[size='6'] { width: 3.3em; } .em55 input[size='7'] { width: 3.85em; } .em55 input[size='8'] { width: 4.4em; } .em55 input[size='9'] { width: 4.95em; } .em55 input[size='10'] { width: 5.5em; } .em55 input[size='11'] { width: 6.05em; } .em55 input[size='12'] { width: 6.6em; } .em55 input[size='13'] { width: 7.15em; } .em55 input[size='14'] { width: 7.7em; } .em55 input[size='15'] { width: 8.25em; } .em55 input[size='16'] { width: 8.8em; } .em55 input[size='17'] { width: 9.35em; } .em55 input[size='18'] { width: 9.9em; } .em55 input[size='19'] { width: 10.45em; } .em55 input[size='20'] { width: 11.0em; }
 .em60 input[size='1'] { width: 0.6em; } .em60 input[size='2'] { width: 1.2em; } .em60 input[size='3'] { width: 1.8em; } .em60 input[size='4'] { width: 2.4em; } .em60 input[size='5'] { width: 3.0em; } .em60 input[size='6'] { width: 3.6em; } .em60 input[size='7'] { width: 4.2em; } .em60 input[size='8'] { width: 4.8em; } .em60 input[size='9'] { width: 5.4em; } .em60 input[size='10'] { width: 6.0em; } .em60 input[size='11'] { width: 6.6em; } .em60 input[size='12'] { width: 7.2em; } .em60 input[size='13'] { width: 7.8em; } .em60 input[size='14'] { width: 8.4em; } .em60 input[size='15'] { width: 9.0em; } .em60 input[size='16'] { width: 9.6em; } .em60 input[size='17'] { width: 10.2em; } .em60 input[size='18'] { width: 10.8em; } .em60 input[size='19'] { width: 11.4em; } .em60 input[size='20'] { width: 12.0em; }
 .em65 input[size='1'] { width: 0.65em; } .em65 input[size='2'] { width: 1.3em; } .em65 input[size='3'] { width: 1.95em; } .em65 input[size='4'] { width: 2.6em; } .em65 input[size='5'] { width: 3.25em; } .em65 input[size='6'] { width: 3.9em; } .em65 input[size='7'] { width: 4.55em; } .em65 input[size='8'] { width: 5.2em; } .em65 input[size='9'] { width: 5.85em; } .em65 input[size='10'] { width: 6.5em; } .em65 input[size='11'] { width: 7.15em; } .em65 input[size='12'] { width: 7.8em; } .em65 input[size='13'] { width: 8.45em; } .em65 input[size='14'] { width: 9.1em; } .em65 input[size='15'] { width: 9.75em; } .em65 input[size='16'] { width: 10.4em; } .em65 input[size='17'] { width: 11.05em; } .em65 input[size='18'] { width: 11.7em; } .em65 input[size='19'] { width: 12.35em; } .em65 input[size='20'] { width: 13.0em; }
 .em70 input[size='1'] { width: 0.7em; } .em70 input[size='2'] { width: 1.4em; } .em70 input[size='3'] { width: 2.1em; } .em70 input[size='4'] { width: 2.8em; } .em70 input[size='5'] { width: 3.5em; } .em70 input[size='6'] { width: 4.2em; } .em70 input[size='7'] { width: 4.9em; } .em70 input[size='8'] { width: 5.6em; } .em70 input[size='9'] { width: 6.3em; } .em70 input[size='10'] { width: 7.0em; } .em70 input[size='11'] { width: 7.7em; } .em70 input[size='12'] { width: 8.4em; } .em70 input[size='13'] { width: 9.1em; } .em70 input[size='14'] { width: 9.8em; } .em70 input[size='15'] { width: 10.5em; } .em70 input[size='16'] { width: 11.2em; } .em70 input[size='17'] { width: 11.9em; } .em70 input[size='18'] { width: 12.6em; } .em70 input[size='19'] { width: 13.3em; } .em70 input[size='20'] { width: 14.0em; }
 .em75 input[size='1'] { width: 0.75em; } .em75 input[size='2'] { width: 1.5em; } .em75 input[size='3'] { width: 2.25em; } .em75 input[size='4'] { width: 3.0em; } .em75 input[size='5'] { width: 3.75em; } .em75 input[size='6'] { width: 4.5em; } .em75 input[size='7'] { width: 5.25em; } .em75 input[size='8'] { width: 6.0em; } .em75 input[size='9'] { width: 6.75em; } .em75 input[size='10'] { width: 7.5em; } .em75 input[size='11'] { width: 8.25em; } .em75 input[size='12'] { width: 9.0em; } .em75 input[size='13'] { width: 9.75em; } .em75 input[size='14'] { width: 10.5em; } .em75 input[size='15'] { width: 11.25em; } .em75 input[size='16'] { width: 12.0em; } .em75 input[size='17'] { width: 12.75em; } .em75 input[size='18'] { width: 13.5em; } .em75 input[size='19'] { width: 14.25em; } .em75 input[size='20'] { width: 15.0em; }
 .em80 input[size='1'] { width: 0.8em; } .em80 input[size='2'] { width: 1.6em; } .em80 input[size='3'] { width: 2.4em; } .em80 input[size='4'] { width: 3.2em; } .em80 input[size='5'] { width: 4.0em; } .em80 input[size='6'] { width: 4.8em; } .em80 input[size='7'] { width: 5.6em; } .em80 input[size='8'] { width: 6.4em; } .em80 input[size='9'] { width: 7.2em; } .em80 input[size='10'] { width: 8.0em; } .em80 input[size='11'] { width: 8.8em; } .em80 input[size='12'] { width: 9.6em; } .em80 input[size='13'] { width: 10.4em; } .em80 input[size='14'] { width: 11.2em; } .em80 input[size='15'] { width: 12.0em; } .em80 input[size='16'] { width: 12.8em; } .em80 input[size='17'] { width: 13.6em; } .em80 input[size='18'] { width: 14.4em; } .em80 input[size='19'] { width: 15.2em; } .em80 input[size='20'] { width: 16.0em; }
 .em85 input[size='1'] { width: 0.85em; } .em85 input[size='2'] { width: 1.7em; } .em85 input[size='3'] { width: 2.55em; } .em85 input[size='4'] { width: 3.4em; } .em85 input[size='5'] { width: 4.25em; } .em85 input[size='6'] { width: 5.1em; } .em85 input[size='7'] { width: 5.95em; } .em85 input[size='8'] { width: 6.8em; } .em85 input[size='9'] { width: 7.65em; } .em85 input[size='10'] { width: 8.5em; } .em85 input[size='11'] { width: 9.35em; } .em85 input[size='12'] { width: 10.2em; } .em85 input[size='13'] { width: 11.05em; } .em85 input[size='14'] { width: 11.9em; } .em85 input[size='15'] { width: 12.75em; } .em85 input[size='16'] { width: 13.6em; } .em85 input[size='17'] { width: 14.45em; } .em85 input[size='18'] { width: 15.3em; } .em85 input[size='19'] { width: 16.15em; } .em85 input[size='20'] { width: 17.0em; }
 .em90 input[size='1'] { width: 0.9em; } .em90 input[size='2'] { width: 1.8em; } .em90 input[size='3'] { width: 2.7em; } .em90 input[size='4'] { width: 3.6em; } .em90 input[size='5'] { width: 4.5em; } .em90 input[size='6'] { width: 5.4em; } .em90 input[size='7'] { width: 6.3em; } .em90 input[size='8'] { width: 7.2em; } .em90 input[size='9'] { width: 8.1em; } .em90 input[size='10'] { width: 9.0em; } .em90 input[size='11'] { width: 9.9em; } .em90 input[size='12'] { width: 10.8em; } .em90 input[size='13'] { width: 11.7em; } .em90 input[size='14'] { width: 12.6em; } .em90 input[size='15'] { width: 13.5em; } .em90 input[size='16'] { width: 14.4em; } .em90 input[size='17'] { width: 15.3em; } .em90 input[size='18'] { width: 16.2em; } .em90 input[size='19'] { width: 17.1em; } .em90 input[size='20'] { width: 18.0em; }
 .em95 input[size='1'] { width: 0.95em; } .em95 input[size='2'] { width: 1.9em; } .em95 input[size='3'] { width: 2.85em; } .em95 input[size='4'] { width: 3.8em; } .em95 input[size='5'] { width: 4.75em; } .em95 input[size='6'] { width: 5.7em; } .em95 input[size='7'] { width: 6.65em; } .em95 input[size='8'] { width: 7.6em; } .em95 input[size='9'] { width: 8.55em; } .em95 input[size='10'] { width: 9.5em; } .em95 input[size='11'] { width: 10.45em; } .em95 input[size='12'] { width: 11.4em; } .em95 input[size='13'] { width: 12.35em; } .em95 input[size='14'] { width: 13.3em; } .em95 input[size='15'] { width: 14.25em; } .em95 input[size='16'] { width: 15.2em; } .em95 input[size='17'] { width: 16.15em; } .em95 input[size='18'] { width: 17.1em; } .em95 input[size='19'] { width: 18.05em; } .em95 input[size='20'] { width: 19.0em; }
 .em100 input[size='1'] { width: 1.0em; } .em100 input[size='2'] { width: 2.0em; } .em100 input[size='3'] { width: 3.0em; } .em100 input[size='4'] { width: 4.0em; } .em100 input[size='5'] { width: 5.0em; } .em100 input[size='6'] { width: 6.0em; } .em100 input[size='7'] { width: 7.0em; } .em100 input[size='8'] { width: 8.0em; } .em100 input[size='9'] { width: 9.0em; } .em100 input[size='10'] { width: 10.0em; } .em100 input[size='11'] { width: 11.0em; } .em100 input[size='12'] { width: 12.0em; } .em100 input[size='13'] { width: 13.0em; } .em100 input[size='14'] { width: 14.0em; } .em100 input[size='15'] { width: 15.0em; } .em100 input[size='16'] { width: 16.0em; } .em100 input[size='17'] { width: 17.0em; } .em100 input[size='18'] { width: 18.0em; } .em100 input[size='19'] { width: 19.0em; } .em100 input[size='20'] { width: 20.0em; }
 input.Folded { cursor: default; }
 .Operator { color: #C678DD; }
 .Conditional { color: #C678DD; }
 .Type { color: #E5C07B; }
 .Constant { color: #56B6C2; }
 .Structure { color: #E5C07B; }
 .Statement { color: #C678DD; }
 .PreProc { color: #E5C07B; }
 .String { color: #98C379; }
 -->
 </style>

 <script type='text/javascript'>
 <!--

 /* simulate a "ch" unit by asking the browser how big a zero character is */
 function FixCharWidth() {
 /* get the hidden element which gives the width of a single character */
 var goodWidth = document.getElementById("oneCharWidth").clientWidth;
 /* get all input elements, we'll filter on class later */
 var inputTags = document.getElementsByTagName("input");
 var ratio = 5;
 var inputWidth = document.getElementById("oneInputWidth").clientWidth;
 var emWidth = document.getElementById("oneEmWidth").clientWidth;
 if (inputWidth > goodWidth) {
 while (ratio < 100*goodWidth/emWidth && ratio < 100) {
 ratio += 5;
 }
 document.getElementById("vimCodeElement").className = "em"+ratio;
 }
 }

 -->
 </script>
 </head>
 <body onload='FixCharWidth();'>
 <!-- hidden divs used by javascript to get the width of a char -->
 <div id='oneCharWidth'>0</div>
 <div id='oneInputWidth'><input size='1' value='0'></div>
 <div id='oneEmWidth' style='width: 1em;'></div>
 <pre id='vimCodeElement'>
 eq_3f_1 <span class="Operator">=</span> <span class="PreProc">setmetatable1</span>((<span class="Structure">{</span>[<span class="String">&quot;lookup&quot;</span>]<span class="Operator">=</span>(<span class="Structure">{}</span>)<span class="Structure">}</span>), (<span class="Structure">{</span>[<span class="String">&quot;__call&quot;</span>]<span class="Operator">=</span>(<span class="Statement">function</span>(temp_this, x, y)
 <span class="Type">local</span> temp_method
 <span class="Type">local</span> temp <span class="Operator">=</span> temp_this[<span class="String">&quot;lookup&quot;</span>]
 <span class="Conditional">if</span> temp <span class="Conditional">then</span>
 <span class="Type">local</span> temp1 <span class="Operator">=</span> temp[<span class="PreProc">type1</span>(x)]
 <span class="Conditional">if</span> temp1 <span class="Conditional">then</span>
 temp_method <span class="Operator">=</span> temp1[<span class="PreProc">type1</span>(y)] <span class="Operator">or</span> <span class="Constant">nil</span>
 <span class="Conditional">else</span>
 temp_method <span class="Operator">=</span> <span class="Constant">nil</span>
 <span class="Conditional">end</span>
 <span class="Conditional">else</span>
 temp_method <span class="Operator">=</span> <span class="Constant">nil</span>
 <span class="Conditional">end</span>
 <span class="Conditional">if</span> <span class="Operator">not</span> temp_method <span class="Conditional">then</span>
 <span class="Conditional">if</span> temp_this[<span class="String">&quot;default&quot;</span>] <span class="Conditional">then</span>
 temp_method <span class="Operator">=</span> temp_this[<span class="String">&quot;default&quot;</span>]
 <span class="Conditional">else</span>
 <span class="PreProc">error1</span>(<span class="String">&quot;No matching method to call for &quot;</span> <span class="Operator">..</span> (<span class="PreProc">type1</span>(x) <span class="Operator">..</span> <span class="String">&quot; &quot;</span>) <span class="Operator">..</span> (<span class="PreProc">type1</span>(y) <span class="Operator">..</span> <span class="String">&quot; &quot;</span>) <span class="Operator">..</span> <span class="String">&quot;</span>\n<span class="String">there are methods to call for &quot;</span> <span class="Operator">..</span> <span class="PreProc">keys1</span>(temp_this[<span class="String">&quot;lookup&quot;</span>]))
 <span class="Conditional">end</span>
 <span class="Conditional">end</span>
 <span class="Statement">return</span> <span class="PreProc">temp_method</span>(x, y)
 <span class="Statement">end</span>)<span class="Structure">}</span>))
 </pre>
 </body>
 </html>
 <!-- vim: set foldmethod=manual : -->
--- a/static/icon/android-chrome-192x192.png
+++ b/static/icon/android-chrome-192x192.png
--- a/static/icon/android-chrome-512x512.png
+++ b/static/icon/android-chrome-512x512.png
--- a/static/icon/apple-touch-icon.png
+++ b/static/icon/apple-touch-icon.png
--- a/static/icon/favicon-16x16.png
+++ b/static/icon/favicon-16x16.png
--- a/static/icon/favicon-32x32.png
+++ b/static/icon/favicon-32x32.png
--- a/static/icon/favicon.ico
+++ b/static/icon/favicon.ico
--- a/static/icon/valid-html20.png
+++ b/static/icon/valid-html20.png
--- a/static/licenses/LICENSE.FantasqueSansMono
+++ b/static/licenses/LICENSE.FantasqueSansMono
@ -0,0 +1,93 @@
 Copyright (c) 2013-2017, Jany Belluz ([email protected])

 This Font Software is licensed under the SIL Open Font License, Version 1.1.
 This license is copied below, and is also available with a FAQ at:
 http://scripts.sil.org/OFL


 -----------------------------------------------------------
 SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007
 -----------------------------------------------------------

 PREAMBLE
 The goals of the Open Font License (OFL) are to stimulate worldwide
 development of collaborative font projects, to support the font creation
 efforts of academic and linguistic communities, and to provide a free and
 open framework in which fonts may be shared and improved in partnership
 with others.

 The OFL allows the licensed fonts to be used, studied, modified and
 redistributed freely as long as they are not sold by themselves. The
 fonts, including any derivative works, can be bundled, embedded,
 redistributed and/or sold with any software provided that any reserved
 names are not used by derivative works. The fonts and derivatives,
 however, cannot be released under any other type of license. The
 requirement for fonts to remain under this license does not apply
 to any document created using the fonts or their derivatives.

 DEFINITIONS
 "Font Software" refers to the set of files released by the Copyright
 Holder(s) under this license and clearly marked as such. This may
 include source files, build scripts and documentation.

 "Reserved Font Name" refers to any names specified as such after the
 copyright statement(s).

 "Original Version" refers to the collection of Font Software components as
 distributed by the Copyright Holder(s).

 "Modified Version" refers to any derivative made by adding to, deleting,
 or substituting -- in part or in whole -- any of the components of the
 Original Version, by changing formats or by porting the Font Software to a
 new environment.

 "Author" refers to any designer, engineer, programmer, technical
 writer or other person who contributed to the Font Software.

 PERMISSION & CONDITIONS
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of the Font Software, to use, study, copy, merge, embed, modify,
 redistribute, and sell modified and unmodified copies of the Font
 Software, subject to the following conditions:

 1) Neither the Font Software nor any of its individual components,
 in Original or Modified Versions, may be sold by itself.

 2) Original or Modified Versions of the Font Software may be bundled,
 redistributed and/or sold with any software, provided that each copy
 contains the above copyright notice and this license. These can be
 included either as stand-alone text files, human-readable headers or
 in the appropriate machine-readable metadata fields within text or
 binary files as long as those fields can be easily viewed by the user.

 3) No Modified Version of the Font Software may use the Reserved Font
 Name(s) unless explicit written permission is granted by the corresponding
 Copyright Holder. This restriction only applies to the primary font name as
 presented to the users.

 4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font
 Software shall not be used to promote, endorse or advertise any
 Modified Version, except to acknowledge the contribution(s) of the
 Copyright Holder(s) and the Author(s) or with their explicit written
 permission.

 5) The Font Software, modified or unmodified, in part or in whole,
 must be distributed entirely under this license, and must not be
 distributed under any other license. The requirement for fonts to
 remain under this license does not apply to any document created
 using the Font Software.

 TERMINATION
 This license becomes null and void if any of the above conditions are
 not met.

 DISCLAIMER
 THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
 OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE
 COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
 DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM
 OTHER DEALINGS IN THE FONT SOFTWARE.
--- a/static/licenses/LICENSE.KaTeX
+++ b/static/licenses/LICENSE.KaTeX
@ -0,0 +1,21 @@
 The MIT License (MIT)

 Copyright (c) 2013-2018 Khan Academy

 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:

 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.

 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
--- a/static/pfp.jpg
+++ b/static/pfp.jpg
--- a/static/profunctor-impredicative.ml.html
+++ b/static/profunctor-impredicative.ml.html
@ -0,0 +1,215 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 <title>~/Projects/amulet/profunctor-impredicative.ml.html</title>
 <meta name="Generator" content="Vim/8.0">
 <meta name="plugin-version" content="vim8.1_v1">
 <meta name="syntax" content="amulet">
 <meta name="settings" content="use_css,pre_wrap,no_foldcolumn,expand_tabs,prevent_copy=t">
 <meta name="colorscheme" content="onedark">
 <style type="text/css">
 <!--
 pre { white-space: pre-wrap; font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 body { font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 * { font-size: 1em; }
 input { border: none; margin: 0; padding: 0; font-family: 'Iosevka','Iosevka Term', monospace; }
 input[size='1'] { width: 1em; width: 1ch; }
 input[size='2'] { width: 2em; width: 2ch; }
 input[size='3'] { width: 3em; width: 3ch; }
 input[size='4'] { width: 4em; width: 4ch; }
 input[size='5'] { width: 5em; width: 5ch; }
 input[size='6'] { width: 6em; width: 6ch; }
 input[size='7'] { width: 7em; width: 7ch; }
 input[size='8'] { width: 8em; width: 8ch; }
 input[size='9'] { width: 9em; width: 9ch; }
 input[size='10'] { width: 10em; width: 10ch; }
 input[size='11'] { width: 11em; width: 11ch; }
 input[size='12'] { width: 12em; width: 12ch; }
 input[size='13'] { width: 13em; width: 13ch; }
 input[size='14'] { width: 14em; width: 14ch; }
 input[size='15'] { width: 15em; width: 15ch; }
 input[size='16'] { width: 16em; width: 16ch; }
 input[size='17'] { width: 17em; width: 17ch; }
 input[size='18'] { width: 18em; width: 18ch; }
 input[size='19'] { width: 19em; width: 19ch; }
 input[size='20'] { width: 20em; width: 20ch; }
 #oneCharWidth, #oneEmWidth, #oneInputWidth { padding: 0; margin: 0; position: absolute; left: -999999px; visibility: hidden; }
 .em5 input[size='1'] { width: 0.05em; } .em5 input[size='2'] { width: 0.1em; } .em5 input[size='3'] { width: 0.15em; } .em5 input[size='4'] { width: 0.2em; } .em5 input[size='5'] { width: 0.25em; } .em5 input[size='6'] { width: 0.3em; } .em5 input[size='7'] { width: 0.35em; } .em5 input[size='8'] { width: 0.4em; } .em5 input[size='9'] { width: 0.45em; } .em5 input[size='10'] { width: 0.5em; } .em5 input[size='11'] { width: 0.55em; } .em5 input[size='12'] { width: 0.6em; } .em5 input[size='13'] { width: 0.65em; } .em5 input[size='14'] { width: 0.7em; } .em5 input[size='15'] { width: 0.75em; } .em5 input[size='16'] { width: 0.8em; } .em5 input[size='17'] { width: 0.85em; } .em5 input[size='18'] { width: 0.9em; } .em5 input[size='19'] { width: 0.95em; } .em5 input[size='20'] { width: 1.0em; }
 .em10 input[size='1'] { width: 0.1em; } .em10 input[size='2'] { width: 0.2em; } .em10 input[size='3'] { width: 0.3em; } .em10 input[size='4'] { width: 0.4em; } .em10 input[size='5'] { width: 0.5em; } .em10 input[size='6'] { width: 0.6em; } .em10 input[size='7'] { width: 0.7em; } .em10 input[size='8'] { width: 0.8em; } .em10 input[size='9'] { width: 0.9em; } .em10 input[size='10'] { width: 1.0em; } .em10 input[size='11'] { width: 1.1em; } .em10 input[size='12'] { width: 1.2em; } .em10 input[size='13'] { width: 1.3em; } .em10 input[size='14'] { width: 1.4em; } .em10 input[size='15'] { width: 1.5em; } .em10 input[size='16'] { width: 1.6em; } .em10 input[size='17'] { width: 1.7em; } .em10 input[size='18'] { width: 1.8em; } .em10 input[size='19'] { width: 1.9em; } .em10 input[size='20'] { width: 2.0em; }
 .em15 input[size='1'] { width: 0.15em; } .em15 input[size='2'] { width: 0.3em; } .em15 input[size='3'] { width: 0.45em; } .em15 input[size='4'] { width: 0.6em; } .em15 input[size='5'] { width: 0.75em; } .em15 input[size='6'] { width: 0.9em; } .em15 input[size='7'] { width: 1.05em; } .em15 input[size='8'] { width: 1.2em; } .em15 input[size='9'] { width: 1.35em; } .em15 input[size='10'] { width: 1.5em; } .em15 input[size='11'] { width: 1.65em; } .em15 input[size='12'] { width: 1.8em; } .em15 input[size='13'] { width: 1.95em; } .em15 input[size='14'] { width: 2.1em; } .em15 input[size='15'] { width: 2.25em; } .em15 input[size='16'] { width: 2.4em; } .em15 input[size='17'] { width: 2.55em; } .em15 input[size='18'] { width: 2.7em; } .em15 input[size='19'] { width: 2.85em; } .em15 input[size='20'] { width: 3.0em; }
 .em20 input[size='1'] { width: 0.2em; } .em20 input[size='2'] { width: 0.4em; } .em20 input[size='3'] { width: 0.6em; } .em20 input[size='4'] { width: 0.8em; } .em20 input[size='5'] { width: 1.0em; } .em20 input[size='6'] { width: 1.2em; } .em20 input[size='7'] { width: 1.4em; } .em20 input[size='8'] { width: 1.6em; } .em20 input[size='9'] { width: 1.8em; } .em20 input[size='10'] { width: 2.0em; } .em20 input[size='11'] { width: 2.2em; } .em20 input[size='12'] { width: 2.4em; } .em20 input[size='13'] { width: 2.6em; } .em20 input[size='14'] { width: 2.8em; } .em20 input[size='15'] { width: 3.0em; } .em20 input[size='16'] { width: 3.2em; } .em20 input[size='17'] { width: 3.4em; } .em20 input[size='18'] { width: 3.6em; } .em20 input[size='19'] { width: 3.8em; } .em20 input[size='20'] { width: 4.0em; }
 .em25 input[size='1'] { width: 0.25em; } .em25 input[size='2'] { width: 0.5em; } .em25 input[size='3'] { width: 0.75em; } .em25 input[size='4'] { width: 1.0em; } .em25 input[size='5'] { width: 1.25em; } .em25 input[size='6'] { width: 1.5em; } .em25 input[size='7'] { width: 1.75em; } .em25 input[size='8'] { width: 2.0em; } .em25 input[size='9'] { width: 2.25em; } .em25 input[size='10'] { width: 2.5em; } .em25 input[size='11'] { width: 2.75em; } .em25 input[size='12'] { width: 3.0em; } .em25 input[size='13'] { width: 3.25em; } .em25 input[size='14'] { width: 3.5em; } .em25 input[size='15'] { width: 3.75em; } .em25 input[size='16'] { width: 4.0em; } .em25 input[size='17'] { width: 4.25em; } .em25 input[size='18'] { width: 4.5em; } .em25 input[size='19'] { width: 4.75em; } .em25 input[size='20'] { width: 5.0em; }
 .em30 input[size='1'] { width: 0.3em; } .em30 input[size='2'] { width: 0.6em; } .em30 input[size='3'] { width: 0.9em; } .em30 input[size='4'] { width: 1.2em; } .em30 input[size='5'] { width: 1.5em; } .em30 input[size='6'] { width: 1.8em; } .em30 input[size='7'] { width: 2.1em; } .em30 input[size='8'] { width: 2.4em; } .em30 input[size='9'] { width: 2.7em; } .em30 input[size='10'] { width: 3.0em; } .em30 input[size='11'] { width: 3.3em; } .em30 input[size='12'] { width: 3.6em; } .em30 input[size='13'] { width: 3.9em; } .em30 input[size='14'] { width: 4.2em; } .em30 input[size='15'] { width: 4.5em; } .em30 input[size='16'] { width: 4.8em; } .em30 input[size='17'] { width: 5.1em; } .em30 input[size='18'] { width: 5.4em; } .em30 input[size='19'] { width: 5.7em; } .em30 input[size='20'] { width: 6.0em; }
 .em35 input[size='1'] { width: 0.35em; } .em35 input[size='2'] { width: 0.7em; } .em35 input[size='3'] { width: 1.05em; } .em35 input[size='4'] { width: 1.4em; } .em35 input[size='5'] { width: 1.75em; } .em35 input[size='6'] { width: 2.1em; } .em35 input[size='7'] { width: 2.45em; } .em35 input[size='8'] { width: 2.8em; } .em35 input[size='9'] { width: 3.15em; } .em35 input[size='10'] { width: 3.5em; } .em35 input[size='11'] { width: 3.85em; } .em35 input[size='12'] { width: 4.2em; } .em35 input[size='13'] { width: 4.55em; } .em35 input[size='14'] { width: 4.9em; } .em35 input[size='15'] { width: 5.25em; } .em35 input[size='16'] { width: 5.6em; } .em35 input[size='17'] { width: 5.95em; } .em35 input[size='18'] { width: 6.3em; } .em35 input[size='19'] { width: 6.65em; } .em35 input[size='20'] { width: 7.0em; }
 .em40 input[size='1'] { width: 0.4em; } .em40 input[size='2'] { width: 0.8em; } .em40 input[size='3'] { width: 1.2em; } .em40 input[size='4'] { width: 1.6em; } .em40 input[size='5'] { width: 2.0em; } .em40 input[size='6'] { width: 2.4em; } .em40 input[size='7'] { width: 2.8em; } .em40 input[size='8'] { width: 3.2em; } .em40 input[size='9'] { width: 3.6em; } .em40 input[size='10'] { width: 4.0em; } .em40 input[size='11'] { width: 4.4em; } .em40 input[size='12'] { width: 4.8em; } .em40 input[size='13'] { width: 5.2em; } .em40 input[size='14'] { width: 5.6em; } .em40 input[size='15'] { width: 6.0em; } .em40 input[size='16'] { width: 6.4em; } .em40 input[size='17'] { width: 6.8em; } .em40 input[size='18'] { width: 7.2em; } .em40 input[size='19'] { width: 7.6em; } .em40 input[size='20'] { width: 8.0em; }
 .em45 input[size='1'] { width: 0.45em; } .em45 input[size='2'] { width: 0.9em; } .em45 input[size='3'] { width: 1.35em; } .em45 input[size='4'] { width: 1.8em; } .em45 input[size='5'] { width: 2.25em; } .em45 input[size='6'] { width: 2.7em; } .em45 input[size='7'] { width: 3.15em; } .em45 input[size='8'] { width: 3.6em; } .em45 input[size='9'] { width: 4.05em; } .em45 input[size='10'] { width: 4.5em; } .em45 input[size='11'] { width: 4.95em; } .em45 input[size='12'] { width: 5.4em; } .em45 input[size='13'] { width: 5.85em; } .em45 input[size='14'] { width: 6.3em; } .em45 input[size='15'] { width: 6.75em; } .em45 input[size='16'] { width: 7.2em; } .em45 input[size='17'] { width: 7.65em; } .em45 input[size='18'] { width: 8.1em; } .em45 input[size='19'] { width: 8.55em; } .em45 input[size='20'] { width: 9.0em; }
 .em50 input[size='1'] { width: 0.5em; } .em50 input[size='2'] { width: 1.0em; } .em50 input[size='3'] { width: 1.5em; } .em50 input[size='4'] { width: 2.0em; } .em50 input[size='5'] { width: 2.5em; } .em50 input[size='6'] { width: 3.0em; } .em50 input[size='7'] { width: 3.5em; } .em50 input[size='8'] { width: 4.0em; } .em50 input[size='9'] { width: 4.5em; } .em50 input[size='10'] { width: 5.0em; } .em50 input[size='11'] { width: 5.5em; } .em50 input[size='12'] { width: 6.0em; } .em50 input[size='13'] { width: 6.5em; } .em50 input[size='14'] { width: 7.0em; } .em50 input[size='15'] { width: 7.5em; } .em50 input[size='16'] { width: 8.0em; } .em50 input[size='17'] { width: 8.5em; } .em50 input[size='18'] { width: 9.0em; } .em50 input[size='19'] { width: 9.5em; } .em50 input[size='20'] { width: 10.0em; }
 .em55 input[size='1'] { width: 0.55em; } .em55 input[size='2'] { width: 1.1em; } .em55 input[size='3'] { width: 1.65em; } .em55 input[size='4'] { width: 2.2em; } .em55 input[size='5'] { width: 2.75em; } .em55 input[size='6'] { width: 3.3em; } .em55 input[size='7'] { width: 3.85em; } .em55 input[size='8'] { width: 4.4em; } .em55 input[size='9'] { width: 4.95em; } .em55 input[size='10'] { width: 5.5em; } .em55 input[size='11'] { width: 6.05em; } .em55 input[size='12'] { width: 6.6em; } .em55 input[size='13'] { width: 7.15em; } .em55 input[size='14'] { width: 7.7em; } .em55 input[size='15'] { width: 8.25em; } .em55 input[size='16'] { width: 8.8em; } .em55 input[size='17'] { width: 9.35em; } .em55 input[size='18'] { width: 9.9em; } .em55 input[size='19'] { width: 10.45em; } .em55 input[size='20'] { width: 11.0em; }
 .em60 input[size='1'] { width: 0.6em; } .em60 input[size='2'] { width: 1.2em; } .em60 input[size='3'] { width: 1.8em; } .em60 input[size='4'] { width: 2.4em; } .em60 input[size='5'] { width: 3.0em; } .em60 input[size='6'] { width: 3.6em; } .em60 input[size='7'] { width: 4.2em; } .em60 input[size='8'] { width: 4.8em; } .em60 input[size='9'] { width: 5.4em; } .em60 input[size='10'] { width: 6.0em; } .em60 input[size='11'] { width: 6.6em; } .em60 input[size='12'] { width: 7.2em; } .em60 input[size='13'] { width: 7.8em; } .em60 input[size='14'] { width: 8.4em; } .em60 input[size='15'] { width: 9.0em; } .em60 input[size='16'] { width: 9.6em; } .em60 input[size='17'] { width: 10.2em; } .em60 input[size='18'] { width: 10.8em; } .em60 input[size='19'] { width: 11.4em; } .em60 input[size='20'] { width: 12.0em; }
 .em65 input[size='1'] { width: 0.65em; } .em65 input[size='2'] { width: 1.3em; } .em65 input[size='3'] { width: 1.95em; } .em65 input[size='4'] { width: 2.6em; } .em65 input[size='5'] { width: 3.25em; } .em65 input[size='6'] { width: 3.9em; } .em65 input[size='7'] { width: 4.55em; } .em65 input[size='8'] { width: 5.2em; } .em65 input[size='9'] { width: 5.85em; } .em65 input[size='10'] { width: 6.5em; } .em65 input[size='11'] { width: 7.15em; } .em65 input[size='12'] { width: 7.8em; } .em65 input[size='13'] { width: 8.45em; } .em65 input[size='14'] { width: 9.1em; } .em65 input[size='15'] { width: 9.75em; } .em65 input[size='16'] { width: 10.4em; } .em65 input[size='17'] { width: 11.05em; } .em65 input[size='18'] { width: 11.7em; } .em65 input[size='19'] { width: 12.35em; } .em65 input[size='20'] { width: 13.0em; }
 .em70 input[size='1'] { width: 0.7em; } .em70 input[size='2'] { width: 1.4em; } .em70 input[size='3'] { width: 2.1em; } .em70 input[size='4'] { width: 2.8em; } .em70 input[size='5'] { width: 3.5em; } .em70 input[size='6'] { width: 4.2em; } .em70 input[size='7'] { width: 4.9em; } .em70 input[size='8'] { width: 5.6em; } .em70 input[size='9'] { width: 6.3em; } .em70 input[size='10'] { width: 7.0em; } .em70 input[size='11'] { width: 7.7em; } .em70 input[size='12'] { width: 8.4em; } .em70 input[size='13'] { width: 9.1em; } .em70 input[size='14'] { width: 9.8em; } .em70 input[size='15'] { width: 10.5em; } .em70 input[size='16'] { width: 11.2em; } .em70 input[size='17'] { width: 11.9em; } .em70 input[size='18'] { width: 12.6em; } .em70 input[size='19'] { width: 13.3em; } .em70 input[size='20'] { width: 14.0em; }
 .em75 input[size='1'] { width: 0.75em; } .em75 input[size='2'] { width: 1.5em; } .em75 input[size='3'] { width: 2.25em; } .em75 input[size='4'] { width: 3.0em; } .em75 input[size='5'] { width: 3.75em; } .em75 input[size='6'] { width: 4.5em; } .em75 input[size='7'] { width: 5.25em; } .em75 input[size='8'] { width: 6.0em; } .em75 input[size='9'] { width: 6.75em; } .em75 input[size='10'] { width: 7.5em; } .em75 input[size='11'] { width: 8.25em; } .em75 input[size='12'] { width: 9.0em; } .em75 input[size='13'] { width: 9.75em; } .em75 input[size='14'] { width: 10.5em; } .em75 input[size='15'] { width: 11.25em; } .em75 input[size='16'] { width: 12.0em; } .em75 input[size='17'] { width: 12.75em; } .em75 input[size='18'] { width: 13.5em; } .em75 input[size='19'] { width: 14.25em; } .em75 input[size='20'] { width: 15.0em; }
 .em80 input[size='1'] { width: 0.8em; } .em80 input[size='2'] { width: 1.6em; } .em80 input[size='3'] { width: 2.4em; } .em80 input[size='4'] { width: 3.2em; } .em80 input[size='5'] { width: 4.0em; } .em80 input[size='6'] { width: 4.8em; } .em80 input[size='7'] { width: 5.6em; } .em80 input[size='8'] { width: 6.4em; } .em80 input[size='9'] { width: 7.2em; } .em80 input[size='10'] { width: 8.0em; } .em80 input[size='11'] { width: 8.8em; } .em80 input[size='12'] { width: 9.6em; } .em80 input[size='13'] { width: 10.4em; } .em80 input[size='14'] { width: 11.2em; } .em80 input[size='15'] { width: 12.0em; } .em80 input[size='16'] { width: 12.8em; } .em80 input[size='17'] { width: 13.6em; } .em80 input[size='18'] { width: 14.4em; } .em80 input[size='19'] { width: 15.2em; } .em80 input[size='20'] { width: 16.0em; }
 .em85 input[size='1'] { width: 0.85em; } .em85 input[size='2'] { width: 1.7em; } .em85 input[size='3'] { width: 2.55em; } .em85 input[size='4'] { width: 3.4em; } .em85 input[size='5'] { width: 4.25em; } .em85 input[size='6'] { width: 5.1em; } .em85 input[size='7'] { width: 5.95em; } .em85 input[size='8'] { width: 6.8em; } .em85 input[size='9'] { width: 7.65em; } .em85 input[size='10'] { width: 8.5em; } .em85 input[size='11'] { width: 9.35em; } .em85 input[size='12'] { width: 10.2em; } .em85 input[size='13'] { width: 11.05em; } .em85 input[size='14'] { width: 11.9em; } .em85 input[size='15'] { width: 12.75em; } .em85 input[size='16'] { width: 13.6em; } .em85 input[size='17'] { width: 14.45em; } .em85 input[size='18'] { width: 15.3em; } .em85 input[size='19'] { width: 16.15em; } .em85 input[size='20'] { width: 17.0em; }
 .em90 input[size='1'] { width: 0.9em; } .em90 input[size='2'] { width: 1.8em; } .em90 input[size='3'] { width: 2.7em; } .em90 input[size='4'] { width: 3.6em; } .em90 input[size='5'] { width: 4.5em; } .em90 input[size='6'] { width: 5.4em; } .em90 input[size='7'] { width: 6.3em; } .em90 input[size='8'] { width: 7.2em; } .em90 input[size='9'] { width: 8.1em; } .em90 input[size='10'] { width: 9.0em; } .em90 input[size='11'] { width: 9.9em; } .em90 input[size='12'] { width: 10.8em; } .em90 input[size='13'] { width: 11.7em; } .em90 input[size='14'] { width: 12.6em; } .em90 input[size='15'] { width: 13.5em; } .em90 input[size='16'] { width: 14.4em; } .em90 input[size='17'] { width: 15.3em; } .em90 input[size='18'] { width: 16.2em; } .em90 input[size='19'] { width: 17.1em; } .em90 input[size='20'] { width: 18.0em; }
 .em95 input[size='1'] { width: 0.95em; } .em95 input[size='2'] { width: 1.9em; } .em95 input[size='3'] { width: 2.85em; } .em95 input[size='4'] { width: 3.8em; } .em95 input[size='5'] { width: 4.75em; } .em95 input[size='6'] { width: 5.7em; } .em95 input[size='7'] { width: 6.65em; } .em95 input[size='8'] { width: 7.6em; } .em95 input[size='9'] { width: 8.55em; } .em95 input[size='10'] { width: 9.5em; } .em95 input[size='11'] { width: 10.45em; } .em95 input[size='12'] { width: 11.4em; } .em95 input[size='13'] { width: 12.35em; } .em95 input[size='14'] { width: 13.3em; } .em95 input[size='15'] { width: 14.25em; } .em95 input[size='16'] { width: 15.2em; } .em95 input[size='17'] { width: 16.15em; } .em95 input[size='18'] { width: 17.1em; } .em95 input[size='19'] { width: 18.05em; } .em95 input[size='20'] { width: 19.0em; }
 .em100 input[size='1'] { width: 1.0em; } .em100 input[size='2'] { width: 2.0em; } .em100 input[size='3'] { width: 3.0em; } .em100 input[size='4'] { width: 4.0em; } .em100 input[size='5'] { width: 5.0em; } .em100 input[size='6'] { width: 6.0em; } .em100 input[size='7'] { width: 7.0em; } .em100 input[size='8'] { width: 8.0em; } .em100 input[size='9'] { width: 9.0em; } .em100 input[size='10'] { width: 10.0em; } .em100 input[size='11'] { width: 11.0em; } .em100 input[size='12'] { width: 12.0em; } .em100 input[size='13'] { width: 13.0em; } .em100 input[size='14'] { width: 14.0em; } .em100 input[size='15'] { width: 15.0em; } .em100 input[size='16'] { width: 16.0em; } .em100 input[size='17'] { width: 17.0em; } .em100 input[size='18'] { width: 18.0em; } .em100 input[size='19'] { width: 19.0em; } .em100 input[size='20'] { width: 20.0em; }
 input.Folded { cursor: default; }
 .Operator { color: #C678DD; }
 .Type { color: #E5C07B; }
 .Constant { color: #56B6C2; }
 .String { color: #98C379; }
 .Include { color: #61AFEF; }
 .Special { color: #61AFEF; }
 .Float { color: #D19A66; }
 .Keyword { color: #E06C75; }
 -->
 </style>

 <script type='text/javascript'>
 <!--

 /* simulate a "ch" unit by asking the browser how big a zero character is */
 function FixCharWidth() {
 /* get the hidden element which gives the width of a single character */
 var goodWidth = document.getElementById("oneCharWidth").clientWidth;
 /* get all input elements, we'll filter on class later */
 var inputTags = document.getElementsByTagName("input");
 var ratio = 5;
 var inputWidth = document.getElementById("oneInputWidth").clientWidth;
 var emWidth = document.getElementById("oneEmWidth").clientWidth;
 if (inputWidth > goodWidth) {
 while (ratio < 100*goodWidth/emWidth && ratio < 100) {
 ratio += 5;
 }
 document.getElementById("vimCodeElement").className = "em"+ratio;
 }
 }

 -->
 </script>
 </head>
 <body onload='FixCharWidth();'>
 <!-- hidden divs used by javascript to get the width of a char -->
 <div id='oneCharWidth'>0</div>
 <div id='oneInputWidth'><input size='1' value='0'></div>
 <div id='oneEmWidth' style='width: 1em;'></div>
 <pre id='vimCodeElement'>
 <span class="Keyword">external</span> <span class="Keyword">val</span> print <span class="Operator">:</span> <span class="Type">'a</span> <span class="Operator">-&gt;</span> <span class="Special">unit</span> <span class="Operator">=</span> <span class="String">&quot;print&quot;</span>

 <span class="Keyword">let</span> id x <span class="Operator">=</span> x
 <span class="Keyword">let</span> f <span class="Operator">&amp;</span> g <span class="Operator">=</span> <span class="Keyword">fun</span> x <span class="Operator">-&gt;</span> f <span class="Keyword">(</span>g x<span class="Keyword">)</span>
 <span class="Keyword">let</span> const x <span class="Keyword">_</span> <span class="Operator">=</span> x
 <span class="Keyword">let</span> x <span class="Operator">|</span><span class="Operator">&gt;</span> f <span class="Operator">=</span> f x

 <span class="Keyword">let</span> fst <span class="Keyword">(</span>x<span class="Operator">,</span> <span class="Keyword">_</span><span class="Keyword">)</span> <span class="Operator">=</span> x
 <span class="Keyword">let</span> snd <span class="Keyword">(</span><span class="Keyword">_</span><span class="Operator">,</span> x<span class="Keyword">)</span> <span class="Operator">=</span> x
 <span class="Keyword">let</span> uncurry f <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">)</span> <span class="Operator">=</span> f x y

 <span class="Keyword">let</span> fork f g x <span class="Operator">=</span> <span class="Keyword">(</span>f x<span class="Operator">,</span> g x<span class="Keyword">)</span>

 <span class="Keyword">class</span> profunctor <span class="Type">'p</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> dimap <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span> <span class="Type">'d</span><span class="Operator">.</span> <span class="Keyword">(</span><span class="Type">'b</span> <span class="Operator">-&gt;</span> <span class="Type">'a</span><span class="Keyword">)</span> <span class="Operator">-&gt;</span> <span class="Keyword">(</span><span class="Type">'c</span> <span class="Operator">-&gt;</span> <span class="Type">'d</span><span class="Keyword">)</span>
 <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'c</span> <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Type">'b</span> <span class="Type">'d</span>
 <span class="Keyword">end</span>

 <span class="Keyword">let</span> lmap g <span class="Operator">=</span> dimap g id
 <span class="Keyword">let</span> rmap x <span class="Operator">=</span> dimap id x

 <span class="Keyword">class</span> profunctor <span class="Type">'p</span> <span class="Operator">=</span><span class="Operator">&gt;</span> strong <span class="Type">'p</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> first <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Operator">.</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Keyword">(</span><span class="Type">'a</span> <span class="Operator">*</span> <span class="Type">'c</span><span class="Keyword">)</span> <span class="Keyword">(</span><span class="Type">'b</span> <span class="Operator">*</span> <span class="Type">'c</span><span class="Keyword">)</span>
 <span class="Keyword">val</span> second <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Operator">.</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Keyword">(</span><span class="Type">'c</span> <span class="Operator">*</span> <span class="Type">'a</span><span class="Keyword">)</span> <span class="Keyword">(</span><span class="Type">'c</span> <span class="Operator">*</span> <span class="Type">'b</span><span class="Keyword">)</span>
 <span class="Keyword">end</span>

 <span class="Keyword">type</span> <span class="Special">either</span> <span class="Type">'l</span> <span class="Type">'r</span> <span class="Operator">=</span> <span class="Constant">Left</span> <span class="Keyword">of</span> <span class="Type">'l</span> <span class="Operator">|</span> <span class="Constant">Right</span> <span class="Keyword">of</span> <span class="Type">'r</span>

 <span class="Keyword">let</span> <span class="Special">either</span> f g <span class="Operator">=</span> <span class="Keyword">function</span>
 <span class="Operator">|</span> <span class="Constant">Left</span> x <span class="Operator">-&gt;</span> f x
 <span class="Operator">|</span> <span class="Constant">Right</span> y <span class="Operator">-&gt;</span> g y

 <span class="Keyword">class</span> profunctor <span class="Type">'p</span> <span class="Operator">=</span><span class="Operator">&gt;</span> choice <span class="Type">'p</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> left <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Operator">.</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span>
 <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Type">'a</span> <span class="Type">'c</span><span class="Keyword">)</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Keyword">)</span>
 <span class="Keyword">val</span> right <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Operator">.</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span>
 <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Type">'c</span> <span class="Type">'a</span><span class="Keyword">)</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Type">'c</span> <span class="Type">'b</span><span class="Keyword">)</span>
 <span class="Keyword">end</span>

 <span class="Keyword">class</span> monoid <span class="Type">'m</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> <span class="Keyword">(</span><span class="Operator">&lt;&gt;</span><span class="Keyword">)</span> <span class="Operator">:</span> <span class="Type">'m</span> <span class="Operator">-&gt;</span> <span class="Type">'m</span> <span class="Operator">-&gt;</span> <span class="Type">'m</span>
 <span class="Keyword">val</span> zero <span class="Operator">:</span> <span class="Type">'m</span>
 <span class="Keyword">end</span>

 <span class="Keyword">type</span> forget <span class="Type">'r</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">of</span> <span class="Type">'a</span> <span class="Operator">-&gt;</span> <span class="Type">'r</span>
 <span class="Keyword">let</span> remember <span class="Keyword">(</span><span class="Constant">Forget</span> r<span class="Keyword">)</span> <span class="Operator">=</span> r

 <span class="Keyword">instance</span> profunctor <span class="Keyword">(</span><span class="Operator">-&gt;</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> dimap f g h <span class="Operator">=</span> g <span class="Operator">&amp;</span> h <span class="Operator">&amp;</span> f

 <span class="Keyword">instance</span> strong <span class="Keyword">(</span><span class="Operator">-&gt;</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> first f <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Keyword">(</span>f x<span class="Operator">,</span> y<span class="Keyword">)</span>
 <span class="Keyword">let</span> second f <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Keyword">(</span>x<span class="Operator">,</span> f y<span class="Keyword">)</span>

 <span class="Keyword">instance</span> choice <span class="Keyword">(</span><span class="Operator">-&gt;</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> left f <span class="Operator">=</span> <span class="Special">either</span> <span class="Keyword">(</span><span class="Constant">Left</span> <span class="Operator">&amp;</span> f<span class="Keyword">)</span> <span class="Constant">Right</span>
 <span class="Keyword">let</span> right f <span class="Operator">=</span> <span class="Special">either</span> <span class="Constant">Left</span> <span class="Keyword">(</span><span class="Constant">Right</span> <span class="Operator">&amp;</span> f<span class="Keyword">)</span>

 <span class="Keyword">instance</span> profunctor <span class="Keyword">(</span>forget <span class="Type">'r</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> dimap f <span class="Keyword">_</span> <span class="Keyword">(</span><span class="Constant">Forget</span> g<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span>g <span class="Operator">&amp;</span> f<span class="Keyword">)</span>

 <span class="Keyword">instance</span> monoid <span class="Type">'r</span> <span class="Operator">=</span><span class="Operator">&gt;</span> choice <span class="Keyword">(</span>forget <span class="Type">'r</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> left <span class="Keyword">(</span><span class="Constant">Forget</span> z<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span><span class="Special">either</span> z <span class="Keyword">(</span>const zero<span class="Keyword">))</span>
 <span class="Keyword">let</span> right <span class="Keyword">(</span><span class="Constant">Forget</span> z<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Keyword">(</span>const zero<span class="Keyword">)</span> z<span class="Keyword">)</span>

 <span class="Keyword">instance</span> strong <span class="Keyword">(</span>forget <span class="Type">'r</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> first <span class="Keyword">(</span><span class="Constant">Forget</span> z<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span>z <span class="Operator">&amp;</span> fst<span class="Keyword">)</span>
 <span class="Keyword">let</span> second <span class="Keyword">(</span><span class="Constant">Forget</span> z<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span>z <span class="Operator">&amp;</span> snd<span class="Keyword">)</span>

 <span class="Keyword">let</span> lens get set <span class="Operator">=</span>
 dimap <span class="Keyword">(</span>fork get id<span class="Keyword">)</span> <span class="Keyword">(</span>uncurry set<span class="Keyword">)</span> <span class="Operator">&amp;</span> first

 <span class="Keyword">let</span> view l <span class="Operator">=</span> remember <span class="Keyword">(</span>l <span class="Keyword">(</span><span class="Constant">Forget</span> id<span class="Keyword">))</span>
 <span class="Keyword">let</span> over f <span class="Operator">=</span> f
 <span class="Keyword">let</span> set l b <span class="Operator">=</span> over l <span class="Keyword">(</span>const b<span class="Keyword">)</span>

 <span class="Keyword">type</span> pair <span class="Type">'a</span> <span class="Type">'b</span> <span class="Operator">=</span> <span class="Constant">Pair</span> <span class="Keyword">of</span> <span class="Type">'a</span> <span class="Operator">*</span> <span class="Type">'b</span>
 <span class="Keyword">let</span> fst' <span class="Keyword">(</span><span class="Constant">Pair</span> <span class="Keyword">(</span>x<span class="Operator">,</span> <span class="Keyword">_</span><span class="Keyword">))</span> <span class="Operator">=</span> x
 <span class="Keyword">let</span> snd' <span class="Keyword">(</span><span class="Constant">Pair</span> <span class="Keyword">(</span><span class="Keyword">_</span><span class="Operator">,</span> x<span class="Keyword">))</span> <span class="Operator">=</span> x

 <span class="Keyword">let</span> first' x <span class="Operator">=</span> lens fst' <span class="Keyword">(fun</span> x <span class="Keyword">(</span><span class="Constant">Pair</span> <span class="Keyword">(</span><span class="Keyword">_</span><span class="Operator">,</span> y<span class="Keyword">))</span> <span class="Operator">-&gt;</span> <span class="Constant">Pair</span> <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">))</span> x
 <span class="Keyword">let</span> second' x <span class="Operator">=</span> lens snd' <span class="Keyword">(fun</span> y <span class="Keyword">(</span><span class="Constant">Pair</span> <span class="Keyword">(</span>x<span class="Operator">,</span> <span class="Keyword">_</span><span class="Keyword">))</span> <span class="Operator">-&gt;</span> <span class="Constant">Pair</span> <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">))</span> x

 <span class="Keyword">type</span> proxy <span class="Type">'a</span> <span class="Operator">=</span> <span class="Constant">Proxy</span>

 <span class="Keyword">type</span> lens <span class="Type">'s</span> <span class="Type">'t</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Operator">&lt;-</span> <span class="Keyword">forall</span> <span class="Type">'p</span><span class="Operator">.</span> strong <span class="Type">'p</span> <span class="Operator">=</span><span class="Operator">&gt;</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Type">'s</span> <span class="Type">'t</span>
 <span class="Keyword">type</span> lens' <span class="Type">'s</span> <span class="Type">'a</span> <span class="Operator">&lt;-</span> lens <span class="Type">'s</span> <span class="Type">'s</span> <span class="Type">'a</span> <span class="Type">'a</span>

 <span class="Keyword">class</span> <span class="Include">Amc</span>.row_cons <span class="Type">'record</span> <span class="Type">'key</span> <span class="Type">'type</span> <span class="Type">'new</span> <span class="Operator">=</span><span class="Operator">&gt;</span> has_lens <span class="Type">'record</span> <span class="Type">'key</span> <span class="Type">'type</span> <span class="Type">'new</span> <span class="Operator">|</span> <span class="Type">'key</span> <span class="Type">'new</span> <span class="Operator">-&gt;</span> <span class="Type">'record</span> <span class="Type">'type</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> rlens <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'p</span><span class="Operator">.</span> strong <span class="Type">'p</span> <span class="Operator">=</span><span class="Operator">&gt;</span> proxy <span class="Type">'key</span> <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Type">'type</span> <span class="Type">'type</span> <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Type">'new</span> <span class="Type">'new</span>
 <span class="Keyword">end</span>

 <span class="Keyword">instance</span> <span class="Include">Amc</span>.known_string <span class="Type">'key</span> <span class="Operator">*</span> <span class="Include">Amc</span>.row_cons <span class="Type">'record</span> <span class="Type">'key</span> <span class="Type">'type</span> <span class="Type">'new</span> <span class="Operator">=</span><span class="Operator">&gt;</span> has_lens <span class="Type">'record</span> <span class="Type">'key</span> <span class="Type">'type</span> <span class="Type">'new</span> <span class="Keyword">begin</span>
 <span class="Keyword">let</span> rlens <span class="Keyword">_</span> <span class="Operator">=</span>
 <span class="Keyword">let</span> view r <span class="Operator">=</span>
 <span class="Keyword">let</span> <span class="Keyword">(</span>x<span class="Operator">,</span> <span class="Keyword">_</span><span class="Keyword">)</span> <span class="Operator">=</span> <span class="Include">Amc</span>.restrict_row <span class="Operator">@</span><span class="Type">'key</span> r
 x
 <span class="Keyword">let</span> set x r <span class="Operator">=</span>
 <span class="Keyword">let</span> <span class="Keyword">(</span><span class="Keyword">_</span><span class="Operator">,</span> r'<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Include">Amc</span>.restrict_row <span class="Operator">@</span><span class="Type">'key</span> r
 <span class="Include">Amc</span>.extend_row <span class="Operator">@</span><span class="Type">'key</span> x r'
 lens view set
 <span class="Keyword">end</span>

 <span class="Keyword">let</span> r <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'key</span> <span class="Operator">-&gt;</span> <span class="Keyword">forall</span> <span class="Type">'record</span> <span class="Type">'type</span> <span class="Type">'new</span> <span class="Type">'p</span><span class="Operator">.</span> <span class="Include">Amc</span>.known_string <span class="Type">'key</span> <span class="Operator">*</span> has_lens <span class="Type">'record</span> <span class="Type">'key</span> <span class="Type">'type</span> <span class="Type">'new</span> <span class="Operator">*</span> strong <span class="Type">'p</span> <span class="Operator">=</span><span class="Operator">&gt;</span> <span class="Type">'p</span> <span class="Type">'type</span> <span class="Type">'type</span> <span class="Operator">-&gt;</span> <span class="Type">'p</span> <span class="Type">'new</span> <span class="Type">'new</span> <span class="Operator">=</span>
 <span class="Keyword">fun</span> x <span class="Operator">-&gt;</span> rlens <span class="Operator">@</span><span class="Type">'record</span> <span class="Keyword">(</span><span class="Constant">Proxy</span> <span class="Operator">:</span> proxy <span class="Type">'key</span><span class="Keyword">)</span> x

 <span class="Keyword">let</span> x <span class="Operator">::</span> xs <span class="Operator">=</span> <span class="Constant">Cons</span> <span class="Keyword">(</span>x<span class="Operator">,</span> xs<span class="Keyword">)</span>
 <span class="Keyword">let</span> lens_list <span class="Constant">()</span> <span class="Operator">=</span> <span class="Keyword">(fun</span> x <span class="Operator">-&gt;</span> r <span class="Operator">@</span><span class="String">&quot;foo&quot;</span> x<span class="Keyword">)</span> <span class="Operator">::</span> <span class="Keyword">(fun</span> x <span class="Operator">-&gt;</span> r <span class="Operator">@</span><span class="String">&quot;bar&quot;</span> x<span class="Keyword">)</span> <span class="Operator">::</span> <span class="Constant">Nil</span> <span class="Operator">@</span><span class="Keyword">(</span>lens' <span class="Keyword">_</span> <span class="Keyword">_</span><span class="Keyword">)</span>

 <span class="Keyword">let</span> map f xs <span class="Operator">=</span> <span class="Keyword">[</span> f x <span class="Operator">|</span> <span class="Keyword">with</span> x <span class="Operator">&lt;-</span> xs <span class="Keyword">]</span>

 <span class="Keyword">let</span> x <span class="Operator">=</span> <span class="Keyword">{</span> foo <span class="Operator">=</span> <span class="Float">1</span><span class="Operator">,</span> bar <span class="Operator">=</span> <span class="Float">2</span> <span class="Keyword">}</span>
 <span class="Keyword">let</span> xs <span class="Operator">=</span> map <span class="Keyword">(</span>`view` x<span class="Keyword">)</span> <span class="Keyword">(</span>lens_list <span class="Constant">()</span><span class="Keyword">)</span>
 </pre>
 </body>
 </html>
 <!-- vim: set foldmethod=manual : -->
--- a/static/profunctors.ml.html
+++ b/static/profunctors.ml.html
@ -0,0 +1,224 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 <title>~/Projects/amulet/profunctors.ml.html</title>
 <meta name="Generator" content="Vim/8.0">
 <meta name="plugin-version" content="vim8.1_v1">
 <meta name="syntax" content="amulet">
 <meta name="settings" content="use_css,pre_wrap,no_foldcolumn,expand_tabs,prevent_copy=t">
 <meta name="colorscheme" content="onedark">
 <style type="text/css">
 <!--
 pre { white-space: pre-wrap; font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 body { font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 * { font-size: 1em; }
 input { border: none; margin: 0; padding: 0; font-family: 'Iosevka','Iosevka Term', monospace; }
 input[size='1'] { width: 1em; width: 1ch; }
 input[size='2'] { width: 2em; width: 2ch; }
 input[size='3'] { width: 3em; width: 3ch; }
 input[size='4'] { width: 4em; width: 4ch; }
 input[size='5'] { width: 5em; width: 5ch; }
 input[size='6'] { width: 6em; width: 6ch; }
 input[size='7'] { width: 7em; width: 7ch; }
 input[size='8'] { width: 8em; width: 8ch; }
 input[size='9'] { width: 9em; width: 9ch; }
 input[size='10'] { width: 10em; width: 10ch; }
 input[size='11'] { width: 11em; width: 11ch; }
 input[size='12'] { width: 12em; width: 12ch; }
 input[size='13'] { width: 13em; width: 13ch; }
 input[size='14'] { width: 14em; width: 14ch; }
 input[size='15'] { width: 15em; width: 15ch; }
 input[size='16'] { width: 16em; width: 16ch; }
 input[size='17'] { width: 17em; width: 17ch; }
 input[size='18'] { width: 18em; width: 18ch; }
 input[size='19'] { width: 19em; width: 19ch; }
 input[size='20'] { width: 20em; width: 20ch; }
 #oneCharWidth, #oneEmWidth, #oneInputWidth { padding: 0; margin: 0; position: absolute; left: -999999px; visibility: hidden; }
 .em5 input[size='1'] { width: 0.05em; } .em5 input[size='2'] { width: 0.1em; } .em5 input[size='3'] { width: 0.15em; } .em5 input[size='4'] { width: 0.2em; } .em5 input[size='5'] { width: 0.25em; } .em5 input[size='6'] { width: 0.3em; } .em5 input[size='7'] { width: 0.35em; } .em5 input[size='8'] { width: 0.4em; } .em5 input[size='9'] { width: 0.45em; } .em5 input[size='10'] { width: 0.5em; } .em5 input[size='11'] { width: 0.55em; } .em5 input[size='12'] { width: 0.6em; } .em5 input[size='13'] { width: 0.65em; } .em5 input[size='14'] { width: 0.7em; } .em5 input[size='15'] { width: 0.75em; } .em5 input[size='16'] { width: 0.8em; } .em5 input[size='17'] { width: 0.85em; } .em5 input[size='18'] { width: 0.9em; } .em5 input[size='19'] { width: 0.95em; } .em5 input[size='20'] { width: 1.0em; }
 .em10 input[size='1'] { width: 0.1em; } .em10 input[size='2'] { width: 0.2em; } .em10 input[size='3'] { width: 0.3em; } .em10 input[size='4'] { width: 0.4em; } .em10 input[size='5'] { width: 0.5em; } .em10 input[size='6'] { width: 0.6em; } .em10 input[size='7'] { width: 0.7em; } .em10 input[size='8'] { width: 0.8em; } .em10 input[size='9'] { width: 0.9em; } .em10 input[size='10'] { width: 1.0em; } .em10 input[size='11'] { width: 1.1em; } .em10 input[size='12'] { width: 1.2em; } .em10 input[size='13'] { width: 1.3em; } .em10 input[size='14'] { width: 1.4em; } .em10 input[size='15'] { width: 1.5em; } .em10 input[size='16'] { width: 1.6em; } .em10 input[size='17'] { width: 1.7em; } .em10 input[size='18'] { width: 1.8em; } .em10 input[size='19'] { width: 1.9em; } .em10 input[size='20'] { width: 2.0em; }
 .em15 input[size='1'] { width: 0.15em; } .em15 input[size='2'] { width: 0.3em; } .em15 input[size='3'] { width: 0.45em; } .em15 input[size='4'] { width: 0.6em; } .em15 input[size='5'] { width: 0.75em; } .em15 input[size='6'] { width: 0.9em; } .em15 input[size='7'] { width: 1.05em; } .em15 input[size='8'] { width: 1.2em; } .em15 input[size='9'] { width: 1.35em; } .em15 input[size='10'] { width: 1.5em; } .em15 input[size='11'] { width: 1.65em; } .em15 input[size='12'] { width: 1.8em; } .em15 input[size='13'] { width: 1.95em; } .em15 input[size='14'] { width: 2.1em; } .em15 input[size='15'] { width: 2.25em; } .em15 input[size='16'] { width: 2.4em; } .em15 input[size='17'] { width: 2.55em; } .em15 input[size='18'] { width: 2.7em; } .em15 input[size='19'] { width: 2.85em; } .em15 input[size='20'] { width: 3.0em; }
 .em20 input[size='1'] { width: 0.2em; } .em20 input[size='2'] { width: 0.4em; } .em20 input[size='3'] { width: 0.6em; } .em20 input[size='4'] { width: 0.8em; } .em20 input[size='5'] { width: 1.0em; } .em20 input[size='6'] { width: 1.2em; } .em20 input[size='7'] { width: 1.4em; } .em20 input[size='8'] { width: 1.6em; } .em20 input[size='9'] { width: 1.8em; } .em20 input[size='10'] { width: 2.0em; } .em20 input[size='11'] { width: 2.2em; } .em20 input[size='12'] { width: 2.4em; } .em20 input[size='13'] { width: 2.6em; } .em20 input[size='14'] { width: 2.8em; } .em20 input[size='15'] { width: 3.0em; } .em20 input[size='16'] { width: 3.2em; } .em20 input[size='17'] { width: 3.4em; } .em20 input[size='18'] { width: 3.6em; } .em20 input[size='19'] { width: 3.8em; } .em20 input[size='20'] { width: 4.0em; }
 .em25 input[size='1'] { width: 0.25em; } .em25 input[size='2'] { width: 0.5em; } .em25 input[size='3'] { width: 0.75em; } .em25 input[size='4'] { width: 1.0em; } .em25 input[size='5'] { width: 1.25em; } .em25 input[size='6'] { width: 1.5em; } .em25 input[size='7'] { width: 1.75em; } .em25 input[size='8'] { width: 2.0em; } .em25 input[size='9'] { width: 2.25em; } .em25 input[size='10'] { width: 2.5em; } .em25 input[size='11'] { width: 2.75em; } .em25 input[size='12'] { width: 3.0em; } .em25 input[size='13'] { width: 3.25em; } .em25 input[size='14'] { width: 3.5em; } .em25 input[size='15'] { width: 3.75em; } .em25 input[size='16'] { width: 4.0em; } .em25 input[size='17'] { width: 4.25em; } .em25 input[size='18'] { width: 4.5em; } .em25 input[size='19'] { width: 4.75em; } .em25 input[size='20'] { width: 5.0em; }
 .em30 input[size='1'] { width: 0.3em; } .em30 input[size='2'] { width: 0.6em; } .em30 input[size='3'] { width: 0.9em; } .em30 input[size='4'] { width: 1.2em; } .em30 input[size='5'] { width: 1.5em; } .em30 input[size='6'] { width: 1.8em; } .em30 input[size='7'] { width: 2.1em; } .em30 input[size='8'] { width: 2.4em; } .em30 input[size='9'] { width: 2.7em; } .em30 input[size='10'] { width: 3.0em; } .em30 input[size='11'] { width: 3.3em; } .em30 input[size='12'] { width: 3.6em; } .em30 input[size='13'] { width: 3.9em; } .em30 input[size='14'] { width: 4.2em; } .em30 input[size='15'] { width: 4.5em; } .em30 input[size='16'] { width: 4.8em; } .em30 input[size='17'] { width: 5.1em; } .em30 input[size='18'] { width: 5.4em; } .em30 input[size='19'] { width: 5.7em; } .em30 input[size='20'] { width: 6.0em; }
 .em35 input[size='1'] { width: 0.35em; } .em35 input[size='2'] { width: 0.7em; } .em35 input[size='3'] { width: 1.05em; } .em35 input[size='4'] { width: 1.4em; } .em35 input[size='5'] { width: 1.75em; } .em35 input[size='6'] { width: 2.1em; } .em35 input[size='7'] { width: 2.45em; } .em35 input[size='8'] { width: 2.8em; } .em35 input[size='9'] { width: 3.15em; } .em35 input[size='10'] { width: 3.5em; } .em35 input[size='11'] { width: 3.85em; } .em35 input[size='12'] { width: 4.2em; } .em35 input[size='13'] { width: 4.55em; } .em35 input[size='14'] { width: 4.9em; } .em35 input[size='15'] { width: 5.25em; } .em35 input[size='16'] { width: 5.6em; } .em35 input[size='17'] { width: 5.95em; } .em35 input[size='18'] { width: 6.3em; } .em35 input[size='19'] { width: 6.65em; } .em35 input[size='20'] { width: 7.0em; }
 .em40 input[size='1'] { width: 0.4em; } .em40 input[size='2'] { width: 0.8em; } .em40 input[size='3'] { width: 1.2em; } .em40 input[size='4'] { width: 1.6em; } .em40 input[size='5'] { width: 2.0em; } .em40 input[size='6'] { width: 2.4em; } .em40 input[size='7'] { width: 2.8em; } .em40 input[size='8'] { width: 3.2em; } .em40 input[size='9'] { width: 3.6em; } .em40 input[size='10'] { width: 4.0em; } .em40 input[size='11'] { width: 4.4em; } .em40 input[size='12'] { width: 4.8em; } .em40 input[size='13'] { width: 5.2em; } .em40 input[size='14'] { width: 5.6em; } .em40 input[size='15'] { width: 6.0em; } .em40 input[size='16'] { width: 6.4em; } .em40 input[size='17'] { width: 6.8em; } .em40 input[size='18'] { width: 7.2em; } .em40 input[size='19'] { width: 7.6em; } .em40 input[size='20'] { width: 8.0em; }
 .em45 input[size='1'] { width: 0.45em; } .em45 input[size='2'] { width: 0.9em; } .em45 input[size='3'] { width: 1.35em; } .em45 input[size='4'] { width: 1.8em; } .em45 input[size='5'] { width: 2.25em; } .em45 input[size='6'] { width: 2.7em; } .em45 input[size='7'] { width: 3.15em; } .em45 input[size='8'] { width: 3.6em; } .em45 input[size='9'] { width: 4.05em; } .em45 input[size='10'] { width: 4.5em; } .em45 input[size='11'] { width: 4.95em; } .em45 input[size='12'] { width: 5.4em; } .em45 input[size='13'] { width: 5.85em; } .em45 input[size='14'] { width: 6.3em; } .em45 input[size='15'] { width: 6.75em; } .em45 input[size='16'] { width: 7.2em; } .em45 input[size='17'] { width: 7.65em; } .em45 input[size='18'] { width: 8.1em; } .em45 input[size='19'] { width: 8.55em; } .em45 input[size='20'] { width: 9.0em; }
 .em50 input[size='1'] { width: 0.5em; } .em50 input[size='2'] { width: 1.0em; } .em50 input[size='3'] { width: 1.5em; } .em50 input[size='4'] { width: 2.0em; } .em50 input[size='5'] { width: 2.5em; } .em50 input[size='6'] { width: 3.0em; } .em50 input[size='7'] { width: 3.5em; } .em50 input[size='8'] { width: 4.0em; } .em50 input[size='9'] { width: 4.5em; } .em50 input[size='10'] { width: 5.0em; } .em50 input[size='11'] { width: 5.5em; } .em50 input[size='12'] { width: 6.0em; } .em50 input[size='13'] { width: 6.5em; } .em50 input[size='14'] { width: 7.0em; } .em50 input[size='15'] { width: 7.5em; } .em50 input[size='16'] { width: 8.0em; } .em50 input[size='17'] { width: 8.5em; } .em50 input[size='18'] { width: 9.0em; } .em50 input[size='19'] { width: 9.5em; } .em50 input[size='20'] { width: 10.0em; }
 .em55 input[size='1'] { width: 0.55em; } .em55 input[size='2'] { width: 1.1em; } .em55 input[size='3'] { width: 1.65em; } .em55 input[size='4'] { width: 2.2em; } .em55 input[size='5'] { width: 2.75em; } .em55 input[size='6'] { width: 3.3em; } .em55 input[size='7'] { width: 3.85em; } .em55 input[size='8'] { width: 4.4em; } .em55 input[size='9'] { width: 4.95em; } .em55 input[size='10'] { width: 5.5em; } .em55 input[size='11'] { width: 6.05em; } .em55 input[size='12'] { width: 6.6em; } .em55 input[size='13'] { width: 7.15em; } .em55 input[size='14'] { width: 7.7em; } .em55 input[size='15'] { width: 8.25em; } .em55 input[size='16'] { width: 8.8em; } .em55 input[size='17'] { width: 9.35em; } .em55 input[size='18'] { width: 9.9em; } .em55 input[size='19'] { width: 10.45em; } .em55 input[size='20'] { width: 11.0em; }
 .em60 input[size='1'] { width: 0.6em; } .em60 input[size='2'] { width: 1.2em; } .em60 input[size='3'] { width: 1.8em; } .em60 input[size='4'] { width: 2.4em; } .em60 input[size='5'] { width: 3.0em; } .em60 input[size='6'] { width: 3.6em; } .em60 input[size='7'] { width: 4.2em; } .em60 input[size='8'] { width: 4.8em; } .em60 input[size='9'] { width: 5.4em; } .em60 input[size='10'] { width: 6.0em; } .em60 input[size='11'] { width: 6.6em; } .em60 input[size='12'] { width: 7.2em; } .em60 input[size='13'] { width: 7.8em; } .em60 input[size='14'] { width: 8.4em; } .em60 input[size='15'] { width: 9.0em; } .em60 input[size='16'] { width: 9.6em; } .em60 input[size='17'] { width: 10.2em; } .em60 input[size='18'] { width: 10.8em; } .em60 input[size='19'] { width: 11.4em; } .em60 input[size='20'] { width: 12.0em; }
 .em65 input[size='1'] { width: 0.65em; } .em65 input[size='2'] { width: 1.3em; } .em65 input[size='3'] { width: 1.95em; } .em65 input[size='4'] { width: 2.6em; } .em65 input[size='5'] { width: 3.25em; } .em65 input[size='6'] { width: 3.9em; } .em65 input[size='7'] { width: 4.55em; } .em65 input[size='8'] { width: 5.2em; } .em65 input[size='9'] { width: 5.85em; } .em65 input[size='10'] { width: 6.5em; } .em65 input[size='11'] { width: 7.15em; } .em65 input[size='12'] { width: 7.8em; } .em65 input[size='13'] { width: 8.45em; } .em65 input[size='14'] { width: 9.1em; } .em65 input[size='15'] { width: 9.75em; } .em65 input[size='16'] { width: 10.4em; } .em65 input[size='17'] { width: 11.05em; } .em65 input[size='18'] { width: 11.7em; } .em65 input[size='19'] { width: 12.35em; } .em65 input[size='20'] { width: 13.0em; }
 .em70 input[size='1'] { width: 0.7em; } .em70 input[size='2'] { width: 1.4em; } .em70 input[size='3'] { width: 2.1em; } .em70 input[size='4'] { width: 2.8em; } .em70 input[size='5'] { width: 3.5em; } .em70 input[size='6'] { width: 4.2em; } .em70 input[size='7'] { width: 4.9em; } .em70 input[size='8'] { width: 5.6em; } .em70 input[size='9'] { width: 6.3em; } .em70 input[size='10'] { width: 7.0em; } .em70 input[size='11'] { width: 7.7em; } .em70 input[size='12'] { width: 8.4em; } .em70 input[size='13'] { width: 9.1em; } .em70 input[size='14'] { width: 9.8em; } .em70 input[size='15'] { width: 10.5em; } .em70 input[size='16'] { width: 11.2em; } .em70 input[size='17'] { width: 11.9em; } .em70 input[size='18'] { width: 12.6em; } .em70 input[size='19'] { width: 13.3em; } .em70 input[size='20'] { width: 14.0em; }
 .em75 input[size='1'] { width: 0.75em; } .em75 input[size='2'] { width: 1.5em; } .em75 input[size='3'] { width: 2.25em; } .em75 input[size='4'] { width: 3.0em; } .em75 input[size='5'] { width: 3.75em; } .em75 input[size='6'] { width: 4.5em; } .em75 input[size='7'] { width: 5.25em; } .em75 input[size='8'] { width: 6.0em; } .em75 input[size='9'] { width: 6.75em; } .em75 input[size='10'] { width: 7.5em; } .em75 input[size='11'] { width: 8.25em; } .em75 input[size='12'] { width: 9.0em; } .em75 input[size='13'] { width: 9.75em; } .em75 input[size='14'] { width: 10.5em; } .em75 input[size='15'] { width: 11.25em; } .em75 input[size='16'] { width: 12.0em; } .em75 input[size='17'] { width: 12.75em; } .em75 input[size='18'] { width: 13.5em; } .em75 input[size='19'] { width: 14.25em; } .em75 input[size='20'] { width: 15.0em; }
 .em80 input[size='1'] { width: 0.8em; } .em80 input[size='2'] { width: 1.6em; } .em80 input[size='3'] { width: 2.4em; } .em80 input[size='4'] { width: 3.2em; } .em80 input[size='5'] { width: 4.0em; } .em80 input[size='6'] { width: 4.8em; } .em80 input[size='7'] { width: 5.6em; } .em80 input[size='8'] { width: 6.4em; } .em80 input[size='9'] { width: 7.2em; } .em80 input[size='10'] { width: 8.0em; } .em80 input[size='11'] { width: 8.8em; } .em80 input[size='12'] { width: 9.6em; } .em80 input[size='13'] { width: 10.4em; } .em80 input[size='14'] { width: 11.2em; } .em80 input[size='15'] { width: 12.0em; } .em80 input[size='16'] { width: 12.8em; } .em80 input[size='17'] { width: 13.6em; } .em80 input[size='18'] { width: 14.4em; } .em80 input[size='19'] { width: 15.2em; } .em80 input[size='20'] { width: 16.0em; }
 .em85 input[size='1'] { width: 0.85em; } .em85 input[size='2'] { width: 1.7em; } .em85 input[size='3'] { width: 2.55em; } .em85 input[size='4'] { width: 3.4em; } .em85 input[size='5'] { width: 4.25em; } .em85 input[size='6'] { width: 5.1em; } .em85 input[size='7'] { width: 5.95em; } .em85 input[size='8'] { width: 6.8em; } .em85 input[size='9'] { width: 7.65em; } .em85 input[size='10'] { width: 8.5em; } .em85 input[size='11'] { width: 9.35em; } .em85 input[size='12'] { width: 10.2em; } .em85 input[size='13'] { width: 11.05em; } .em85 input[size='14'] { width: 11.9em; } .em85 input[size='15'] { width: 12.75em; } .em85 input[size='16'] { width: 13.6em; } .em85 input[size='17'] { width: 14.45em; } .em85 input[size='18'] { width: 15.3em; } .em85 input[size='19'] { width: 16.15em; } .em85 input[size='20'] { width: 17.0em; }
 .em90 input[size='1'] { width: 0.9em; } .em90 input[size='2'] { width: 1.8em; } .em90 input[size='3'] { width: 2.7em; } .em90 input[size='4'] { width: 3.6em; } .em90 input[size='5'] { width: 4.5em; } .em90 input[size='6'] { width: 5.4em; } .em90 input[size='7'] { width: 6.3em; } .em90 input[size='8'] { width: 7.2em; } .em90 input[size='9'] { width: 8.1em; } .em90 input[size='10'] { width: 9.0em; } .em90 input[size='11'] { width: 9.9em; } .em90 input[size='12'] { width: 10.8em; } .em90 input[size='13'] { width: 11.7em; } .em90 input[size='14'] { width: 12.6em; } .em90 input[size='15'] { width: 13.5em; } .em90 input[size='16'] { width: 14.4em; } .em90 input[size='17'] { width: 15.3em; } .em90 input[size='18'] { width: 16.2em; } .em90 input[size='19'] { width: 17.1em; } .em90 input[size='20'] { width: 18.0em; }
 .em95 input[size='1'] { width: 0.95em; } .em95 input[size='2'] { width: 1.9em; } .em95 input[size='3'] { width: 2.85em; } .em95 input[size='4'] { width: 3.8em; } .em95 input[size='5'] { width: 4.75em; } .em95 input[size='6'] { width: 5.7em; } .em95 input[size='7'] { width: 6.65em; } .em95 input[size='8'] { width: 7.6em; } .em95 input[size='9'] { width: 8.55em; } .em95 input[size='10'] { width: 9.5em; } .em95 input[size='11'] { width: 10.45em; } .em95 input[size='12'] { width: 11.4em; } .em95 input[size='13'] { width: 12.35em; } .em95 input[size='14'] { width: 13.3em; } .em95 input[size='15'] { width: 14.25em; } .em95 input[size='16'] { width: 15.2em; } .em95 input[size='17'] { width: 16.15em; } .em95 input[size='18'] { width: 17.1em; } .em95 input[size='19'] { width: 18.05em; } .em95 input[size='20'] { width: 19.0em; }
 .em100 input[size='1'] { width: 1.0em; } .em100 input[size='2'] { width: 2.0em; } .em100 input[size='3'] { width: 3.0em; } .em100 input[size='4'] { width: 4.0em; } .em100 input[size='5'] { width: 5.0em; } .em100 input[size='6'] { width: 6.0em; } .em100 input[size='7'] { width: 7.0em; } .em100 input[size='8'] { width: 8.0em; } .em100 input[size='9'] { width: 9.0em; } .em100 input[size='10'] { width: 10.0em; } .em100 input[size='11'] { width: 11.0em; } .em100 input[size='12'] { width: 12.0em; } .em100 input[size='13'] { width: 13.0em; } .em100 input[size='14'] { width: 14.0em; } .em100 input[size='15'] { width: 15.0em; } .em100 input[size='16'] { width: 16.0em; } .em100 input[size='17'] { width: 17.0em; } .em100 input[size='18'] { width: 18.0em; } .em100 input[size='19'] { width: 19.0em; } .em100 input[size='20'] { width: 20.0em; }
 input.Folded { cursor: default; }
 .Operator { color: #C678DD; }
 .Type { color: #E5C07B; }
 .Include { color: #61AFEF; }
 .Special { color: #61AFEF; }
 .String { color: #98C379; }
 .Float { color: #D19A66; }
 .Constant { color: #56B6C2; }
 .Keyword { color: #E06C75; }
 -->
 </style>

 <script type='text/javascript'>
 <!--

 /* simulate a "ch" unit by asking the browser how big a zero character is */
 function FixCharWidth() {
 /* get the hidden element which gives the width of a single character */
 var goodWidth = document.getElementById("oneCharWidth").clientWidth;
 /* get all input elements, we'll filter on class later */
 var inputTags = document.getElementsByTagName("input");
 var ratio = 5;
 var inputWidth = document.getElementById("oneInputWidth").clientWidth;
 var emWidth = document.getElementById("oneEmWidth").clientWidth;
 if (inputWidth > goodWidth) {
 while (ratio < 100*goodWidth/emWidth && ratio < 100) {
 ratio += 5;
 }
 document.getElementById("vimCodeElement").className = "em"+ratio;
 }
 }

 -->
 </script>
 </head>
 <body onload='FixCharWidth();'>
 <!-- hidden divs used by javascript to get the width of a char -->
 <div id='oneCharWidth'>0</div>
 <div id='oneInputWidth'><input size='1' value='0'></div>
 <div id='oneEmWidth' style='width: 1em;'></div>
 <pre id='vimCodeElement'>
 <span class="Keyword">external</span> <span class="Keyword">val</span> print <span class="Operator">:</span> <span class="Type">'a</span> <span class="Keyword">-&gt;</span> <span class="Special">unit</span> <span class="Operator">=</span> <span class="String">&quot;print&quot;</span>

 <span class="Keyword">let</span> id x <span class="Operator">=</span> x
 <span class="Keyword">let</span> f <span class="Operator">&lt;&lt;&lt;</span> g <span class="Operator">=</span> <span class="Keyword">fun</span> x <span class="Keyword">-&gt;</span> f <span class="Keyword">(</span>g x<span class="Keyword">)</span>
 <span class="Keyword">let</span> const x <span class="Keyword">_</span> <span class="Operator">=</span> x
 <span class="Keyword">let</span> x <span class="Operator">|</span><span class="Operator">&gt;</span> f <span class="Operator">=</span> f x

 <span class="Keyword">let</span> fst <span class="Keyword">(</span>x<span class="Operator">,</span> <span class="Keyword">_</span><span class="Keyword">)</span> <span class="Operator">=</span> x
 <span class="Keyword">let</span> snd <span class="Keyword">(</span><span class="Keyword">_</span><span class="Operator">,</span> x<span class="Keyword">)</span> <span class="Operator">=</span> x
 <span class="Keyword">let</span> uncurry f <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">)</span> <span class="Operator">=</span> f x y

 <span class="Keyword">let</span> fork f g x <span class="Operator">=</span> <span class="Keyword">(</span>f x<span class="Operator">,</span> g x<span class="Keyword">)</span>

 <span class="Keyword">class</span> profunctor <span class="Type">'p</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> dimap <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span> <span class="Type">'d</span><span class="Operator">.</span> <span class="Keyword">(</span><span class="Type">'b</span> <span class="Keyword">-&gt;</span> <span class="Type">'a</span><span class="Keyword">)</span> <span class="Keyword">-&gt;</span> <span class="Keyword">(</span><span class="Type">'c</span> <span class="Keyword">-&gt;</span> <span class="Type">'d</span><span class="Keyword">)</span>
 <span class="Keyword">-&gt;</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'c</span> <span class="Keyword">-&gt;</span> <span class="Type">'p</span> <span class="Type">'b</span> <span class="Type">'d</span>
 <span class="Keyword">end</span>

 <span class="Keyword">let</span> lmap g <span class="Operator">=</span> dimap g id
 <span class="Keyword">let</span> rmap x <span class="Operator">=</span> dimap id x

 <span class="Keyword">class</span> profunctor <span class="Type">'p</span> <span class="Operator">=</span><span class="Operator">&gt;</span> strong <span class="Type">'p</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> first <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Operator">.</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Keyword">-&gt;</span> <span class="Type">'p</span> <span class="Keyword">(</span><span class="Type">'a</span> <span class="Operator">*</span> <span class="Type">'c</span><span class="Keyword">)</span> <span class="Keyword">(</span><span class="Type">'b</span> <span class="Operator">*</span> <span class="Type">'c</span><span class="Keyword">)</span>
 <span class="Keyword">val</span> second <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Operator">.</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Keyword">-&gt;</span> <span class="Type">'p</span> <span class="Keyword">(</span><span class="Type">'c</span> <span class="Operator">*</span> <span class="Type">'a</span><span class="Keyword">)</span> <span class="Keyword">(</span><span class="Type">'c</span> <span class="Operator">*</span> <span class="Type">'b</span><span class="Keyword">)</span>
 <span class="Keyword">end</span>

 <span class="Keyword">type</span> <span class="Special">either</span> <span class="Type">'l</span> <span class="Type">'r</span> <span class="Operator">=</span> <span class="Constant">Left</span> <span class="Keyword">of</span> <span class="Type">'l</span> <span class="Operator">|</span> <span class="Constant">Right</span> <span class="Keyword">of</span> <span class="Type">'r</span>

 <span class="Keyword">let</span> <span class="Special">either</span> f g <span class="Operator">=</span> <span class="Keyword">function</span>
 <span class="Operator">|</span> <span class="Constant">Left</span> x <span class="Keyword">-&gt;</span> f x
 <span class="Operator">|</span> <span class="Constant">Right</span> y <span class="Keyword">-&gt;</span> g y

 <span class="Keyword">class</span> profunctor <span class="Type">'p</span> <span class="Operator">=</span><span class="Operator">&gt;</span> choice <span class="Type">'p</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> left <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Operator">.</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span>
 <span class="Keyword">-&gt;</span> <span class="Type">'p</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Type">'a</span> <span class="Type">'c</span><span class="Keyword">)</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Keyword">)</span>
 <span class="Keyword">val</span> right <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Type">'c</span><span class="Operator">.</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'b</span>
 <span class="Keyword">-&gt;</span> <span class="Type">'p</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Type">'c</span> <span class="Type">'a</span><span class="Keyword">)</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Type">'c</span> <span class="Type">'b</span><span class="Keyword">)</span>
 <span class="Keyword">end</span>

 <span class="Keyword">class</span> monoid <span class="Type">'m</span> <span class="Keyword">begin</span>
 <span class="Keyword">val</span> <span class="Keyword">(</span><span class="Operator">&lt;&gt;</span><span class="Keyword">)</span> <span class="Operator">:</span> <span class="Type">'m</span> <span class="Keyword">-&gt;</span> <span class="Type">'m</span> <span class="Keyword">-&gt;</span> <span class="Type">'m</span>
 <span class="Keyword">val</span> zero <span class="Operator">:</span> <span class="Type">'m</span>
 <span class="Keyword">end</span>

 <span class="Keyword">type</span> forget <span class="Type">'r</span> <span class="Type">'a</span> <span class="Type">'b</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">of</span> <span class="Type">'a</span> <span class="Keyword">-&gt;</span> <span class="Type">'r</span>
 <span class="Keyword">let</span> remember <span class="Keyword">(</span><span class="Constant">Forget</span> r<span class="Keyword">)</span> <span class="Operator">=</span> r

 <span class="Keyword">instance</span> profunctor <span class="Keyword">(</span><span class="Keyword">-&gt;</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> dimap f g h <span class="Operator">=</span> g <span class="Operator">&lt;&lt;&lt;</span> h <span class="Operator">&lt;&lt;&lt;</span> f

 <span class="Keyword">instance</span> strong <span class="Keyword">(</span><span class="Keyword">-&gt;</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> first f <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Keyword">(</span>f x<span class="Operator">,</span> y<span class="Keyword">)</span>
 <span class="Keyword">let</span> second f <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Keyword">(</span>x<span class="Operator">,</span> f y<span class="Keyword">)</span>

 <span class="Keyword">instance</span> choice <span class="Keyword">(</span><span class="Keyword">-&gt;</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> left f <span class="Operator">=</span> <span class="Special">either</span> <span class="Keyword">(</span><span class="Constant">Left</span> <span class="Operator">&lt;&lt;&lt;</span> f<span class="Keyword">)</span> <span class="Constant">Right</span>
 <span class="Keyword">let</span> right f <span class="Operator">=</span> <span class="Special">either</span> <span class="Constant">Left</span> <span class="Keyword">(</span><span class="Constant">Right</span> <span class="Operator">&lt;&lt;&lt;</span> f<span class="Keyword">)</span>

 <span class="Keyword">instance</span> profunctor <span class="Keyword">(</span>forget <span class="Type">'r</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> dimap f <span class="Keyword">_</span> <span class="Keyword">(</span><span class="Constant">Forget</span> g<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span>g <span class="Operator">&lt;&lt;&lt;</span> f<span class="Keyword">)</span>

 <span class="Keyword">instance</span> monoid <span class="Type">'r</span> <span class="Operator">=</span><span class="Operator">&gt;</span> choice <span class="Keyword">(</span>forget <span class="Type">'r</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> left <span class="Keyword">(</span><span class="Constant">Forget</span> z<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span><span class="Special">either</span> z <span class="Keyword">(</span>const zero<span class="Keyword">))</span>
 <span class="Keyword">let</span> right <span class="Keyword">(</span><span class="Constant">Forget</span> z<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span><span class="Special">either</span> <span class="Keyword">(</span>const zero<span class="Keyword">)</span> z<span class="Keyword">)</span>

 <span class="Keyword">instance</span> strong <span class="Keyword">(</span>forget <span class="Type">'r</span><span class="Keyword">)</span>
 <span class="Keyword">let</span> first <span class="Keyword">(</span><span class="Constant">Forget</span> z<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span>z <span class="Operator">&lt;&lt;&lt;</span> fst<span class="Keyword">)</span>
 <span class="Keyword">let</span> second <span class="Keyword">(</span><span class="Constant">Forget</span> z<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Constant">Forget</span> <span class="Keyword">(</span>z <span class="Operator">&lt;&lt;&lt;</span> snd<span class="Keyword">)</span>

 <span class="Keyword">let</span> lens get set <span class="Operator">=</span>
 dimap <span class="Keyword">(</span>fork get id<span class="Keyword">)</span> <span class="Keyword">(</span>uncurry set<span class="Keyword">)</span> <span class="Operator">&lt;&lt;&lt;</span> first

 <span class="Keyword">let</span> view l <span class="Operator">=</span> remember <span class="Keyword">(</span>l <span class="Keyword">(</span><span class="Constant">Forget</span> id<span class="Keyword">))</span>
 <span class="Keyword">let</span> over f <span class="Operator">=</span> f
 <span class="Keyword">let</span> set l b <span class="Operator">=</span> over l <span class="Keyword">(</span>const b<span class="Keyword">)</span>

 <span class="Keyword">let</span> x <span class="Operator">^.</span> l <span class="Operator">=</span> view l x
 <span class="Keyword">let</span> l <span class="Operator">^</span><span class="Operator">~</span> f <span class="Operator">=</span> over l f

 <span class="Keyword">type</span> pair <span class="Type">'a</span> <span class="Type">'b</span> <span class="Operator">=</span> <span class="Constant">Pair</span> <span class="Keyword">of</span> <span class="Type">'a</span> <span class="Operator">*</span> <span class="Type">'b</span>
 <span class="Keyword">let</span> fst' <span class="Keyword">(</span><span class="Constant">Pair</span> <span class="Keyword">(</span>x<span class="Operator">,</span> <span class="Keyword">_</span><span class="Keyword">))</span> <span class="Operator">=</span> x
 <span class="Keyword">let</span> snd' <span class="Keyword">(</span><span class="Constant">Pair</span> <span class="Keyword">(</span><span class="Keyword">_</span><span class="Operator">,</span> x<span class="Keyword">))</span> <span class="Operator">=</span> x

 <span class="Keyword">let</span> first' x <span class="Operator">=</span> lens fst' <span class="Keyword">(fun</span> x <span class="Keyword">(</span><span class="Constant">Pair</span> <span class="Keyword">(</span><span class="Keyword">_</span><span class="Operator">,</span> y<span class="Keyword">))</span> <span class="Keyword">-&gt;</span> <span class="Constant">Pair</span> <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">))</span> x
 <span class="Keyword">let</span> second' x <span class="Operator">=</span> lens snd' <span class="Keyword">(fun</span> y <span class="Keyword">(</span><span class="Constant">Pair</span> <span class="Keyword">(</span>x<span class="Operator">,</span> <span class="Keyword">_</span><span class="Keyword">))</span> <span class="Keyword">-&gt;</span> <span class="Constant">Pair</span> <span class="Keyword">(</span>x<span class="Operator">,</span> y<span class="Keyword">))</span> x

 <span class="Keyword">type</span> proxy <span class="Type">'a</span> <span class="Operator">=</span> <span class="Constant">Proxy</span>

 <span class="Keyword">type</span> optic <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'s</span> <span class="Operator">&lt;-</span> <span class="Type">'p</span> <span class="Type">'a</span> <span class="Type">'a</span> <span class="Keyword">-&gt;</span> <span class="Type">'p</span> <span class="Type">'s</span> <span class="Type">'s</span>

 <span class="Keyword">class</span>
 <span class="Include">Amc</span>.row_cons <span class="Type">'r</span> <span class="Type">'k</span> <span class="Type">'t</span> <span class="Type">'n</span>
 <span class="Operator">=</span><span class="Operator">&gt;</span> has_lens <span class="Type">'r</span> <span class="Type">'k</span> <span class="Type">'t</span> <span class="Type">'n</span>
 <span class="Operator">|</span> <span class="Type">'k</span> <span class="Type">'n</span> <span class="Keyword">-&gt;</span> <span class="Type">'r</span> <span class="Type">'t</span>
 <span class="Keyword">begin</span>
 <span class="Keyword">val</span> rlens <span class="Operator">:</span> strong <span class="Type">'p</span> <span class="Operator">=</span><span class="Operator">&gt;</span> proxy <span class="Type">'k</span> <span class="Keyword">-&gt;</span> optic <span class="Type">'p</span> <span class="Type">'t</span> <span class="Type">'n</span>
 <span class="Keyword">end</span>

 <span class="Keyword">instance</span>
 <span class="Include">Amc</span>.known_string <span class="Type">'key</span>
 <span class="Operator">*</span> <span class="Include">Amc</span>.row_cons <span class="Type">'record</span> <span class="Type">'key</span> <span class="Type">'type</span> <span class="Type">'new</span>
 <span class="Operator">=</span><span class="Operator">&gt;</span> has_lens <span class="Type">'record</span> <span class="Type">'key</span> <span class="Type">'type</span> <span class="Type">'new</span>
 <span class="Keyword">begin</span>
 <span class="Keyword">let</span> rlens <span class="Keyword">_</span> <span class="Operator">=</span>
 <span class="Keyword">let</span> view r <span class="Operator">=</span>
 <span class="Keyword">let</span> <span class="Keyword">(</span>x<span class="Operator">,</span> <span class="Keyword">_</span><span class="Keyword">)</span> <span class="Operator">=</span> <span class="Include">Amc</span>.restrict_row <span class="Operator">@</span><span class="Type">'key</span> r
 x
 <span class="Keyword">let</span> set x r <span class="Operator">=</span>
 <span class="Keyword">let</span> <span class="Keyword">(</span><span class="Keyword">_</span><span class="Operator">,</span> r'<span class="Keyword">)</span> <span class="Operator">=</span> <span class="Include">Amc</span>.restrict_row <span class="Operator">@</span><span class="Type">'key</span> r
 <span class="Include">Amc</span>.extend_row <span class="Operator">@</span><span class="Type">'key</span> x r'
 lens view set
 <span class="Keyword">end</span>

 <span class="Keyword">let</span> r
 <span class="Operator">:</span> <span class="Keyword">forall</span> <span class="Type">'key</span> <span class="Keyword">-&gt;</span> <span class="Keyword">forall</span> <span class="Type">'record</span> <span class="Type">'type</span> <span class="Type">'new</span> <span class="Type">'p</span><span class="Operator">.</span>
 <span class="Include">Amc</span>.known_string <span class="Type">'key</span>
 <span class="Operator">*</span> has_lens <span class="Type">'record</span> <span class="Type">'key</span> <span class="Type">'type</span> <span class="Type">'new</span>
 <span class="Operator">*</span> strong <span class="Type">'p</span>
 <span class="Operator">=</span><span class="Operator">&gt;</span> optic <span class="Type">'p</span> <span class="Type">'type</span> <span class="Type">'new</span> <span class="Operator">=</span>
 <span class="Keyword">fun</span> x <span class="Keyword">-&gt;</span> rlens <span class="Operator">@</span><span class="Type">'record</span> <span class="Keyword">(</span><span class="Constant">Proxy</span> <span class="Operator">:</span> proxy <span class="Type">'key</span><span class="Keyword">)</span> x

 <span class="Keyword">let</span> succ <span class="Operator">=</span> <span class="Keyword">(</span><span class="Operator">+</span> <span class="Float">1</span><span class="Keyword">)</span>
 </pre>
 </body>
 </html>
 <!-- vim: set foldmethod=manual : -->
--- a/static/tasks.lisp
+++ b/static/tasks.lisp
@ -0,0 +1,26 @@
 (import urn/control/prompt ())

 (defun run-tasks (&tasks) ; 1
 (loop [(queue tasks)] ; 2
 [(empty? queue)] ; 2
 (call/p 'task (car queue)
 (lambda (k)
 (when (alive? k)
 (push-cdr! queue k)))) ; 2
 (recur (cdr queue))))

 (defun yield ()
 (abort-to-prompt 'task))

 (run-tasks
 (lambda ()
 (map (lambda (x)
 (print! $"loop 1: ~{x}")
 (yield))
 (range :from 1 :to 5)))
 (lambda ()
 (map (lambda (x)
 (print! $"loop 2: ~{x}")
 (yield))
 (range :from 1 :to 5))))

--- a/static/tasks.lisp.html
+++ b/static/tasks.lisp.html
@ -0,0 +1,126 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 <title>~/Projects/blag/static/tasks.lisp.html</title>
 <meta name="Generator" content="Vim/7.4">
 <meta name="plugin-version" content="vim7.4_v2">
 <meta name="syntax" content="lisp">
 <meta name="settings" content="use_css,pre_wrap,no_foldcolumn,expand_tabs,prevent_copy=t">
 <meta name="colorscheme" content="onedark">
 <style type="text/css">
 <!--
 pre { white-space: pre-wrap; font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 body { font-family: 'Iosevka','Iosevka Term', monospace; color: #ABB2BF; background-color: #282C34; }
 * { font-size: 1em; }
 input { border: none; margin: 0; padding: 0; font-family: 'Iosevka','Iosevka Term', monospace; }
 input[size='1'] { width: 1em; width: 1ch; }
 input[size='2'] { width: 2em; width: 2ch; }
 input[size='3'] { width: 3em; width: 3ch; }
 input[size='4'] { width: 4em; width: 4ch; }
 input[size='5'] { width: 5em; width: 5ch; }
 input[size='6'] { width: 6em; width: 6ch; }
 input[size='7'] { width: 7em; width: 7ch; }
 input[size='8'] { width: 8em; width: 8ch; }
 input[size='9'] { width: 9em; width: 9ch; }
 input[size='10'] { width: 10em; width: 10ch; }
 input[size='11'] { width: 11em; width: 11ch; }
 input[size='12'] { width: 12em; width: 12ch; }
 input[size='13'] { width: 13em; width: 13ch; }
 input[size='14'] { width: 14em; width: 14ch; }
 input[size='15'] { width: 15em; width: 15ch; }
 input[size='16'] { width: 16em; width: 16ch; }
 input[size='17'] { width: 17em; width: 17ch; }
 input[size='18'] { width: 18em; width: 18ch; }
 input[size='19'] { width: 19em; width: 19ch; }
 input[size='20'] { width: 20em; width: 20ch; }
 #oneCharWidth, #oneEmWidth, #oneInputWidth { padding: 0; margin: 0; position: absolute; left: -999999px; visibility: hidden; }
 .em5 input[size='1'] { width: 0.05em; } .em5 input[size='2'] { width: 0.1em; } .em5 input[size='3'] { width: 0.15em; } .em5 input[size='4'] { width: 0.2em; } .em5 input[size='5'] { width: 0.25em; } .em5 input[size='6'] { width: 0.3em; } .em5 input[size='7'] { width: 0.35em; } .em5 input[size='8'] { width: 0.4em; } .em5 input[size='9'] { width: 0.45em; } .em5 input[size='10'] { width: 0.5em; } .em5 input[size='11'] { width: 0.55em; } .em5 input[size='12'] { width: 0.6em; } .em5 input[size='13'] { width: 0.65em; } .em5 input[size='14'] { width: 0.7em; } .em5 input[size='15'] { width: 0.75em; } .em5 input[size='16'] { width: 0.8em; } .em5 input[size='17'] { width: 0.85em; } .em5 input[size='18'] { width: 0.9em; } .em5 input[size='19'] { width: 0.95em; } .em5 input[size='20'] { width: 1.0em; }
 .em10 input[size='1'] { width: 0.1em; } .em10 input[size='2'] { width: 0.2em; } .em10 input[size='3'] { width: 0.3em; } .em10 input[size='4'] { width: 0.4em; } .em10 input[size='5'] { width: 0.5em; } .em10 input[size='6'] { width: 0.6em; } .em10 input[size='7'] { width: 0.7em; } .em10 input[size='8'] { width: 0.8em; } .em10 input[size='9'] { width: 0.9em; } .em10 input[size='10'] { width: 1.0em; } .em10 input[size='11'] { width: 1.1em; } .em10 input[size='12'] { width: 1.2em; } .em10 input[size='13'] { width: 1.3em; } .em10 input[size='14'] { width: 1.4em; } .em10 input[size='15'] { width: 1.5em; } .em10 input[size='16'] { width: 1.6em; } .em10 input[size='17'] { width: 1.7em; } .em10 input[size='18'] { width: 1.8em; } .em10 input[size='19'] { width: 1.9em; } .em10 input[size='20'] { width: 2.0em; }
 .em15 input[size='1'] { width: 0.15em; } .em15 input[size='2'] { width: 0.3em; } .em15 input[size='3'] { width: 0.45em; } .em15 input[size='4'] { width: 0.6em; } .em15 input[size='5'] { width: 0.75em; } .em15 input[size='6'] { width: 0.9em; } .em15 input[size='7'] { width: 1.05em; } .em15 input[size='8'] { width: 1.2em; } .em15 input[size='9'] { width: 1.35em; } .em15 input[size='10'] { width: 1.5em; } .em15 input[size='11'] { width: 1.65em; } .em15 input[size='12'] { width: 1.8em; } .em15 input[size='13'] { width: 1.95em; } .em15 input[size='14'] { width: 2.1em; } .em15 input[size='15'] { width: 2.25em; } .em15 input[size='16'] { width: 2.4em; } .em15 input[size='17'] { width: 2.55em; } .em15 input[size='18'] { width: 2.7em; } .em15 input[size='19'] { width: 2.85em; } .em15 input[size='20'] { width: 3.0em; }
 .em20 input[size='1'] { width: 0.2em; } .em20 input[size='2'] { width: 0.4em; } .em20 input[size='3'] { width: 0.6em; } .em20 input[size='4'] { width: 0.8em; } .em20 input[size='5'] { width: 1.0em; } .em20 input[size='6'] { width: 1.2em; } .em20 input[size='7'] { width: 1.4em; } .em20 input[size='8'] { width: 1.6em; } .em20 input[size='9'] { width: 1.8em; } .em20 input[size='10'] { width: 2.0em; } .em20 input[size='11'] { width: 2.2em; } .em20 input[size='12'] { width: 2.4em; } .em20 input[size='13'] { width: 2.6em; } .em20 input[size='14'] { width: 2.8em; } .em20 input[size='15'] { width: 3.0em; } .em20 input[size='16'] { width: 3.2em; } .em20 input[size='17'] { width: 3.4em; } .em20 input[size='18'] { width: 3.6em; } .em20 input[size='19'] { width: 3.8em; } .em20 input[size='20'] { width: 4.0em; }
 .em25 input[size='1'] { width: 0.25em; } .em25 input[size='2'] { width: 0.5em; } .em25 input[size='3'] { width: 0.75em; } .em25 input[size='4'] { width: 1.0em; } .em25 input[size='5'] { width: 1.25em; } .em25 input[size='6'] { width: 1.5em; } .em25 input[size='7'] { width: 1.75em; } .em25 input[size='8'] { width: 2.0em; } .em25 input[size='9'] { width: 2.25em; } .em25 input[size='10'] { width: 2.5em; } .em25 input[size='11'] { width: 2.75em; } .em25 input[size='12'] { width: 3.0em; } .em25 input[size='13'] { width: 3.25em; } .em25 input[size='14'] { width: 3.5em; } .em25 input[size='15'] { width: 3.75em; } .em25 input[size='16'] { width: 4.0em; } .em25 input[size='17'] { width: 4.25em; } .em25 input[size='18'] { width: 4.5em; } .em25 input[size='19'] { width: 4.75em; } .em25 input[size='20'] { width: 5.0em; }
 .em30 input[size='1'] { width: 0.3em; } .em30 input[size='2'] { width: 0.6em; } .em30 input[size='3'] { width: 0.9em; } .em30 input[size='4'] { width: 1.2em; } .em30 input[size='5'] { width: 1.5em; } .em30 input[size='6'] { width: 1.8em; } .em30 input[size='7'] { width: 2.1em; } .em30 input[size='8'] { width: 2.4em; } .em30 input[size='9'] { width: 2.7em; } .em30 input[size='10'] { width: 3.0em; } .em30 input[size='11'] { width: 3.3em; } .em30 input[size='12'] { width: 3.6em; } .em30 input[size='13'] { width: 3.9em; } .em30 input[size='14'] { width: 4.2em; } .em30 input[size='15'] { width: 4.5em; } .em30 input[size='16'] { width: 4.8em; } .em30 input[size='17'] { width: 5.1em; } .em30 input[size='18'] { width: 5.4em; } .em30 input[size='19'] { width: 5.7em; } .em30 input[size='20'] { width: 6.0em; }
 .em35 input[size='1'] { width: 0.35em; } .em35 input[size='2'] { width: 0.7em; } .em35 input[size='3'] { width: 1.05em; } .em35 input[size='4'] { width: 1.4em; } .em35 input[size='5'] { width: 1.75em; } .em35 input[size='6'] { width: 2.1em; } .em35 input[size='7'] { width: 2.45em; } .em35 input[size='8'] { width: 2.8em; } .em35 input[size='9'] { width: 3.15em; } .em35 input[size='10'] { width: 3.5em; } .em35 input[size='11'] { width: 3.85em; } .em35 input[size='12'] { width: 4.2em; } .em35 input[size='13'] { width: 4.55em; } .em35 input[size='14'] { width: 4.9em; } .em35 input[size='15'] { width: 5.25em; } .em35 input[size='16'] { width: 5.6em; } .em35 input[size='17'] { width: 5.95em; } .em35 input[size='18'] { width: 6.3em; } .em35 input[size='19'] { width: 6.65em; } .em35 input[size='20'] { width: 7.0em; }
 .em40 input[size='1'] { width: 0.4em; } .em40 input[size='2'] { width: 0.8em; } .em40 input[size='3'] { width: 1.2em; } .em40 input[size='4'] { width: 1.6em; } .em40 input[size='5'] { width: 2.0em; } .em40 input[size='6'] { width: 2.4em; } .em40 input[size='7'] { width: 2.8em; } .em40 input[size='8'] { width: 3.2em; } .em40 input[size='9'] { width: 3.6em; } .em40 input[size='10'] { width: 4.0em; } .em40 input[size='11'] { width: 4.4em; } .em40 input[size='12'] { width: 4.8em; } .em40 input[size='13'] { width: 5.2em; } .em40 input[size='14'] { width: 5.6em; } .em40 input[size='15'] { width: 6.0em; } .em40 input[size='16'] { width: 6.4em; } .em40 input[size='17'] { width: 6.8em; } .em40 input[size='18'] { width: 7.2em; } .em40 input[size='19'] { width: 7.6em; } .em40 input[size='20'] { width: 8.0em; }
 .em45 input[size='1'] { width: 0.45em; } .em45 input[size='2'] { width: 0.9em; } .em45 input[size='3'] { width: 1.35em; } .em45 input[size='4'] { width: 1.8em; } .em45 input[size='5'] { width: 2.25em; } .em45 input[size='6'] { width: 2.7em; } .em45 input[size='7'] { width: 3.15em; } .em45 input[size='8'] { width: 3.6em; } .em45 input[size='9'] { width: 4.05em; } .em45 input[size='10'] { width: 4.5em; } .em45 input[size='11'] { width: 4.95em; } .em45 input[size='12'] { width: 5.4em; } .em45 input[size='13'] { width: 5.85em; } .em45 input[size='14'] { width: 6.3em; } .em45 input[size='15'] { width: 6.75em; } .em45 input[size='16'] { width: 7.2em; } .em45 input[size='17'] { width: 7.65em; } .em45 input[size='18'] { width: 8.1em; } .em45 input[size='19'] { width: 8.55em; } .em45 input[size='20'] { width: 9.0em; }
 .em50 input[size='1'] { width: 0.5em; } .em50 input[size='2'] { width: 1.0em; } .em50 input[size='3'] { width: 1.5em; } .em50 input[size='4'] { width: 2.0em; } .em50 input[size='5'] { width: 2.5em; } .em50 input[size='6'] { width: 3.0em; } .em50 input[size='7'] { width: 3.5em; } .em50 input[size='8'] { width: 4.0em; } .em50 input[size='9'] { width: 4.5em; } .em50 input[size='10'] { width: 5.0em; } .em50 input[size='11'] { width: 5.5em; } .em50 input[size='12'] { width: 6.0em; } .em50 input[size='13'] { width: 6.5em; } .em50 input[size='14'] { width: 7.0em; } .em50 input[size='15'] { width: 7.5em; } .em50 input[size='16'] { width: 8.0em; } .em50 input[size='17'] { width: 8.5em; } .em50 input[size='18'] { width: 9.0em; } .em50 input[size='19'] { width: 9.5em; } .em50 input[size='20'] { width: 10.0em; }
 .em55 input[size='1'] { width: 0.55em; } .em55 input[size='2'] { width: 1.1em; } .em55 input[size='3'] { width: 1.65em; } .em55 input[size='4'] { width: 2.2em; } .em55 input[size='5'] { width: 2.75em; } .em55 input[size='6'] { width: 3.3em; } .em55 input[size='7'] { width: 3.85em; } .em55 input[size='8'] { width: 4.4em; } .em55 input[size='9'] { width: 4.95em; } .em55 input[size='10'] { width: 5.5em; } .em55 input[size='11'] { width: 6.05em; } .em55 input[size='12'] { width: 6.6em; } .em55 input[size='13'] { width: 7.15em; } .em55 input[size='14'] { width: 7.7em; } .em55 input[size='15'] { width: 8.25em; } .em55 input[size='16'] { width: 8.8em; } .em55 input[size='17'] { width: 9.35em; } .em55 input[size='18'] { width: 9.9em; } .em55 input[size='19'] { width: 10.45em; } .em55 input[size='20'] { width: 11.0em; }
 .em60 input[size='1'] { width: 0.6em; } .em60 input[size='2'] { width: 1.2em; } .em60 input[size='3'] { width: 1.8em; } .em60 input[size='4'] { width: 2.4em; } .em60 input[size='5'] { width: 3.0em; } .em60 input[size='6'] { width: 3.6em; } .em60 input[size='7'] { width: 4.2em; } .em60 input[size='8'] { width: 4.8em; } .em60 input[size='9'] { width: 5.4em; } .em60 input[size='10'] { width: 6.0em; } .em60 input[size='11'] { width: 6.6em; } .em60 input[size='12'] { width: 7.2em; } .em60 input[size='13'] { width: 7.8em; } .em60 input[size='14'] { width: 8.4em; } .em60 input[size='15'] { width: 9.0em; } .em60 input[size='16'] { width: 9.6em; } .em60 input[size='17'] { width: 10.2em; } .em60 input[size='18'] { width: 10.8em; } .em60 input[size='19'] { width: 11.4em; } .em60 input[size='20'] { width: 12.0em; }
 .em65 input[size='1'] { width: 0.65em; } .em65 input[size='2'] { width: 1.3em; } .em65 input[size='3'] { width: 1.95em; } .em65 input[size='4'] { width: 2.6em; } .em65 input[size='5'] { width: 3.25em; } .em65 input[size='6'] { width: 3.9em; } .em65 input[size='7'] { width: 4.55em; } .em65 input[size='8'] { width: 5.2em; } .em65 input[size='9'] { width: 5.85em; } .em65 input[size='10'] { width: 6.5em; } .em65 input[size='11'] { width: 7.15em; } .em65 input[size='12'] { width: 7.8em; } .em65 input[size='13'] { width: 8.45em; } .em65 input[size='14'] { width: 9.1em; } .em65 input[size='15'] { width: 9.75em; } .em65 input[size='16'] { width: 10.4em; } .em65 input[size='17'] { width: 11.05em; } .em65 input[size='18'] { width: 11.7em; } .em65 input[size='19'] { width: 12.35em; } .em65 input[size='20'] { width: 13.0em; }
 .em70 input[size='1'] { width: 0.7em; } .em70 input[size='2'] { width: 1.4em; } .em70 input[size='3'] { width: 2.1em; } .em70 input[size='4'] { width: 2.8em; } .em70 input[size='5'] { width: 3.5em; } .em70 input[size='6'] { width: 4.2em; } .em70 input[size='7'] { width: 4.9em; } .em70 input[size='8'] { width: 5.6em; } .em70 input[size='9'] { width: 6.3em; } .em70 input[size='10'] { width: 7.0em; } .em70 input[size='11'] { width: 7.7em; } .em70 input[size='12'] { width: 8.4em; } .em70 input[size='13'] { width: 9.1em; } .em70 input[size='14'] { width: 9.8em; } .em70 input[size='15'] { width: 10.5em; } .em70 input[size='16'] { width: 11.2em; } .em70 input[size='17'] { width: 11.9em; } .em70 input[size='18'] { width: 12.6em; } .em70 input[size='19'] { width: 13.3em; } .em70 input[size='20'] { width: 14.0em; }
 .em75 input[size='1'] { width: 0.75em; } .em75 input[size='2'] { width: 1.5em; } .em75 input[size='3'] { width: 2.25em; } .em75 input[size='4'] { width: 3.0em; } .em75 input[size='5'] { width: 3.75em; } .em75 input[size='6'] { width: 4.5em; } .em75 input[size='7'] { width: 5.25em; } .em75 input[size='8'] { width: 6.0em; } .em75 input[size='9'] { width: 6.75em; } .em75 input[size='10'] { width: 7.5em; } .em75 input[size='11'] { width: 8.25em; } .em75 input[size='12'] { width: 9.0em; } .em75 input[size='13'] { width: 9.75em; } .em75 input[size='14'] { width: 10.5em; } .em75 input[size='15'] { width: 11.25em; } .em75 input[size='16'] { width: 12.0em; } .em75 input[size='17'] { width: 12.75em; } .em75 input[size='18'] { width: 13.5em; } .em75 input[size='19'] { width: 14.25em; } .em75 input[size='20'] { width: 15.0em; }
 .em80 input[size='1'] { width: 0.8em; } .em80 input[size='2'] { width: 1.6em; } .em80 input[size='3'] { width: 2.4em; } .em80 input[size='4'] { width: 3.2em; } .em80 input[size='5'] { width: 4.0em; } .em80 input[size='6'] { width: 4.8em; } .em80 input[size='7'] { width: 5.6em; } .em80 input[size='8'] { width: 6.4em; } .em80 input[size='9'] { width: 7.2em; } .em80 input[size='10'] { width: 8.0em; } .em80 input[size='11'] { width: 8.8em; } .em80 input[size='12'] { width: 9.6em; } .em80 input[size='13'] { width: 10.4em; } .em80 input[size='14'] { width: 11.2em; } .em80 input[size='15'] { width: 12.0em; } .em80 input[size='16'] { width: 12.8em; } .em80 input[size='17'] { width: 13.6em; } .em80 input[size='18'] { width: 14.4em; } .em80 input[size='19'] { width: 15.2em; } .em80 input[size='20'] { width: 16.0em; }
 .em85 input[size='1'] { width: 0.85em; } .em85 input[size='2'] { width: 1.7em; } .em85 input[size='3'] { width: 2.55em; } .em85 input[size='4'] { width: 3.4em; } .em85 input[size='5'] { width: 4.25em; } .em85 input[size='6'] { width: 5.1em; } .em85 input[size='7'] { width: 5.95em; } .em85 input[size='8'] { width: 6.8em; } .em85 input[size='9'] { width: 7.65em; } .em85 input[size='10'] { width: 8.5em; } .em85 input[size='11'] { width: 9.35em; } .em85 input[size='12'] { width: 10.2em; } .em85 input[size='13'] { width: 11.05em; } .em85 input[size='14'] { width: 11.9em; } .em85 input[size='15'] { width: 12.75em; } .em85 input[size='16'] { width: 13.6em; } .em85 input[size='17'] { width: 14.45em; } .em85 input[size='18'] { width: 15.3em; } .em85 input[size='19'] { width: 16.15em; } .em85 input[size='20'] { width: 17.0em; }
 .em90 input[size='1'] { width: 0.9em; } .em90 input[size='2'] { width: 1.8em; } .em90 input[size='3'] { width: 2.7em; } .em90 input[size='4'] { width: 3.6em; } .em90 input[size='5'] { width: 4.5em; } .em90 input[size='6'] { width: 5.4em; } .em90 input[size='7'] { width: 6.3em; } .em90 input[size='8'] { width: 7.2em; } .em90 input[size='9'] { width: 8.1em; } .em90 input[size='10'] { width: 9.0em; } .em90 input[size='11'] { width: 9.9em; } .em90 input[size='12'] { width: 10.8em; } .em90 input[size='13'] { width: 11.7em; } .em90 input[size='14'] { width: 12.6em; } .em90 input[size='15'] { width: 13.5em; } .em90 input[size='16'] { width: 14.4em; } .em90 input[size='17'] { width: 15.3em; } .em90 input[size='18'] { width: 16.2em; } .em90 input[size='19'] { width: 17.1em; } .em90 input[size='20'] { width: 18.0em; }
 .em95 input[size='1'] { width: 0.95em; } .em95 input[size='2'] { width: 1.9em; } .em95 input[size='3'] { width: 2.85em; } .em95 input[size='4'] { width: 3.8em; } .em95 input[size='5'] { width: 4.75em; } .em95 input[size='6'] { width: 5.7em; } .em95 input[size='7'] { width: 6.65em; } .em95 input[size='8'] { width: 7.6em; } .em95 input[size='9'] { width: 8.55em; } .em95 input[size='10'] { width: 9.5em; } .em95 input[size='11'] { width: 10.45em; } .em95 input[size='12'] { width: 11.4em; } .em95 input[size='13'] { width: 12.35em; } .em95 input[size='14'] { width: 13.3em; } .em95 input[size='15'] { width: 14.25em; } .em95 input[size='16'] { width: 15.2em; } .em95 input[size='17'] { width: 16.15em; } .em95 input[size='18'] { width: 17.1em; } .em95 input[size='19'] { width: 18.05em; } .em95 input[size='20'] { width: 19.0em; }
 .em100 input[size='1'] { width: 1.0em; } .em100 input[size='2'] { width: 2.0em; } .em100 input[size='3'] { width: 3.0em; } .em100 input[size='4'] { width: 4.0em; } .em100 input[size='5'] { width: 5.0em; } .em100 input[size='6'] { width: 6.0em; } .em100 input[size='7'] { width: 7.0em; } .em100 input[size='8'] { width: 8.0em; } .em100 input[size='9'] { width: 9.0em; } .em100 input[size='10'] { width: 10.0em; } .em100 input[size='11'] { width: 11.0em; } .em100 input[size='12'] { width: 12.0em; } .em100 input[size='13'] { width: 13.0em; } .em100 input[size='14'] { width: 14.0em; } .em100 input[size='15'] { width: 15.0em; } .em100 input[size='16'] { width: 16.0em; } .em100 input[size='17'] { width: 17.0em; } .em100 input[size='18'] { width: 18.0em; } .em100 input[size='19'] { width: 19.0em; } .em100 input[size='20'] { width: 20.0em; }
 input.Folded { cursor: default; }
 .Identifier { color: #E06C75; }
 .Number { color: #D19A66; }
 .Comment { color: #5C6370; }
 .Type { color: #E5C07B; }
 .Statement { color: #C678DD; }
 .String { color: #98C379; }
 -->
 </style>

 <script type='text/javascript'>
 <!--

 /* simulate a "ch" unit by asking the browser how big a zero character is */
 function FixCharWidth() {
 /* get the hidden element which gives the width of a single character */
 var goodWidth = document.getElementById("oneCharWidth").clientWidth;
 /* get all input elements, we'll filter on class later */
 var inputTags = document.getElementsByTagName("input");
 var ratio = 5;
 var inputWidth = document.getElementById("oneInputWidth").clientWidth;
 var emWidth = document.getElementById("oneEmWidth").clientWidth;
 if (inputWidth > goodWidth) {
 while (ratio < 100*goodWidth/emWidth && ratio < 100) {
 ratio += 5;
 }
 document.getElementById("vimCodeElement").className = "em"+ratio;
 }
 }

 -->
 </script>
 </head>
 <body onload='FixCharWidth();'>
 <!-- hidden divs used by javascript to get the width of a char -->
 <div id='oneCharWidth'>0</div>
 <div id='oneInputWidth'><input size='1' value='0'></div>
 <div id='oneEmWidth' style='width: 1em;'></div>
 <pre id='vimCodeElement'>
 (<span class="Statement">import</span> urn/control/prompt ())

 (<span class="Statement">defun</span> run-tasks (&amp;tasks) <span class="Comment">; 1</span>
 (<span class="Statement">loop</span> [(queue tasks)] <span class="Comment">; 2</span>
 [(empty? queue)] <span class="Comment">; 2</span>
 (call/p '<span class="Identifier">task</span> (<span class="Statement">car</span> queue)
 (<span class="Statement">lambda</span> (k)
 (<span class="Statement">when</span> (alive? k)
 (push-cdr! queue k)))) <span class="Comment">; 2</span>
 (recur (<span class="Statement">cdr</span> queue))))

 (<span class="Statement">defun</span> yield ()
 (abort-to-prompt '<span class="Identifier">task</span>))

 (run-tasks
 (<span class="Statement">lambda</span> ()
 (<span class="Statement">map</span> (<span class="Statement">lambda</span> (x)
 (<span class="Statement">print</span>! $<span class="String">&quot;loop 1: ~{x}&quot;</span>)
 (yield))
 (range <span class="Type">:from</span> <span class="Number">1</span> <span class="Type">:to</span> <span class="Number">5</span>)))
 (<span class="Statement">lambda</span> ()
 (<span class="Statement">map</span> (<span class="Statement">lambda</span> (x)
 (<span class="Statement">print</span>! $<span class="String">&quot;loop 2: ~{x}&quot;</span>)
 (yield))
 (range <span class="Type">:from</span> <span class="Number">1</span> <span class="Type">:to</span> <span class="Number">5</span>))))

 </pre>
 </body>
 </html>
 <!-- vim: set foldmethod=manual : -->
--- a/static/verify_error.png
+++ b/static/verify_error.png
--- a/static/verify_warn.png
+++ b/static/verify_warn.png
--- a/+ 8
+++ b/+ 8
@ -0,0 +1,8 @@
 #!/usr/bin/env bash

 if rg fastbuild pages/posts >/dev/null; then
 echo "posts still have fast build, remove and rebuild then repush"
 exit 1
 fi

 rsync .site/ "${SYNC_SERVER}:/var/www/abby.how/" -vuar0
--- a/syntax/amcprove.xml
+++ b/syntax/amcprove.xml
@ -0,0 +1,190 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!-- Kate syntax highlighting for Objective Caml version 4.02 in the standard and revised syntaxes, with Ocamldoc comments. -->

 <!DOCTYPE language SYSTEM "language.dtd"
 [
 <!-- Regular expresion constants: -->
 <!ENTITY LOWER "a-z\300-\326\330-\337"> <!-- Lowercase Latin-1 letters. -->
 <!ENTITY UPPER "A-Z\340-\366\370-\377"> <!-- Uppercase Latin-1 letters. -->
 <!ENTITY LETTER "&LOWER;&UPPER;"> <!-- All Latin-1 letters. -->
 <!ENTITY LIDENT "[&LOWER;_][&LETTER;0-9_']*"> <!-- Lowercase OCaml identifiers. -->
 <!ENTITY UIDENT "`?[&UPPER;][&LETTER;0-9_']*"> <!-- Uppercase OCaml identifiers. -->
 <!ENTITY IDENT "`?[&LETTER;][&LETTER;0-9_']*"> <!-- All OCaml identifiers. -->
 <!ENTITY ESC "(\\[ntbr'&quot;\\]|\\[0-9]{3}|\\x[0-9A-Fa-f]{2})"> <!-- OCaml character code escapes. -->
 <!ENTITY DEC "[0-9][0-9_]*"> <!-- Decimal digits with underscores. -->
 <!ENTITY INFIX "[:!#$%&amp;*+\\/<=>?@^|-~][:!#$%&amp;*+\\/<=>?@^|-~\.]*">
 ]>
 <language name="amc-prove"
 extensions="*.ml;*.mli"
 mimetype="text/x-amc-prove"
 section="Sources"
 version="6"
 priority="10"
 kateversion="2.4"
 author="Abigail Magalhães ([email protected])"
 license="LGPL" >

 <highlighting>
 <list name="Keywords">
 <item>forall</item>
 <item>fun</item>
 <item>function</item>
 <item>lazy</item>
 <item>match</item>
 <item>not</item>
 <item>yes</item>
 <item>probably</item>
 </list>

 <list name="Boolean Literals">
 <item>tt</item>
 <item>ff</item>
 </list>

 <list name="Pervasive Functions">
 </list>

 <list name="Pervasive Types">
 </list>

 <list name="Standard Library Modules">
 <item>Amc</item>
 </list>

 <contexts>

 <context name="Code" lineEndContext="#stay" attribute="Normal">

 <!-- ] and ]} close code samples in Ocamldoc, so -->
 <!-- nested [ ] and { } brackets have to be allowed for: -->
 <DetectChar char="[" context="Nested Code 1" attribute="Normal" />
 <DetectChar char="{" context="Nested Code 2" attribute="Normal" />


 <!-- Comments. -->
 <!-- A (** begins a special comment with Ocamldoc documentation markup. -->
 <Detect2Chars char="(" char1="*" context="Comment" attribute="Comment" beginRegion="comment" />

 <!-- Interpreter directives. -->
 <!-- (These are lines where the first symbol is a '#' followed by an identifier. -->
 <!-- Such lines could also be part of a method call split over two lines but -->
 <!-- it's unlikey anyone would code like that.) -->

 <!-- String, character and Camlp4 "quotation" constants. -->
 <!-- Note: If you must modify the pattern for characters be precise: -->
 <!-- single quotes have several meanings in Ocaml. -->
 <DetectChar char="&quot;" context="String" attribute="String" />
 <RegExpr String="'(&ESC;|[^'])'" context="#stay" attribute="Character" />


 <!-- Identifiers and keywords. -->
 <keyword String="Keywords" context="#stay" attribute="Keyword" />
 <keyword String="Pervasive Functions" context="#stay" attribute="Pervasive Functions" />
 <keyword String="Pervasive Types" context="#stay" attribute="Pervasive Types" />
 <keyword String="Standard Library Modules" context="#stay" attribute="Standard Library Modules" />
 <keyword String="Boolean Literals" context="#stay" attribute="Boolean Literals" />

 <RegExpr String="&LIDENT;" context="#stay" attribute="Lowercase Identifier" />
 <RegExpr String="&UIDENT;" context="#stay" attribute="Uppercase Identifier" />
 <RegExpr String="'&LIDENT;" context="#stay" attribute="Type Variable" />
 <RegExpr String="[\-!#\$%&amp;\*\+/&lt;=&gt;\?&#92;@\^\|~\.:]+"
 context="#stay" attribute="Infix Operator" />

 <!-- Numeric constants. -->
 <!-- Note that they may contain underscores. -->
 <RegExpr String="-?0[xX][0-9A-Fa-f_]+" context="#stay" attribute="Hexadecimal" />
 <RegExpr String="-?0[oO][0-7_]+" context="#stay" attribute="Octal" />
 <RegExpr String="-?0[bB][01_]+" context="#stay" attribute="Binary" />
 <RegExpr String="-?&DEC;(\.&DEC;([eE][-+]?&DEC;)?|[eE][-+]?&DEC;)" context="#stay" attribute="Float" />
 <RegExpr String="-?&DEC;" context="#stay" attribute="Decimal" />

 <IncludeRules context="Unmatched Closing Brackets" />
 </context>

 <context name="Nested Code 1" lineEndContext="#stay" attribute="Normal">
 <DetectChar char="]" context="#pop" attribute="Normal" />
 <IncludeRules context="Code" includeAttrib="true" />
 </context>

 <context name="Nested Code 2" lineEndContext="#stay" attribute="Normal">
 <DetectChar char="}" context="#pop" attribute="Normal" />
 <IncludeRules context="Code" includeAttrib="true" />
 </context>

 <context name="String" lineEndContext="#stay" attribute="String">
 <DetectChar char="&quot;" context="#pop" attribute="String" />
 <RegExpr String="&ESC;" context="#stay" attribute="Escaped Characters" />
 <!-- A backslash at the end of a line in a string indicates -->
 <!-- that the string will continue on the next line: -->
 <RegExpr String="\\$" context="#stay" attribute="Escaped Characters" />
 </context>

 <context name="Comment" lineEndContext="#stay" attribute="Comment">
 <Detect2Chars char="*" char1=")" context="#pop" attribute="Comment" endRegion="comment" />
 <!-- Support for nested comments: -->
 <Detect2Chars char="(" char1="*" context="Comment" attribute="Comment" beginRegion="comment" />
 <!-- Strings in Ocaml comments must be well-formed: -->
 <DetectChar char="&quot;" context="String in Comment" attribute="String in Comment" />
 </context>

 <context name="String in Comment" lineEndContext="#stay" attribute="String in Comment">
 <DetectChar char="&quot;" context="#pop" attribute="String in Comment" />
 <IncludeRules context="String" />
 </context>

 <!-- Unmatched closing brackets- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

 <context name="Unmatched Closing Brackets" lineEndContext="#stay" attribute="Normal">
 <Detect2Chars char="*" char1=")" context="#pop" attribute="Mismatched Brackets" />
 <Detect2Chars char="v" char1="}" context="#stay" attribute="Mismatched Brackets" />
 <Detect2Chars char="]" char1="}" context="#stay" attribute="Mismatched Brackets" />
 <Detect2Chars char="%" char1="}" context="#stay" attribute="Mismatched Brackets" />
 <DetectChar char="]" context="#stay" attribute="Mismatched Brackets" />
 <DetectChar char="}" context="#stay" attribute="Mismatched Brackets" />
 </context>
 </contexts>

 <itemDatas>
 <itemData name="Keyword" defStyleNum="dsKeyword" />
 <itemData name="Normal" defStyleNum="dsNormal" />
 <itemData name="Infix Operator" defStyleNum="dsOperator" />

 <itemData name="Uppercase Identifier" defStyleNum="dsDataType" italic="true" />
 <itemData name="Lowercase Identifier" defStyleNum="dsVariable" />

 <!-- Lowercase pervasive identifiers: -->
 <itemData name="Pervasive Functions" defStyleNum="dsFunction" />
 <itemData name="Pervasive Types" defStyleNum="dsDataType" />

 <!-- Type variables -->
 <itemData name="Type Variable" defStyleNum="dsSpecialString" />

 <!-- Uppercase pervasive identifiers: -->
 <itemData name="Standard Library Modules" defStyleNum="dsDataType" italic="true" />

 <itemData name="Boolean Literals" defStyleNum="dsConstant" />
 <itemData name="Decimal" defStyleNum="dsDecVal" />
 <itemData name="Hexadecimal" defStyleNum="dsBaseN" />
 <itemData name="Octal" defStyleNum="dsBaseN" />
 <itemData name="Binary" defStyleNum="dsBaseN" />
 <itemData name="Float" defStyleNum="dsFloat" />

 <itemData name="Character" defStyleNum="dsChar" />
 <itemData name="String" defStyleNum="dsString" />
 <itemData name="Escaped Characters" defStyleNum="dsChar" />

 <itemData name="Comment" defStyleNum="dsComment" />
 <itemData name="String in Comment" defStyleNum="dsComment" bold="true" />
 <itemData name="Mismatched Brackets" defStyleNum="dsError" />

 </itemDatas>
 </highlighting>

 <general>
 <keywords casesensitive="true" />
 <comments>
 <comment name="multiLine" start="(*" end="*)" region ="comment" />
 </comments>
 </general>
 </language>
 <!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
--- a/syntax/amulet.xml
+++ b/syntax/amulet.xml
@ -0,0 +1,222 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!-- Kate syntax highlighting for Objective Caml version 4.02 in the standard and revised syntaxes, with Ocamldoc comments. -->

 <!DOCTYPE language SYSTEM "language.dtd"
 [
 <!-- Regular expresion constants: -->
 <!ENTITY LOWER "a-z\300-\326\330-\337"> <!-- Lowercase Latin-1 letters. -->
 <!ENTITY UPPER "A-Z\340-\366\370-\377"> <!-- Uppercase Latin-1 letters. -->
 <!ENTITY LETTER "&LOWER;&UPPER;"> <!-- All Latin-1 letters. -->
 <!ENTITY LIDENT "[&LOWER;_][&LETTER;0-9_']*"> <!-- Lowercase OCaml identifiers. -->
 <!ENTITY UIDENT "`?[&UPPER;][&LETTER;0-9_']*"> <!-- Uppercase OCaml identifiers. -->
 <!ENTITY IDENT "`?[&LETTER;][&LETTER;0-9_']*"> <!-- All OCaml identifiers. -->
 <!ENTITY ESC "(\\[ntbr'&quot;\\]|\\[0-9]{3}|\\x[0-9A-Fa-f]{2})"> <!-- OCaml character code escapes. -->
 <!ENTITY DEC "[0-9][0-9_]*"> <!-- Decimal digits with underscores. -->
 <!ENTITY INFIX "[:!#$%&amp;*+\\/<=>?@^|-~][:!#$%&amp;*+\\/<=>?@^|-~\.]*">
 ]>
 <language name="Amulet"
 extensions="*.ml;*.mli"
 mimetype="text/x-amulet"
 section="Sources"
 version="6"
 priority="10"
 kateversion="2.4"
 author="Abigail Magalhães ([email protected])"
 license="LGPL" >

 <highlighting>
 <list name="Keywords">
 <item>as</item>
 <item>forall</item>
 <item>begin</item>
 <item>class</item>
 <item>else</item>
 <item>end</item>
 <item>external</item>
 <item>fun</item>
 <item>function</item>
 <item>if</item>
 <item>in</item>
 <item>lazy</item>
 <item>let</item>
 <item>match</item>
 <item>module</item>
 <item>of</item>
 <item>open</item>
 <item>then</item>
 <item>type</item>
 <item>val</item>
 <item>with</item>
 <item>instance</item>
 <item>rec</item>
 <item>import</item>
 <item>and</item>
 </list>

 <list name="Boolean Literals">
 <item>true</item>
 <item>false</item>
 </list>

 <list name="Pervasive Functions">
 </list>

 <list name="Pervasive Types">
 <item>string</item>
 <item>int</item>
 <item>float</item>
 <item>bool</item>
 <item>unit</item>
 <item>lazy</item>
 <item>list</item>
 <item>constraint</item>
 <item>ref</item>

 <item>known_string</item>
 <item>known_int</item>
 <item>row_cons</item>
 </list>

 <list name="Standard Library Modules">
 <item>Amc</item>
 </list>

 <contexts>

 <context name="Code" lineEndContext="#stay" attribute="Normal">

 <!-- ] and ]} close code samples in Ocamldoc, so -->
 <!-- nested [ ] and { } brackets have to be allowed for: -->
 <DetectChar char="[" context="Nested Code 1" attribute="Infix Operator" />
 <DetectChar char="{" context="Nested Code 2" attribute="Infix Operator" />


 <!-- Comments. -->
 <!-- A (** begins a special comment with Ocamldoc documentation markup. -->
 <Detect2Chars char="(" char1="*" context="Comment" attribute="Comment" beginRegion="comment" />

 <!-- Interpreter directives. -->
 <!-- (These are lines where the first symbol is a '#' followed by an identifier. -->
 <!-- Such lines could also be part of a method call split over two lines but -->
 <!-- it's unlikey anyone would code like that.) -->

 <!-- String, character and Camlp4 "quotation" constants. -->
 <!-- Note: If you must modify the pattern for characters be precise: -->
 <!-- single quotes have several meanings in Ocaml. -->
 <DetectChar char="&quot;" context="String" attribute="String" />
 <RegExpr String="'(&ESC;|[^'])'" context="#stay" attribute="Character" />


 <!-- Identifiers and keywords. -->
 <keyword String="Keywords" context="#stay" attribute="Keyword" />
 <keyword String="Pervasive Functions" context="#stay" attribute="Pervasive Functions" />
 <keyword String="Pervasive Types" context="#stay" attribute="Pervasive Types" />
 <keyword String="Standard Library Modules" context="#stay" attribute="Standard Library Modules" />
 <keyword String="Boolean Literals" context="#stay" attribute="Boolean Literals" />

 <RegExpr String="&LIDENT;" context="#stay" attribute="Lowercase Identifier" />
 <RegExpr String="&UIDENT;" context="#stay" attribute="Uppercase Identifier" />
 <RegExpr String="'&LIDENT;" context="#stay" attribute="Type Variable" />
 <RegExpr String="[\-!#\$%&amp;\*\+/&lt;=&gt;\?&#92;@\^\|~\.:]+"
 context="#stay" attribute="Infix Operator" />

 <RegExpr String="," context="#stay" attribute="Infix Operator" />

 <!-- Numeric constants. -->
 <!-- Note that they may contain underscores. -->
 <RegExpr String="-?0[xX][0-9A-Fa-f_]+" context="#stay" attribute="Hexadecimal" />
 <RegExpr String="-?0[oO][0-7_]+" context="#stay" attribute="Octal" />
 <RegExpr String="-?0[bB][01_]+" context="#stay" attribute="Binary" />
 <RegExpr String="-?&DEC;(\.&DEC;([eE][-+]?&DEC;)?|[eE][-+]?&DEC;)" context="#stay" attribute="Float" />
 <RegExpr String="-?&DEC;" context="#stay" attribute="Decimal" />

 <IncludeRules context="Unmatched Closing Brackets" />
 </context>

 <context name="Nested Code 1" lineEndContext="#stay" attribute="Normal">
 <DetectChar char="]" context="#pop" attribute="Infix Operator" />
 <IncludeRules context="Code" includeAttrib="true" />
 </context>

 <context name="Nested Code 2" lineEndContext="#stay" attribute="Normal">
 <DetectChar char="}" context="#pop" attribute="Infix Operator" />
 <IncludeRules context="Code" includeAttrib="true" />
 </context>

 <context name="String" lineEndContext="#stay" attribute="String">
 <DetectChar char="&quot;" context="#pop" attribute="String" />
 <RegExpr String="&ESC;" context="#stay" attribute="Escaped Characters" />
 <!-- A backslash at the end of a line in a string indicates -->
 <!-- that the string will continue on the next line: -->
 <RegExpr String="\\$" context="#stay" attribute="Escaped Characters" />
 </context>

 <context name="Comment" lineEndContext="#stay" attribute="Comment">
 <Detect2Chars char="*" char1=")" context="#pop" attribute="Comment" endRegion="comment" />
 <!-- Support for nested comments: -->
 <Detect2Chars char="(" char1="*" context="Comment" attribute="Comment" beginRegion="comment" />
 <!-- Strings in Ocaml comments must be well-formed: -->
 <DetectChar char="&quot;" context="String in Comment" attribute="String in Comment" />
 </context>

 <context name="String in Comment" lineEndContext="#stay" attribute="String in Comment">
 <DetectChar char="&quot;" context="#pop" attribute="String in Comment" />
 <IncludeRules context="String" />
 </context>

 <!-- Unmatched closing brackets- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

 <context name="Unmatched Closing Brackets" lineEndContext="#stay" attribute="Normal">
 <Detect2Chars char="*" char1=")" context="#pop" attribute="Mismatched Brackets" />
 <Detect2Chars char="v" char1="}" context="#stay" attribute="Mismatched Brackets" />
 <Detect2Chars char="]" char1="}" context="#stay" attribute="Mismatched Brackets" />
 <Detect2Chars char="%" char1="}" context="#stay" attribute="Mismatched Brackets" />
 <DetectChar char="]" context="#stay" attribute="Mismatched Brackets" />
 <DetectChar char="}" context="#stay" attribute="Mismatched Brackets" />
 </context>
 </contexts>

 <itemDatas>
 <itemData name="Keyword" defStyleNum="dsKeyword" />
 <itemData name="Normal" defStyleNum="dsNormal" />
 <itemData name="Infix Operator" defStyleNum="dsOperator" />

 <itemData name="Uppercase Identifier" defStyleNum="dsDataType" italic="true" />
 <itemData name="Lowercase Identifier" defStyleNum="dsVariable" />

 <!-- Lowercase pervasive identifiers: -->
 <itemData name="Pervasive Functions" defStyleNum="dsFunction" />
 <itemData name="Pervasive Types" defStyleNum="dsDataType" />

 <!-- Type variables -->
 <itemData name="Type Variable" defStyleNum="dsSpecialString" />

 <!-- Uppercase pervasive identifiers: -->
 <itemData name="Standard Library Modules" defStyleNum="dsDataType" italic="true" />

 <itemData name="Boolean Literals" defStyleNum="dsConstant" />
 <itemData name="Decimal" defStyleNum="dsDecVal" />
 <itemData name="Hexadecimal" defStyleNum="dsBaseN" />
 <itemData name="Octal" defStyleNum="dsBaseN" />
 <itemData name="Binary" defStyleNum="dsBaseN" />
 <itemData name="Float" defStyleNum="dsFloat" />

 <itemData name="Character" defStyleNum="dsChar" />
 <itemData name="String" defStyleNum="dsString" />
 <itemData name="Escaped Characters" defStyleNum="dsChar" />

 <itemData name="Comment" defStyleNum="dsComment" />
 <itemData name="String in Comment" defStyleNum="dsComment" bold="true" />
 <itemData name="Mismatched Brackets" defStyleNum="dsError" />

 </itemDatas>
 </highlighting>

 <general>
 <keywords casesensitive="true" />
 <comments>
 <comment name="multiLine" start="(*" end="*)" region ="comment" />
 </comments>
 </general>
 </language>
 <!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
--- a/templates/archive.html
+++ b/templates/archive.html
@ -0,0 +1,2 @@
 Here you can find all my previous posts:
 $partial("templates/post-list.html")$
--- a/templates/default.html
+++ b/templates/default.html
@ -0,0 +1,71 @@
 <!DOCTYPE html>
 <html>
 <head>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

 <title>$title$</title>

 <link rel="stylesheet" type="text/css" href="/css/default.css" />
 <link rel="stylesheet" type="text/css" href="/css/code.css" />
 <link rel="stylesheet" type="text/css" href="/css/katex.min.css" />

 <link rel="apple-touch-icon" sizes="180x180" href="/static/icon/apple-touch-icon.png">
 <link rel="icon" type="image/png" sizes="32x32" href="/static/icon/favicon-32x32.png">
 <link rel="icon" type="image/png" sizes="16x16" href="/static/icon/favicon-16x16.png">

 <link rel="alternate" type="application/rss+xml" href="/rss.xml" title="Blog feed for abby.how" />

 <meta property="og:type" content="website">
 <meta property="og:title" content="$title$">
 <meta name="title" content="$title$">

 <noscript>
 <style> .script { display: none } </style>
 </noscript>

 $if(fastbuild)$
 <style>
 .math {
 color: red;
 }
 </style>
 $endif$

 </head>

 <body>
 <a rel="me" href="https://functional.cafe/@hydraz" id=mastodon></a>
 <header>
 <div id="header">
 <div id="logo">
 <a href="/">Home</a>
 </div>
 <nav>
 <div id="navigation">
 <div class="nav-button"><a href="/contact.html">Contact</a></div>
 <div class="nav-button"><a href="/archive.html">Archive</a></div>
 <div class="nav-button"><a href="/oss.html">Licenses</a></div>
 <div class="nav-button"><a href="/feed.xml">RSS</a></div>
 </div>
 </nav>
 </div>
 </header>
 <div id="content">
 <h1>$title$</h1>

 $body$
 </div>
 <footer>
 <div id="footer" style="display: flex; justify-content: space-between;">
 <div>
 </div>
 <div>
 This wobsite is proudly powered by
 <a href="https://haskell.org">Haskell</a>.
 Hosted by <a href="https://shamiko.tmpim.pw">a demon</a>.
 </div>
 </div>
 </footer>
 </body>
 </html>
--- a/templates/post-list.html
+++ b/templates/post-list.html
@ -0,0 +1,10 @@
 <ul class="post-list">
 $for(posts)$
 <li>
 <div class="post-list-item">
 <a href="$url$">$title$</a>
 $date$
 </div>
 </li>
 $endfor$
 </ul>
--- a/templates/post.html
+++ b/templates/post.html
@ -0,0 +1,10 @@
 <div class="info">
 Posted on $date$
 $if(author)$
 by $author$
 $endif$
 </div>

 <article>
 $body$
 </article>
--- a/templates/tikz.tex
+++ b/templates/tikz.tex
@ -0,0 +1,20 @@
 \documentclass{article}
 \usepackage[pdftex,active,tightpage]{preview}
 \usepackage{amsmath}
 \usepackage{amssymb}
 \usepackage{tikz}
 \usetikzlibrary{matrix}
 \usetikzlibrary{calc}
 \usetikzlibrary{arrows.meta}
 \usepackage{xcolor}
 \usepackage{tgpagella}
 \definecolor{red}{RGB}{235, 77, 75}
 \definecolor{blue}{RGB}{9, 123, 227}

 \begin{document}
 \begin{preview}
 \begin{tikzpicture}[auto]
 $body$
 \end{tikzpicture}
 \end{preview}
 \end{document}