\documentclass{article}
\usepackage{fullpage,amsmath,amssymb,proof}

\newcommand{\cd}[1]{\texttt{#1}}
\newcommand{\mt}[1]{\mathsf{#1}}

\newcommand{\rc}{+ \hspace{-.075in} + \;}
\newcommand{\rcut}{\; \texttt{--} \;}
\newcommand{\rcutM}{\; \texttt{---} \;}

\begin{document}

\title{The Ur/Web Manual}
\author{Adam Chlipala}

\maketitle

\section{Ur Syntax}

In this section, we describe the syntax of Ur, deferring to a later section discussion of most of the syntax specific to SQL and XML.  The sole exceptions are the declaration forms for tables, sequences, and cookies.

\subsection{Lexical Conventions}

We give the Ur language definition in \LaTeX $\;$ math mode, since that is prettier than monospaced ASCII.  The corresponding ASCII syntax can be read off directly.  Here is the key for mapping math symbols to ASCII character sequences.

\begin{center}
  \begin{tabular}{rl}
    \textbf{\LaTeX} & \textbf{ASCII} \\
    $\to$ & \cd{->} \\
    $\times$ & \cd{*} \\
    $\lambda$ & \cd{fn} \\
    $\Rightarrow$ & \cd{=>} \\
    $\neq$ & \cd{<>} \\
    $\leq$ & \cd{<=} \\
    $\geq$ & \cd{>=} \\
    \\
    $x$ & Normal textual identifier, not beginning with an uppercase letter \\
    $X$ & Normal textual identifier, beginning with an uppercase letter \\
  \end{tabular}
\end{center}

We often write syntax like $e^*$ to indicate zero or more copies of $e$, $e^+$ to indicate one or more copies, and $e,^*$ and $e,^+$ to indicate multiple copies separated by commas.  Another separator may be used in place of a comma.  The $e$ term may be surrounded by parentheses to indicate grouping; those parentheses should not be included in the actual ASCII.

We write $\ell$ for literals of the primitive types, for the most part following C conventions.  There are $\mt{int}$, $\mt{float}$, and $\mt{string}$ literals.

This version of the manual doesn't include operator precedences; see \texttt{src/urweb.grm} for that.

\subsection{Core Syntax}

\emph{Kinds} classify types and other compile-time-only entities.  Each kind in the grammar is listed with a description of the sort of data it classifies.
$$\begin{array}{rrcll}
  \textrm{Kinds} & \kappa &::=& \mt{Type} & \textrm{proper types} \\
  &&& \mt{Unit} & \textrm{the trivial constructor} \\
  &&& \mt{Name} & \textrm{field names} \\
  &&& \kappa \to \kappa & \textrm{type-level functions} \\
  &&& \{\kappa\} & \textrm{type-level records} \\
  &&& (\kappa\times^+) & \textrm{type-level tuples} \\
  &&& \_\_ & \textrm{wildcard} \\
  &&& (\kappa) & \textrm{explicit precedence} \\
\end{array}$$

Ur supports several different notions of functions that take types as arguments.  These arguments can be either implicit, causing them to be inferred at use sites; or explicit, forcing them to be specified manually at use sites.  There is a common explicitness annotation convention applied at the definitions of and in the types of such functions.
$$\begin{array}{rrcll}
  \textrm{Explicitness} & ? &::=& :: & \textrm{explicit} \\
  &&& \; ::: & \textrm{implicit}
\end{array}$$

\emph{Constructors} are the main class of compile-time-only data.  They include proper types and are classified by kinds.
$$\begin{array}{rrcll}
  \textrm{Constructors} & c, \tau &::=& (c) :: \kappa & \textrm{kind annotation} \\
  &&& \hat{x} & \textrm{constructor variable} \\
  \\
  &&& \tau \to \tau & \textrm{function type} \\
  &&& x \; ? \; \kappa \to \tau & \textrm{polymorphic function type} \\
  &&& \$ c & \textrm{record type} \\
  \\
  &&& c \; c & \textrm{type-level function application} \\
  &&& \lambda x \; :: \; \kappa \Rightarrow c & \textrm{type-level function abstraction} \\
  \\
  &&& () & \textrm{type-level unit} \\
  &&& \#X & \textrm{field name} \\
  \\
  &&& [(c = c)^*] & \textrm{known-length type-level record} \\
  &&& c \rc c & \textrm{type-level record concatenation} \\
  &&& \mt{fold} & \textrm{type-level record fold} \\
  \\
  &&& (c^+) & \textrm{type-level tuple} \\
  &&& c.n & \textrm{type-level tuple projection ($n \in \mathbb N^+$)} \\
  \\
  &&& \lambda [c \sim c] \Rightarrow c & \textrm{guarded constructor} \\
  \\
  &&& \_ :: \kappa & \textrm{wildcard} \\
  &&& (c) & \textrm{explicit precedence} \\
  \\
  \textrm{Qualified uncapitalized variables} & \hat{x} &::=& x & \textrm{not from a module} \\
  &&& M.x & \textrm{projection from a module} \\
\end{array}$$

Modules of the module system are described by \emph{signatures}.
$$\begin{array}{rrcll}
  \textrm{Signatures} & S &::=& \mt{sig} \; s^* \; \mt{end} & \textrm{constant} \\
  &&& X & \textrm{variable} \\
  &&& \mt{functor}(X : S) : S & \textrm{functor} \\
  &&& S \; \mt{where} \; \mt{con} \; x = c & \textrm{concretizing an abstract constructor} \\
  &&& M.X & \textrm{projection from a module} \\
  \\
  \textrm{Signature items} & s &::=& \mt{con} \; x :: \kappa & \textrm{abstract constructor} \\
  &&& \mt{con} \; x :: \kappa = c & \textrm{concrete constructor} \\
  &&& \mt{datatype} \; x \; x^* = dc\mid^+ & \textrm{algebraic datatype definition} \\
  &&& \mt{datatype} \; x = \mt{datatype} \; M.x & \textrm{algebraic datatype import} \\
  &&& \mt{val} \; x : \tau & \textrm{value} \\
  &&& \mt{structure} \; X : S & \textrm{sub-module} \\
  &&& \mt{signature} \; X = S & \textrm{sub-signature} \\
  &&& \mt{include} \; S & \textrm{signature inclusion} \\
  &&& \mt{constraint} \; c \sim c & \textrm{record disjointness constraint} \\
  &&& \mt{class} \; x & \textrm{abstract type class} \\
  &&& \mt{class} \; x = c & \textrm{concrete type class} \\
  \\
  \textrm{Datatype constructors} & dc &::=& X & \textrm{nullary constructor} \\
  &&& X \; \mt{of} \; \tau & \textrm{unary constructor} \\
\end{array}$$

\emph{Patterns} are used to describe structural conditions on expressions, such that expressions may be tested against patterns, generating assignments to pattern variables if successful.
$$\begin{array}{rrcll}
  \textrm{Patterns} & p &::=& \_ & \textrm{wildcard} \\
  &&& x & \textrm{variable} \\
  &&& \ell & \textrm{constant} \\
  &&& \hat{X} & \textrm{nullary constructor} \\
  &&& \hat{X} \; p & \textrm{unary constructor} \\
  &&& \{(x = p,)^*\} & \textrm{rigid record pattern} \\
  &&& \{(x = p,)^+, \ldots\} & \textrm{flexible record pattern} \\
  &&& (p) & \textrm{explicit precedence} \\
  \\
  \textrm{Qualified capitalized variables} & \hat{X} &::=& X & \textrm{not from a module} \\
  &&& M.X & \textrm{projection from a module} \\
\end{array}$$

\emph{Expressions} are the main run-time entities, corresponding to both ``expressions'' and ``statements'' in mainstream imperative languages.
$$\begin{array}{rrcll}
  \textrm{Expressions} & e &::=& e : \tau & \textrm{type annotation} \\
  &&& \hat{x} & \textrm{variable} \\
  &&& \hat{X} & \textrm{datatype constructor} \\
  &&& \ell & \textrm{constant} \\
  \\
  &&& e \; e & \textrm{function application} \\
  &&& \lambda x : \tau \Rightarrow e & \textrm{function abstraction} \\
  &&& e [c] & \textrm{polymorphic function application} \\
  &&& \lambda x \; ? \; \kappa \Rightarrow e & \textrm{polymorphic function abstraction} \\
  \\
  &&& \{(c = e,)^*\} & \textrm{known-length record} \\
  &&& e.c & \textrm{record field projection} \\
  &&& e \rc e & \textrm{record concatenation} \\
  &&& e \rcut c & \textrm{removal of a single record field} \\
  &&& e \rcutM c & \textrm{removal of multiple record fields} \\
  &&& \mt{fold} & \textrm{fold over fields of a type-level record} \\
  \\
  &&& \mt{let} \; ed^* \; \mt{in} \; e \; \mt{end} & \textrm{local definitions} \\
  \\
  &&& \mt{case} \; e \; \mt{of} \; (p \Rightarrow e|)^+ & \textrm{pattern matching} \\
  \\
  &&& \lambda [c \sim c] \Rightarrow e & \textrm{guarded expression} \\
  \\
  &&& \_ & \textrm{wildcard} \\
  &&& (e) & \textrm{explicit precedence} \\
  \\
  \textrm{Local declarations} & ed &::=& \cd{val} \; x : \tau = e & \textrm{non-recursive value} \\
  &&& \cd{val} \; \cd{rec} \; (x : \tau = e \; \cd{and})^+ & \textrm{mutually-recursive values} \\
\end{array}$$

\emph{Declarations} primarily bring new symbols into context.
$$\begin{array}{rrcll}
  \textrm{Declarations} & d &::=& \mt{con} \; x :: \kappa = c & \textrm{constructor synonym} \\
  &&& \mt{datatype} \; x \; x^* = dc\mid^+ & \textrm{algebraic datatype definition} \\
  &&& \mt{datatype} \; x = \mt{datatype} \; M.x & \textrm{algebraic datatype import} \\
  &&& \mt{val} \; x : \tau = e & \textrm{value} \\
  &&& \mt{val} \; \cd{rec} \; (x : \tau = e \; \mt{and})^+ & \textrm{mutually-recursive values} \\
  &&& \mt{structure} \; X : S = M & \textrm{module definition} \\
  &&& \mt{signature} \; X = S & \textrm{signature definition} \\
  &&& \mt{open} \; M & \textrm{module inclusion} \\
  &&& \mt{constraint} \; c \sim c & \textrm{record disjointness constraint} \\
  &&& \mt{open} \; \mt{constraints} \; M & \textrm{inclusion of just the constraints from a module} \\
  &&& \mt{table} \; x : c & \textrm{SQL table} \\
  &&& \mt{sequence} \; x & \textrm{SQL sequence} \\
  &&& \mt{class} \; x = c & \textrm{concrete type class} \\
  &&& \mt{cookie} \; x : \tau & \textrm{HTTP cookie} \\
  \\
  \textrm{Modules} & M &::=& \mt{struct} \; d^* \; \mt{end} & \textrm{constant} \\
  &&& X & \textrm{variable} \\
  &&& M.X & \textrm{projection} \\
  &&& M(M) & \textrm{functor application} \\
  &&& \mt{functor}(X : S) : S = M & \textrm{functor abstraction} \\
\end{array}$$

There are two kinds of Ur files.  A file named $M\texttt{.ur}$ is an \emph{implementation file}, and it should contain a sequence of declarations $d^*$.  A file named $M\texttt{.urs}$ is an \emph{interface file}; it must always have a matching $M\texttt{.ur}$ and should contain a sequence of signature items $s^*$.  When both files are present, the overall effect is the same as a monolithic declaration $\mt{structure} \; M : \mt{sig} \; s^* \; \mt{end} = \mt{struct} \; d^* \; \mt{end}$.  When no interface file is included, the overall effect is similar, with a signature for module $M$ being inferred rather than just checked against an interface.

\subsection{Shorthands}

There are a variety of derived syntactic forms that elaborate into the core syntax from the last subsection.  We will present the additional forms roughly following the order in which we presented the constructs that they elaborate into.

In many contexts where record fields are expected, like in a projection $e.c$, a constant field may be written as simply $X$, rather than $\#X$.

A record type may be written $\{(c = c,)^*\}$, which elaborates to $\$[(c = c,)^*]$.

A tuple type $(\tau_1, \ldots, \tau_n)$ expands to a record type $\{1 = \tau_1, \ldots, n = \tau_n\}$, with natural numbers as field names.  A tuple pattern $(p_1, \ldots, p_n)$ expands to a rigid record pattern $\{1 = p_1, \ldots, n = p_n\}$.  Positive natural numbers may be used in most places where field names would be allowed.

In general, several adjacent $\lambda$ forms may be combined into one, and kind and type annotations may be omitted, in which case they are implicitly included as wildcards.  More formally, for constructor-level abstractions, we can define a new non-terminal $b ::= x \mid (x :: \kappa) \mid [c \sim c]$ and allow composite abstractions of the form $\lambda b^+ \Rightarrow c$, elaborating into the obvious sequence of one core $\lambda$ per element of $b^+$.  

For any signature item or declaration that defines some entity to be equal to $A$ with classification annotation $B$ (e.g., $\mt{val} \; x : B = A$), $B$ and the preceding colon (or similar punctuation) may be omitted, in which case it is filled in as a wildcard.

A signature item or declaration $\mt{type} \; x$ or $\mt{type} \; x = \tau$ is elaborated into $\mt{con} \; x :: \mt{Type}$ or $\mt{con} \; x :: \mt{Type} = \tau$, respectively.

A signature item or declaration $\mt{class} \; x = \lambda y :: \mt{Type} \Rightarrow c$ may be abbreviated $\mt{class} \; x \; y = c$.

Handling of implicit and explicit constructor arguments may be tweaked with some prefixes to variable references.  An expression $@x$ is a version of $x$ where all implicit constructor arguments have been made explicit.  An expression $@@x$ achieves the same effect, additionally halting automatic resolution of type class instances.  The same syntax works for variables projected out of modules and for capitalized variables (datatype constructors).

At the expression level, an analogue is available of the composite $\lambda$ form for constructors.  We define the language of binders as $b ::= x \mid (x : \tau) \mid (x \; ? \; \kappa) \mid [c \sim c]$.  A lone variable $x$ as a binder stands for an expression variable of unspecified type.

A $\mt{val}$ or $\mt{val} \; \mt{rec}$ declaration may include expression binders before the equal sign, following the binder grammar from the last paragraph.  Such declarations are elaborated into versions that add additional $\lambda$s to the fronts of the righthand sides, as appropriate.  The keyword $\mt{fun}$ is a synonym for $\mt{val} \; \mt{rec}$.

A signature item $\mt{functor} \; X_1 \; (X_2 : S_1) : S_2$ is elaborated into $\mt{structure} \; X_1 : \mt{functor}(X_2 : S_1) : S_2$.  A declaration $\mt{functor} \; X_1 \; (X_2 : S_1) : S_2 = M$ is elaborated into $\mt{structure} \; X_1 : \mt{functor}(X_2 : S_1) : S_2 = \mt{functor}(X_2 : S_1) : S_2 = M$.

A declaration $\mt{table} \; x : \{(c = c,)^*\}$ is elaborated into $\mt{table} \; x : [(c = c,)^*]$

The syntax $\mt{where} \; \mt{type}$ is an alternate form of $\mt{where} \; \mt{con}$.

The syntax $\mt{if} \; e \; \mt{then} \; e_1 \; \mt{else} \; e_2$ expands to $\mt{case} \; e \; \mt{of} \; \mt{Basis}.\mt{True} \Rightarrow e_1 \mid \mt{Basis}.\mt{False} \Rightarrow e_2$.

There are infix operator syntaxes for a number of functions defined in the $\mt{Basis}$ module.  There is $=$ for $\mt{eq}$, $\neq$ for $\mt{neq}$, $-$ for $\mt{neg}$ (as a prefix operator) and $\mt{minus}$, $+$ for $\mt{plus}$, $\times$ for $\mt{times}$, $/$ for $\mt{div}$, $\%$ for $\mt{mod}$, $<$ for $\mt{lt}$, $\leq$ for $\mt{le}$, $>$ for $\mt{gt}$, and $\geq$ for $\mt{ge}$.

A signature item $\mt{table} \; x : c$ is shorthand for $\mt{val} \; x : \mt{Basis}.\mt{sql\_table} \; c$.  $\mt{sequence} \; x$ is short for $\mt{val} \; x : \mt{Basis}.\mt{sql\_sequence}$, and $\mt{cookie} \; x : \tau$ is shorthand for $\mt{val} \; x : \mt{Basis}.\mt{http\_cookie} \; \tau$.


\section{Static Semantics}

In this section, we give a declarative presentation of Ur's typing rules and related judgments.  Inference is the subject of the next section; here, we assume that an oracle has filled in all wildcards with concrete values.

Since there is significant mutual recursion among the judgments, we introduce them all before beginning to give rules.  We use the same variety of contexts throughout this section, implicitly introducing new sorts of context entries as needed.
\begin{itemize}
\item $\Gamma \vdash c :: \kappa$ assigns a kind to a constructor in a context.
\item $\Gamma \vdash c \sim c$ proves the disjointness of two record constructors; that is, that they share no field names.  We overload the judgment to apply to pairs of field names as well.
\item $\Gamma \vdash c \hookrightarrow \overline{c}$ proves that record constructor $c$ decomposes into set $\overline{c}$ of field names and record constructors.
\item $\Gamma \vdash c \equiv c$ proves the computational equivalence of two constructors.  This is often called a \emph{definitional equality} in the world of type theory.
\item $\Gamma \vdash e : \tau$ is a standard typing judgment.
\item $\Gamma \vdash M : S$ is the module signature checking judgment.
\item $\mt{proj}(M, S, V)$ is a partial function for projecting a signature item from a signature $S$, given the module $M$ that we project from.  $V$ may be $\mt{con} \; x$, $\mt{val} \; x$, $\mt{signature} \; X$, or $\mt{structure} \; X$.  The parameter $M$ is needed because the projected signature item may refer to other items of $S$.
\end{itemize}

\subsection{Kinding}

$$\infer{\Gamma \vdash (c) :: \kappa :: \kappa}{
  \Gamma \vdash c :: \kappa
}
\quad \infer{\Gamma \vdash x :: \kappa}{
  x :: \kappa \in \Gamma
}
\quad \infer{\Gamma \vdash x :: \kappa}{
  x :: \kappa = c \in \Gamma
}$$

$$\infer{\Gamma \vdash M.x :: \kappa}{
  \Gamma \vdash M : S
  & \mt{proj}(M, S, \mt{con} \; x) = \kappa
}
\quad \infer{\Gamma \vdash M.x :: \kappa}{
  \Gamma \vdash M : S
  & \mt{proj}(M, S, \mt{con} \; x) = (\kappa, c)
}$$

$$\infer{\Gamma \vdash \tau_1 \to \tau_2 :: \mt{Type}}{
  \Gamma \vdash \tau_1 :: \mt{Type}
  & \Gamma \vdash \tau_2 :: \mt{Type}
}
\quad \infer{\Gamma \vdash x \; ? \: \kappa \to \tau :: \mt{Type}}{
  \Gamma, x :: \kappa \vdash \tau :: \mt{Type}
}
\quad \infer{\Gamma \vdash \$c :: \mt{Type}}{
  \Gamma \vdash c :: \{\mt{Type}\}
}$$

$$\infer{\Gamma \vdash c_1 \; c_2 :: \kappa_2}{
  \Gamma \vdash c_1 :: \kappa_1 \to \kappa_2
  & \Gamma \vdash c_2 :: \kappa_1
}
\quad \infer{\Gamma \vdash \lambda x \; :: \; \kappa_1 \Rightarrow c :: \kappa_1 \to \kappa_2}{
  \Gamma, x :: \kappa_1 \vdash c :: \kappa_2
}$$

$$\infer{\Gamma \vdash () :: \mt{Unit}}{}
\quad \infer{\Gamma \vdash \#X :: \mt{Name}}{}$$

$$\infer{\Gamma \vdash [\overline{c_i = c'_i}] :: \{\kappa\}}{
  \forall i: \Gamma \vdash c_i : \mt{Name}
  & \Gamma \vdash c'_i :: \kappa
  & \forall i \neq j: \Gamma \vdash c_i \sim c_j
}
\quad \infer{\Gamma \vdash c_1 \rc c_2 :: \{\kappa\}}{
  \Gamma \vdash c_1 :: \{\kappa\}
  & \Gamma \vdash c_2 :: \{\kappa\}
  & \Gamma \vdash c_1 \sim c_2
}$$

$$\infer{\Gamma \vdash \mt{fold} :: ((\mt{Name} \to \kappa_1 \to \kappa_2 \to \kappa_2) \to \kappa_2 \to \{\kappa_1\} \to \kappa_2}{}$$

$$\infer{\Gamma \vdash (\overline c) :: (k_1 \times \ldots \times k_n)}{
  \forall i: \Gamma \vdash c_i :: k_i
}
\quad \infer{\Gamma \vdash c.i :: k_i}{
  \Gamma \vdash c :: (k_1 \times \ldots \times k_n)
}$$

$$\infer{\Gamma \vdash \lambda [c_1 \sim c_2] \Rightarrow c :: \kappa}{
  \Gamma \vdash c_1 :: \{\kappa'\}
  & \Gamma \vdash c_2 :: \{\kappa'\}
  & \Gamma, c_1 \sim c_2 \vdash c :: \kappa
}$$

\end{document}