Changes in doc/papers/general/Paper.tex [5ff188f:43bbdf3]

File:

• doc/papers/general/Paper.tex (modified) (16 diffs)

doc/papers/general/Paper.tex

@@ -39 +39 @@
 \newcommand{\TODO}[1]{\textbf{TODO}: {\itshape #1}} % TODO included
 %\newcommand{\TODO}[1]{} % TODO elided
+
 % Default underscore is too low and wide. Cannot use lstlisting "literate" as replacing underscore
-% removes it as a variable-name character so keyworks in variables are highlighted
-\DeclareTextCommandDefault{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}
+% removes it as a variable-name character so keywords in variables are highlighted. MUST APPEAR
+% AFTER HYPERREF.
+%\DeclareTextCommandDefault{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}
+\renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
 
 \makeatletter
@@ -49 +52 @@
 \setlength{\parindentlnth}{\parindent}
 
+\newcommand{\LstKeywordStyle}[1]{{\lst@basicstyle{\lst@keywordstyle{#1}}}}
+\newcommand{\LstCommentStyle}[1]{{\lst@basicstyle{\lst@commentstyle{#1}}}}
+
 \newlength{\gcolumnposn}                                % temporary hack because lstlisting does not handle tabs correctly
 \newlength{\columnposn}
 \setlength{\gcolumnposn}{2.75in}
 \setlength{\columnposn}{\gcolumnposn}
-\newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@commentstyle{#2}}}
+\newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@basicstyle{\LstCommentStyle{#2}}}}
 \newcommand{\CRT}{\global\columnposn=\gcolumnposn}
+
+% Denote newterms in particular font and index them without particular font and in lowercase, e.g., \newterm{abc}.
+% The option parameter provides an index term different from the new term, e.g., \newterm[\texttt{abc}]{abc}
+% The star version does not lowercase the index information, e.g., \newterm*{IBM}.
+\newcommand{\newtermFontInline}{\emph}
+\newcommand{\newterm}{\@ifstar\@snewterm\@newterm}
+\newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
+\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
 
 % Latin abbreviation
 \newcommand{\abbrevFont}{\textit}       % set empty for no italics
+\newcommand{\EG}{\abbrevFont{e}.\abbrevFont{g}.}
 \newcommand*{\eg}{%
-        \@ifnextchar{,}{\abbrevFont{e}.\abbrevFont{g}.}%
-                {\@ifnextchar{:}{\abbrevFont{e}.\abbrevFont{g}.}%
-                        {\abbrevFont{e}.\abbrevFont{g}.,\xspace}}%
+        \@ifnextchar{,}{\EG}%
+                {\@ifnextchar{:}{\EG}%
+                        {\EG,\xspace}}%
 }%
+\newcommand{\IE}{\abbrevFont{i}.\abbrevFont{e}.}
 \newcommand*{\ie}{%
-        \@ifnextchar{,}{\abbrevFont{i}.\abbrevFont{e}.}%
-                {\@ifnextchar{:}{\abbrevFont{i}.\abbrevFont{e}.}%
-                        {\abbrevFont{i}.\abbrevFont{e}.,\xspace}}%
+        \@ifnextchar{,}{\IE}%
+                {\@ifnextchar{:}{\IE}%
+                        {\IE,\xspace}}%
 }%
+\newcommand{\ETC}{\abbrevFont{etc}}
 \newcommand*{\etc}{%
-        \@ifnextchar{.}{\abbrevFont{etc}}%
-        {\abbrevFont{etc}.\xspace}%
+        \@ifnextchar{.}{\ETC}%
+        {\ETC\xspace}%
 }%
-\newcommand{\etal}{%
-        \@ifnextchar{.}{\abbrevFont{et~al}}%
-                {\abbrevFont{et al}.\xspace}%
+\newcommand{\ETAL}{\abbrevFont{et}\hspace{2pt}\abbrevFont{al}}
+\newcommand*{\etal}{%
+        \@ifnextchar{.}{\protect\ETAL}%
+                {\abbrevFont{\protect\ETAL}.\xspace}%
+}%
+\newcommand{\VIZ}{\abbrevFont{viz}}
+\newcommand*{\viz}{%
+        \@ifnextchar{.}{\VIZ}%
+                {\abbrevFont{\VIZ}.\xspace}%
 }%
 \makeatother
@@ -80 +103 @@
 % CFA programming language, based on ANSI C (with some gcc additions)
 \lstdefinelanguage{CFA}[ANSI]{C}{
-        morekeywords={_Alignas,_Alignof,__alignof,__alignof__,asm,__asm,__asm__,_At,_Atomic,__attribute,__attribute__,auto,
-                _Bool,catch,catchResume,choose,_Complex,__complex,__complex__,__const,__const__,disable,dtype,enable,__extension__,
-                fallthrough,fallthru,finally,forall,ftype,_Generic,_Imaginary,inline,__label__,lvalue,_Noreturn,one_t,otype,restrict,_Static_assert,
-                _Thread_local,throw,throwResume,trait,try,ttype,typeof,__typeof,__typeof__,zero_t},
+        morekeywords={
+                _Alignas, _Alignof, __alignof, __alignof__, asm, __asm, __asm__, _At, __attribute,
+                __attribute__, auto, _Bool, catch, catchResume, choose, _Complex, __complex, __complex__,
+                __const, __const__, disable, dtype, enable, __extension__, fallthrough, fallthru,
+                finally, forall, ftype, _Generic, _Imaginary, inline, __label__, lvalue, _Noreturn, one_t,
+                otype, restrict, _Static_assert, throw, throwResume, trait, try, ttype, typeof, __typeof,
+                __typeof__, virtual, with, zero_t},
+        moredirectives={defined,include_next}%
 }%
 
@@ -91 +118 @@
 basicstyle=\linespread{0.9}\sf,                                                 % reduce line spacing and use sanserif font
 stringstyle=\tt,                                                                                % use typewriter font
-tabsize=4,                                                                                              % 4 space tabbing
+tabsize=5,                                                                                              % N space tabbing
 xleftmargin=\parindentlnth,                                                             % indent code to paragraph indentation
 %mathescape=true,                                                                               % LaTeX math escape in CFA code $...$
@@ -101 +128 @@
 belowskip=3pt,
 % replace/adjust listing characters that look bad in sanserif
-literate={-}{\makebox[1.4ex][c]{\raisebox{0.5ex}{\rule{1.2ex}{0.06ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
+literate={-}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
         {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
-        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1.4ex][c]{\raisebox{0.5ex}{\rule{1.2ex}{0.06ex}}}\kern-0.3ex\textgreater}2,
+        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex\textgreater}2,
 moredelim=**[is][\color{red}]{`}{`},
 }% lstset
@@ -109 +136 @@
 % inline code @...@
 \lstMakeShortInline@%
+
+\lstnewenvironment{cfa}[1][]
+{\lstset{#1}}
+{}
+\lstnewenvironment{C++}[1][]                            % use C++ style
+{\lstset{language=C++,moredelim=**[is][\protect\color{red}]{`}{`},#1}\lstset{#1}}
+{}
+
 
 \title{Generic and Tuple Types with Efficient Dynamic Layout in \protect\CFA}
@@ -148 +183 @@
 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects.
 This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
-The \cite{TIOBE} ranks the top 5 most popular programming languages as: Java 16\%, \Textbf{C 7\%}, \Textbf{\CC 5\%}, \Csharp 4\%, Python 4\% = 36\%, where the next 50 languages are less than 3\% each with a long tail.
+The TIOBE~\cite{TIOBE} ranks the top 5 most popular programming languages as: Java 16\%, \Textbf{C 7\%}, \Textbf{\CC 5\%}, \Csharp 4\%, Python 4\% = 36\%, where the next 50 languages are less than 3\% each with a long tail.
 The top 3 rankings over the past 30 years are:
 \lstDeleteShortInline@%
@@ -185 +220 @@
 \label{sec:poly-fns}
 
-\CFA{}\hspace{1pt}'s polymorphism was originally formalized by \cite{Ditchfield92}, and first implemented by \cite{Bilson03}.
+\CFA{}\hspace{1pt}'s polymorphism was originally formalized by Ditchfield~\cite{Ditchfield92}, and first implemented by Bilson~\cite{Bilson03}.
 The signature feature of \CFA is parametric-polymorphic functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a @forall@ clause (giving the language its name):
 \begin{lstlisting}
@@ -258 +293 @@
 }
 \end{lstlisting}
-Within the block, the nested version of @<@ performs @>@ and this local version overrides the built-in @<@ so it is passed to @qsort@.
+Within the block, the nested version of @?<?@ performs @?>?@ and this local version overrides the built-in @?<?@ so it is passed to @qsort@.
 Hence, programmers can easily form local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
 
@@ -544 +579 @@
 p`->0` = 5;                                                                     $\C{// change quotient}$
 bar( qr`.1`, qr );                                                      $\C{// pass remainder and quotient/remainder}$
-rem = [42, div( 13, 5 )]`.0.1`;                         $\C{// access 2nd component of 1st component of tuple expression}$
+rem = [div( 13, 5 ), 42]`.0.1`;                         $\C{// access 2nd component of 1st component of tuple expression}$
 \end{lstlisting}
 
@@ -730 +765 @@
 \end{lstlisting}
 Hence, function parameter and return lists are flattened for the purposes of type unification allowing the example to pass expression resolution.
-This relaxation is possible by extending the thunk scheme described by~\cite{Bilson03}.
+This relaxation is possible by extending the thunk scheme described by Bilson~\cite{Bilson03}.
 Whenever a candidate's parameter structure does not exactly match the formal parameter's structure, a thunk is generated to specialize calls to the actual function:
 \begin{lstlisting}
@@ -902 +937 @@
 
 
+\section{Control Structures}
+
+
+\subsection{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break}}{Labelled continue / break}}
+
+While C provides @continue@ and @break@ statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
+Unfortunately, this restriction forces programmers to use @goto@ to achieve the equivalent control-flow for more than one level of nesting.
+To prevent having to switch to the @goto@, \CFA extends the @continue@ and @break@ with a target label to support static multi-level exit~\cite{Buhr85}, as in Java.
+For both @continue@ and @break@, the target label must be directly associated with a @for@, @while@ or @do@ statement;
+for @break@, the target label can also be associated with a @switch@, @if@ or compound (@{}@) statement.
+Figure~\ref{f:MultiLevelExit} shows @continue@ and @break@ indicating the specific control structure, and the corresponding C program using only @goto@ and labels.
+The innermost loop has 7 exit points, which cause continuation or termination of one or more of the 7 nested control-structures.
+
+\begin{figure}
+\lstDeleteShortInline@%
+\begin{tabular}{@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
+\multicolumn{1}{@{\hspace{\parindentlnth}}c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}   & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}}      \\
+\begin{cfa}
+`LC:` {
+        ... $declarations$ ...
+        `LS:` switch ( ... ) {
+          case 3:
+                `LIF:` if ( ... ) {
+                        `LF:` for ( ... ) {
+                                `LW:` while ( ... ) {
+                                        ... break `LC`; ...
+                                        ... break `LS`; ...
+                                        ... break `LIF`; ...
+                                        ... continue `LF;` ...
+                                        ... break `LF`; ...
+                                        ... continue `LW`; ...
+                                        ... break `LW`; ...
+                                } // while
+                        } // for
+                } else {
+                        ... break `LIF`; ...
+                } // if
+        } // switch
+} // compound
+\end{cfa}
+&
+\begin{cfa}
+{
+        ... $declarations$ ...
+        switch ( ... ) {
+          case 3:
+                if ( ... ) {
+                        for ( ... ) {
+                                while ( ... ) {
+                                        ... goto `LC`; ...
+                                        ... goto `LS`; ...
+                                        ... goto `LIF`; ...
+                                        ... goto `LFC`; ...
+                                        ... goto `LFB`; ...
+                                        ... goto `LWC`; ...
+                                        ... goto `LWB`; ...
+                                  `LWC`: ; } `LWB:` ;
+                          `LFC:` ; } `LFB:` ;
+                } else {
+                        ... goto `LIF`; ...
+                } `L3:` ;
+        } `LS:` ;
+} `LC:` ;
+\end{cfa}
+&
+\begin{cfa}
+
+
+
+
+
+
+
+// terminate compound
+// terminate switch
+// terminate if
+// continue loop
+// terminate loop
+// continue loop
+// terminate loop
+
+
+
+// terminate if
+
+
+
+\end{cfa}
+\end{tabular}
+\lstMakeShortInline@%
+\caption{Multi-level Exit}
+\label{f:MultiLevelExit}
+\end{figure}
+
+Both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:
+\begin{itemize}
+\item
+They cannot create a loop, which means only the looping constructs cause looping.
+This restriction means all situations resulting in repeated execution are clearly delineated.
+\item
+They cannot branch into a control structure.
+This restriction prevents missing declarations and/or initializations at the start of a control structure resulting in undefined behaviour.
+\end{itemize}
+The advantage of the labelled @continue@/@break@ is allowing static multi-level exits without having to use the @goto@ statement, and tying control flow to the target control structure rather than an arbitrary point in a program.
+Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader (eye candy) that complex control-flow is occurring in the body of the control structure.
+With @goto@, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
+Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
+The implicit targets of the current @continue@ and @break@, \ie the closest enclosing loop or @switch@, change as certain constructs are added or removed.
+
+\TODO{choose and fallthrough here as well?}
+
+
+\subsection{\texorpdfstring{\LstKeywordStyle{with} Clause / Statement}{with Clause / Statement}}
+\label{s:WithClauseStatement}
+
+Grouping heterogenous data into \newterm{aggregate}s is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers:
+\begin{cfa}
+struct S {                                                              $\C{// aggregate}$
+        char c;                                                         $\C{// fields}$
+        int i;
+        double d;
+};
+S s, as[10];
+\end{cfa}
+However, routines manipulating aggregates have repeition of the aggregate name to access its containing fields:
+\begin{cfa}
+void f( S s ) {
+        `s.`c; `s.`i; `s.`d;                            $\C{// access containing fields}$
+}
+\end{cfa}
+A similar situation occurs in object-oriented programming, \eg \CC:
+\begin{C++}
+class C {
+        char c;                                                         $\C{// fields}$
+        int i;
+        double d;
+        int mem() {                                                     $\C{// implicit "this" parameter}$
+                `this->`c; `this->`i; `this->`d;$\C{// access containing fields}$
+        }
+}
+\end{C++}
+Nesting of member routines in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of nested lexical-scoping.
+
+% In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided.
+% In any programming language, some functions have a naturally close relationship with a particular data type. 
+% Object-oriented programming allows this close relationship to be codified in the language by making such functions \emph{class methods} of their related data type.
+% Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type. 
+% When writing C functions in an object-oriented style, this un-prefixed access is swiftly missed, as access to fields of a @Foo* f@ requires an extra three characters @f->@ every time, which disrupts coding flow and clutters the produced code. 
+% 
+% \TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.}
+
+\CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided aggregate qualification to fields by opening a scope containing field identifiers.
+Hence, the qualified fields become variables, and making it easier to optimizing field references in a block.
+\begin{cfa}
+void f( S s ) `with s` {                                $\C{// with clause}$
+        c; i; d;                                                        $\C{\color{red}// s.c, s.i, s.d}$
+}
+\end{cfa}
+and the equivalence for object-style programming is:
+\begin{cfa}
+int mem( S & this ) `with this` {               $\C{// with clause}$
+        c; i; d;                                                        $\C{\color{red}// this.c, this.i, this.d}$
+}
+\end{cfa}
+The key generality over the object-oriented approach is that one aggregate parameter \lstinline[language=C++]@this@ is not treated specially over other aggregate parameters:
+\begin{cfa}
+struct T { double m, n; };
+int mem( S & s, T & t ) `with s, t` {   $\C{// multiple aggregate parameters}$
+        c; i; d;                                                        $\C{\color{red}// s.c, s.i, s.d}$
+        m; n;                                                           $\C{\color{red}// t.m, t.n}$
+}
+\end{cfa}
+The equivalent object-oriented style is:
+\begin{cfa}
+int S::mem( T & t ) {                                   $\C{// multiple aggregate parameters}$
+        c; i; d;                                                        $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$
+        `t.`m; `t.`n;
+}
+\end{cfa}
+
+The statement form is used within a block:
+\begin{cfa}
+int foo() {
+        struct S1 { ... } s1;
+        struct S2 { ... } s2;
+        `with s1` {                                             $\C{// with statement}$
+                // access fields of s1 without qualification
+                `with s2` {                                     $\C{// nesting}$
+                        // access fields of s1 and s2 without qualification
+                }
+        }
+        `with s1, s2` {
+                // access unambiguous fields of s1 and s2 without qualification
+        }
+}
+\end{cfa}
+
+When opening multiple structures, fields with the same name and type are ambiguous and must be fully qualified.
+For fields with the same name but different type, context/cast can be used to disambiguate.
+\begin{cfa}
+struct S { int i; int j; double m; } a, c;
+struct T { int i; int k; int m } b, c;
+`with a, b` {
+        j + k;                                                  $\C{// unambiguous, unique names define unique types}$
+        i;                                                              $\C{// ambiguous, same name and type}$
+        a.i + b.i;                                              $\C{// unambiguous, qualification defines unique names}$
+        m;                                                              $\C{// ambiguous, same name and no context to define unique type}$
+        m = 5.0;                                                $\C{// unambiguous, same name and context defines unique type}$
+        m = 1;                                                  $\C{// unambiguous, same name and context defines unique type}$
+}
+`with c` { ... }                                        $\C{// ambiguous, same name and no context}$
+`with (S)c` { ... }                                     $\C{// unambiguous, same name and cast defines unique type}$
+\end{cfa}
+
+The components in the "with" clause
+
+  with a, b, c { ... }
+
+serve 2 purposes: each component provides a type and object. The type must be a
+structure type. Enumerations are already opened, and I think a union is opened
+to some extent, too. (Or is that just unnamed unions?) The object is the target
+that the naked structure-fields apply to. The components are open in "parallel"
+at the scope of the "with" clause/statement, so opening "a" does not affect
+opening "b", etc. This semantic is different from Pascal, which nests the
+openings.
+
+Having said the above, it seems reasonable to allow a "with" component to be an
+expression. The type is the static expression-type and the object is the result
+of the expression. Again, the type must be an aggregate. Expressions require
+parenthesis around the components.
+
+  with( a, b, c ) { ... }
+
+Does this now make sense?
+
+Having written more CFA code, it is becoming clear to me that I *really* want
+the "with" to be implemented because I hate having to type all those object
+names for fields. It's a great way to drive people away from the language.
+
+
+\subsection{Exception Handling ???}
+
+
+\section{Declarations}
+
+It is important to the design team that \CFA subjectively ``feel like'' C to user programmers. 
+An important part of this subjective feel is maintaining C's procedural programming paradigm, as opposed to the object-oriented paradigm of other systems languages such as \CC and Rust. 
+Maintaining this procedural paradigm means that coding patterns that work in C will remain not only functional but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development. 
+Nonetheless, some features of object-oriented languages are undeniably convienient, and the \CFA design team has attempted to adapt them to a procedural paradigm so as to incorporate their benefits into \CFA; two of these features are resource management and name scoping.
+
+
+\subsection{Alternative Declaration Syntax}
+
+
+\subsection{References}
+
+All variables in C have an \emph{address}, a \emph{value}, and a \emph{type}; at the position in the program's memory denoted by the address, there exists a sequence of bits (the value), with the length and semantic meaning of this bit sequence defined by the type. 
+The C type system does not always track the relationship between a value and its address; a value that does not have a corresponding address is called a \emph{rvalue} (for ``right-hand value''), while a value that does have an address is called a \emph{lvalue} (for ``left-hand value''); in @int x; x = 42;@ the variable expression @x@ on the left-hand-side of the assignment is a lvalue, while the constant expression @42@ on the right-hand-side of the assignment is a rvalue.
+Which address a value is located at is sometimes significant; the imperative programming paradigm of C relies on the mutation of values at specific addresses. 
+Within a lexical scope, lvalue exressions can be used in either their \emph{address interpretation} to determine where a mutated value should be stored or in their \emph{value interpretation} to refer to their stored value; in @x = y;@ in @{ int x, y = 7; x = y; }@, @x@ is used in its address interpretation, while y is used in its value interpretation.
+Though this duality of interpretation is useful, C lacks a direct mechanism to pass lvalues between contexts, instead relying on \emph{pointer types} to serve a similar purpose. 
+In C, for any type @T@ there is a pointer type @T*@, the value of which is the address of a value of type @T@; a pointer rvalue can be explicitly \emph{dereferenced} to the pointed-to lvalue with the dereference operator @*?@, while the rvalue representing the address of a lvalue can be obtained with the address-of operator @&?@.
+
+\begin{cfa}
+int x = 1, y = 2, * p1, * p2, ** p3;
+p1 = &x;  $\C{// p1 points to x}$
+p2 = &y;  $\C{// p2 points to y}$
+p3 = &p1;  $\C{// p3 points to p1}$
+\end{cfa}
+
+Unfortunately, the dereference and address-of operators introduce a great deal of syntactic noise when dealing with pointed-to values rather than pointers, as well as the potential for subtle bugs. 
+It would be desirable to have the compiler figure out how to elide the dereference operators in a complex expression such as @*p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);@, for both brevity and clarity.
+However, since C defines a number of forms of \emph{pointer arithmetic}, two similar expressions involving pointers to arithmetic types (\eg @*p1 + x@ and @p1 + x@) may each have well-defined but distinct semantics, introducing the possibility that a user programmer may write one when they mean the other, and precluding any simple algorithm for elision of dereference operators.
+To solve these problems, \CFA introduces reference types @T&@; a @T&@ has exactly the same value as a @T*@, but where the @T*@ takes the address interpretation by default, a @T&@ takes the value interpretation by default, as below:
+
+\begin{cfa}
+inx x = 1, y = 2, & r1, & r2, && r3;
+&r1 = &x;  $\C{// r1 points to x}$
+&r2 = &y;  $\C{// r2 points to y}$
+&&r3 = &&r1;  $\C{// r3 points to r2}$
+r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);  $\C{// implicit dereferencing}$
+\end{cfa}
+
+Except for auto-dereferencing by the compiler, this reference example is exactly the same as the previous pointer example. 
+Hence, a reference behaves like a variable name -- an lvalue expression which is interpreted as a value, but also has the type system track the address of that value. 
+One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in the reference variable declaration, so the previous example implicitly acts like:
+
+\begin{cfa}
+`*`r2 = ((`*`r1 + `*`r2) * (`**`r3 - `*`r1)) / (`**`r3 - 15);
+\end{cfa}
+
+References in \CFA are similar to those in \CC, but with a couple important improvements, both of which can be seen in the example above. 
+Firstly, \CFA does not forbid references to references, unlike \CC. 
+This provides a much more orthogonal design for library implementors, obviating the need for workarounds such as @std::reference_wrapper@. 
+
+Secondly, unlike the references in \CC which always point to a fixed address, \CFA references are rebindable. 
+This allows \CFA references to be default-initialized (to a null pointer), and also to point to different addresses throughout their lifetime. 
+This rebinding is accomplished without adding any new syntax to \CFA, but simply by extending the existing semantics of the address-of operator in C. 
+In C, the address of a lvalue is always a rvalue, as in general that address is not stored anywhere in memory, and does not itself have an address. 
+In \CFA, the address of a @T&@ is a lvalue @T*@, as the address of the underlying @T@ is stored in the reference, and can thus be mutated there. 
+The result of this rule is that any reference can be rebound using the existing pointer assignment semantics by assigning a compatible pointer into the address of the reference, \eg @&r1 = &x;@ above. 
+This rebinding can occur to an arbitrary depth of reference nesting; $n$ address-of operators applied to a reference nested $m$ times will produce an lvalue pointer nested $n$ times if $n \le m$ (note that $n = m+1$ is simply the usual C rvalue address-of operator applied to the $n = m$ case).
+The explicit address-of operators can be thought of as ``cancelling out'' the implicit dereference operators, \eg @(&`*`)r1 = &x;@ or @(&(&`*`)`*`)r3 = &(&`*`)r1;@ or even @(&`*`)r2 = (&`*`)`*`r3;@ for @&r2 = &r3;@.
+
+Since pointers and references share the same internal representation, code using either is equally performant; in fact the \CFA compiler converts references to pointers internally, and the choice between them in user code can be made based solely on convenience. 
+By analogy to pointers, \CFA references also allow cv-qualifiers:
+
+\begin{cfa}
+const int cx = 5;               $\C{// cannot change cx}$
+const int & cr = cx;    $\C{// cannot change cr's referred value}$
+&cr = &cx;                              $\C{// rebinding cr allowed}$
+cr = 7;                                 $\C{// ERROR, cannot change cr}$
+int & const rc = x;             $\C{// must be initialized, like in \CC}$
+&rc = &x;                               $\C{// ERROR, cannot rebind rc}$
+rc = 7;                                 $\C{// x now equal to 7}$
+\end{cfa}
+
+\TODO{Pull more draft text from user manual; make sure to discuss initialization and reference conversions}
+
+
+\subsection{Constructors and Destructors}
+
+One of the strengths of C is the control over memory management it gives programmers, allowing resource release to be more consistent and precisely timed than is possible with garbage-collected memory management. 
+However, this manual approach to memory management is often verbose, and it is useful to manage resources other than memory (\eg file handles) using the same mechanism as memory. 
+\CC is well-known for an approach to manual memory management that addresses both these issues, Resource Allocation Is Initialization (RAII), implemented by means of special \emph{constructor} and \emph{destructor} functions; we have implemented a similar feature in \CFA.
+
+\TODO{Fill out section. Mention field-constructors and at-equal escape hatch to C-style initialization. Probably pull some text from Rob's thesis for first draft.}
+
+
+\subsection{Default Parameters}
+
+
+\section{Literals}
+
+
+\subsection{0/1}
+
+\TODO{Some text already at the end of Section~\ref{sec:poly-fns}}
+
+
+\subsection{Units}
+
+Alternative call syntax (literal argument before routine name) to convert basic literals into user literals.
+
+{\lstset{language=CFA,deletedelim=**[is][]{`}{`},moredelim=**[is][\color{red}]{@}{@}}
+\begin{cfa}
+struct Weight { double stones; };
+
+void ?{}( Weight & w ) { w.stones = 0; } $\C{// operations}$
+void ?{}( Weight & w, double w ) { w.stones = w; }
+Weight ?+?( Weight l, Weight r ) { return (Weight){ l.stones + r.stones }; }
+
+Weight @?`st@( double w ) { return (Weight){ w }; } $\C{// backquote for units}$
+Weight @?`lb@( double w ) { return (Weight){ w / 14.0 }; }
+Weight @?`kg@( double w ) { return (Weight) { w * 0.1575}; }
+
+int main() {
+        Weight w, hw = { 14 };                  $\C{// 14 stone}$
+        w = 11@`st@ + 1@`lb@;
+        w = 70.3@`kg@;
+        w = 155@`lb@;
+        w = 0x_9b_u@`lb@;                               $\C{// hexadecimal unsigned weight (155)}$
+        w = 0_233@`lb@;                                 $\C{// octal weight (155)}$
+        w = 5@`st@ + 8@`kg@ + 25@`lb@ + hw;
+}
+\end{cfa}
+}%
+
+
 \section{Evaluation}
 \label{sec:eval}
@@ -1013 +1417 @@
 In contrast, \CFA has a single facility for polymorphic code supporting type-safe separate-compilation of polymorphic functions and generic (opaque) types, which uniformly leverage the C procedural paradigm.
 The key mechanism to support separate compilation is \CFA's \emph{explicit} use of assumed properties for a type.
-Until \CC~\cite{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way to specify the requirements of a generic function in code beyond compilation errors during template expansion;
+Until \CC concepts~\cite{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way to specify the requirements of a generic function in code beyond compilation errors during template expansion;
 furthermore, \CC concepts are restricted to template polymorphism.
 
@@ -1021 +1425 @@
 In \CFA terms, all Cyclone polymorphism must be dtype-static.
 While the Cyclone design provides the efficiency benefits discussed in Section~\ref{sec:generic-apps} for dtype-static polymorphism, it is more restrictive than \CFA's general model.
-\cite{Smith98} present Polymorphic C, an ML dialect with polymorphic functions and C-like syntax and pointer types; it lacks many of C's features, however, most notably structure types, and so is not a practical C replacement.
-
-\cite{obj-c-book} is an industrially successful extension to C.
+Smith and Volpano~\cite{Smith98} present Polymorphic C, an ML dialect with polymorphic functions, C-like syntax, and pointer types; it lacks many of C's features, however, most notably structure types, and so is not a practical C replacement.
+
+Objective-C~\cite{obj-c-book} is an industrially successful extension to C.
 However, Objective-C is a radical departure from C, using an object-oriented model with message-passing.
 Objective-C did not support type-checked generics until recently \cite{xcode7}, historically using less-efficient runtime checking of object types.
-The~\cite{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage-collection to C;
+The GObject~\cite{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage-collection to C;
 these features are more intrusive additions than those provided by \CFA, in addition to the runtime overhead of reference-counting.
-\cite{Vala} compiles to GObject-based C, adding the burden of learning a separate language syntax to the aforementioned demerits of GObject as a modernization path for existing C code-bases.
+Vala~\cite{Vala} compiles to GObject-based C, adding the burden of learning a separate language syntax to the aforementioned demerits of GObject as a modernization path for existing C code-bases.
 Java~\cite{Java8} included generic types in Java~5, which are type-checked at compilation and type-erased at runtime, similar to \CFA's.
 However, in Java, each object carries its own table of method pointers, while \CFA passes the method pointers separately to maintain a C-compatible layout.
 Java is also a garbage-collected, object-oriented language, with the associated resource usage and C-interoperability burdens.
 
-D~\cite{D}, Go, and~\cite{Rust} are modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in D and Go and \emph{traits} in Rust.
+D~\cite{D}, Go, and Rust~\cite{Rust} are modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in D and Go and \emph{traits} in Rust.
 However, each language represents a significant departure from C in terms of language model, and none has the same level of compatibility with C as \CFA.
 D and Go are garbage-collected languages, imposing the associated runtime overhead.
@@ -1054 +1458 @@
 \CCeleven introduced @std::tuple@ as a library variadic template structure.
 Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values.
-Operations include @std::get<N>@ to extract vales, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons.
+Operations include @std::get<N>@ to extract values, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons.
 \CCseventeen proposes \emph{structured bindings}~\cite{Sutter15} to eliminate pre-declaring variables and use of @std::tie@ for binding the results.
 This extension requires the use of @auto@ to infer the types of the new variables, so complicated expressions with a non-obvious type must be documented with some other mechanism.
@@ -1068 +1472 @@
 The goal of \CFA is to provide an evolutionary pathway for large C development-environments to be more productive and safer, while respecting the talent and skill of C programmers.
 While other programming languages purport to be a better C, they are in fact new and interesting languages in their own right, but not C extensions.
-The purpose of this paper is to introduce \CFA, and showcase two language features that illustrate the \CFA type-system and approaches taken to achieve the goal of evolutionary C extension.
+The purpose of this paper is to introduce \CFA, and showcase language features that illustrate the \CFA type-system and approaches taken to achieve the goal of evolutionary C extension.
 The contributions are a powerful type-system using parametric polymorphism and overloading, generic types, and tuples, which all have complex interactions.
 The work is a challenging design, engineering, and implementation exercise.