Ignore:
Timestamp:
Feb 12, 2018, 11:55:02 AM (7 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
d56ca354, ee2938a
Parents:
827a190 (diff), 43c6dc82 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/papers/general/Paper.tex

    r827a190 rcfe2f0a  
    22
    33\usepackage{fullpage}
     4\usepackage{epic,eepic}
    45\usepackage{xspace,calc,comment}
    56\usepackage{upquote}                                                                    % switch curled `'" to straight
    … …  
    3637%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    3738
    38 \newcommand{\Textbf}[1]{{\color{red}\textbf{#1}}}
     39\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
    3940\newcommand{\TODO}[1]{\textbf{TODO}: {\itshape #1}} % TODO included
    4041%\newcommand{\TODO}[1]{} % TODO elided
    … …  
    101102\makeatother
    102103
     104\newenvironment{cquote}{%
     105        \list{}{\lstset{resetmargins=true,aboveskip=0pt,belowskip=0pt}\topsep=4pt\parsep=0pt\leftmargin=\parindent\rightmargin\leftmargin}%
     106        \item\relax
     107}{%
     108        \endlist
     109}% cquote
     110
    103111% CFA programming language, based on ANSI C (with some gcc additions)
    104112\lstdefinelanguage{CFA}[ANSI]{C}{
    … …  
    226234int forty_two = identity( 42 );                         $\C{// T is bound to int, forty\_two == 42}$
    227235\end{lstlisting}
    228 The @identity@ function above can be applied to any complete \emph{object type} (or @otype@).
     236The @identity@ function above can be applied to any complete \newterm{object type} (or @otype@).
    229237The type variable @T@ is transformed into a set of additional implicit parameters encoding sufficient information about @T@ to create and return a variable of that type.
    230238The \CFA implementation passes the size and alignment of the type represented by an @otype@ parameter, as well as an assignment operator, constructor, copy constructor and destructor.
    231 If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \emph{data type} (or @dtype@).
     239If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@).
    232240
    233241In \CFA, the polymorphism runtime-cost is spread over each polymorphic call, due to passing more arguments to polymorphic functions;
    … …  
    235243A design advantage is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat.
    236244
    237 Since bare polymorphic-types provide a restricted set of available operations, \CFA provides a \emph{type assertion}~\cite[pp.~37-44]{Alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable.
     245Since bare polymorphic-types provide a restricted set of available operations, \CFA provides a \newterm{type assertion}~\cite[pp.~37-44]{Alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable.
    238246For example, the function @twice@ can be defined using the \CFA syntax for operator overloading:
    239247\begin{lstlisting}
    … …  
    302310\end{lstlisting}
    303311Here, the single name @MAX@ replaces all the C type-specific names: @SHRT_MAX@, @INT_MAX@, @DBL_MAX@.
    304 As well, restricted constant overloading is allowed for the values @0@ and @1@, which have special status in C, \eg the value @0@ is both an integer and a pointer literal, so its meaning depends on context.
    305 In addition, several operations are defined in terms values @0@ and @1@, \eg:
    306 \begin{lstlisting}
    307 int x;
    308 if (x) x++                                                                      $\C{// if (x != 0) x += 1;}$
    309 \end{lstlisting}
    310 Every @if@ and iteration statement in C compares the condition with @0@, and every increment and decrement operator is semantically equivalent to adding or subtracting the value @1@ and storing the result.
    311 Due to these rewrite rules, the values @0@ and @1@ have the types @zero_t@ and @one_t@ in \CFA, which allows overloading various operations for new types that seamlessly connect to all special @0@ and @1@ contexts.
    312 The types @zero_t@ and @one_t@ have special built in implicit conversions to the various integral types, and a conversion to pointer types for @0@, which allows standard C code involving @0@ and @1@ to work as normal.
    313 
    314312
    315313\subsection{Traits}
    316314
    317 \CFA provides \emph{traits} to name a group of type assertions, where the trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration:
     315\CFA provides \newterm{traits} to name a group of type assertions, where the trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration:
    318316\begin{lstlisting}
    319317trait summable( otype T ) {
    … …  
    339337Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete type: stack-allocatable, default or copy-initialized, assigned, and deleted.
    340338
    341 In summation, the \CFA type-system uses \emph{nominal typing} for concrete types, matching with the C type-system, and \emph{structural typing} for polymorphic types.
     339In summation, the \CFA type-system uses \newterm{nominal typing} for concrete types, matching with the C type-system, and \newterm{structural typing} for polymorphic types.
    342340Hence, trait names play no part in type equivalence;
    343341the names are simply macros for a list of polymorphic assertions, which are expanded at usage sites.
    … …  
    384382Furthermore, writing and using preprocessor macros can be unnatural and inflexible.
    385383
    386 \CC, Java, and other languages use \emph{generic types} to produce type-safe abstract data-types.
     384\CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data-types.
    387385\CFA also implements generic types that integrate efficiently and naturally with the existing polymorphic functions, while retaining backwards compatibility with C and providing separate compilation.
    388386However, for known concrete parameters, the generic-type definition can be inlined, like \CC templates.
    … …  
    405403\end{lstlisting}
    406404
    407 \CFA classifies generic types as either \emph{concrete} or \emph{dynamic}.
     405\CFA classifies generic types as either \newterm{concrete} or \newterm{dynamic}.
    408406Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
    409 A type may have polymorphic parameters but still be concrete, called \emph{dtype-static}.
     407A type may have polymorphic parameters but still be concrete, called \newterm{dtype-static}.
    410408Polymorphic pointers are an example of dtype-static types, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@  is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation.
    411409
    … …  
    444442Though \CFA implements concrete generic-types efficiently, it also has a fully general system for dynamic generic types.
    445443As mentioned in Section~\ref{sec:poly-fns}, @otype@ function parameters (in fact all @sized@ polymorphic parameters) come with implicit size and alignment parameters provided by the caller.
    446 Dynamic generic-types also have an \emph{offset array} containing structure-member offsets.
     444Dynamic generic-types also have an \newterm{offset array} containing structure-member offsets.
    447445A dynamic generic-union needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.
    448446Access to members of a dynamic structure is provided at runtime via base-displacement addressing with the structure pointer and the member offset (similar to the @offsetof@ macro), moving a compile-time offset calculation to runtime.
    … …  
    457455For instance, modularity is generally provided in C by including an opaque forward-declaration of a structure and associated accessor and mutator functions in a header file, with the actual implementations in a separately-compiled @.c@ file.
    458456\CFA supports this pattern for generic types, but the caller does not know the actual layout or size of the dynamic generic-type, and only holds it by a pointer.
    459 The \CFA translator automatically generates \emph{layout functions} for cases where the size, alignment, and offset array of a generic struct cannot be passed into a function from that function's caller.
     457The \CFA translator automatically generates \newterm{layout functions} for cases where the size, alignment, and offset array of a generic struct cannot be passed into a function from that function's caller.
    460458These layout functions take as arguments pointers to size and alignment variables and a caller-allocated array of member offsets, as well as the size and alignment of all @sized@ parameters to the generic structure (un@sized@ parameters are forbidden from being used in a context that affects layout).
    461459Results of these layout functions are cached so that they are only computed once per type per function. %, as in the example below for @pair@.
    … …  
    481479Since @pair(T *, T * )@ is a concrete type, there are no implicit parameters passed to @lexcmp@, so the generated code is identical to a function written in standard C using @void *@, yet the \CFA version is type-checked to ensure the fields of both pairs and the arguments to the comparison function match in type.
    482480
    483 Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \emph{tag-structures}.
     481Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \newterm{tag-structures}.
    484482Sometimes information is only used for type-checking and can be omitted at runtime, \eg:
    485483\begin{lstlisting}
    … …  
    537535The addition of multiple-return-value functions (MRVF) are useless without a syntax for accepting multiple values at the call-site.
    538536The simplest mechanism for capturing the return values is variable assignment, allowing the values to be retrieved directly.
    539 As such, \CFA allows assigning multiple values from a function into multiple variables, using a square-bracketed list of lvalue expressions (as above), called a \emph{tuple}.
    540 
    541 However, functions also use \emph{composition} (nested calls), with the direct consequence that MRVFs must also support composition to be orthogonal with single-returning-value functions (SRVF), \eg:
     537As such, \CFA allows assigning multiple values from a function into multiple variables, using a square-bracketed list of lvalue expressions (as above), called a \newterm{tuple}.
     538
     539However, functions also use \newterm{composition} (nested calls), with the direct consequence that MRVFs must also support composition to be orthogonal with single-returning-value functions (SRVF), \eg:
    542540\begin{lstlisting}
    543541printf( "%d %d\n", div( 13, 5 ) );                      $\C{// return values seperated into arguments}$
    … …  
    572570printf( "%d %d\n", qr );
    573571\end{lstlisting}
    574 \CFA also supports \emph{tuple indexing} to access single components of a tuple expression:
     572\CFA also supports \newterm{tuple indexing} to access single components of a tuple expression:
    575573\begin{lstlisting}
    576574[int, int] * p = &qr;                                           $\C{// tuple pointer}$
    … …  
    615613\subsection{Tuple Assignment}
    616614
    617 An assignment where the left side is a tuple type is called \emph{tuple assignment}.
    618 There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \emph{multiple} and \emph{mass assignment}, respectively.
     615An assignment where the left side is a tuple type is called \newterm{tuple assignment}.
     616There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \newterm{multiple} and \newterm{mass assignment}, respectively.
    619617%\lstDeleteShortInline@%
    620618%\par\smallskip
    … …  
    650648\subsection{Member Access}
    651649
    652 It is also possible to access multiple fields from a single expression using a \emph{member-access}.
     650It is also possible to access multiple fields from a single expression using a \newterm{member-access}.
    653651The result is a single tuple-valued expression whose type is the tuple of the types of the members, \eg:
    654652\begin{lstlisting}
    … …  
    780778Matching against a @ttype@ parameter consumes all remaining argument components and packages them into a tuple, binding to the resulting tuple of types.
    781779In a given parameter list, there must be at most one @ttype@ parameter that occurs last, which matches normal variadic semantics, with a strong feeling of similarity to \CCeleven variadic templates.
    782 As such, @ttype@ variables are also called \emph{argument packs}.
     780As such, @ttype@ variables are also called \newterm{argument packs}.
    783781
    784782Like variadic templates, the main way to manipulate @ttype@ polymorphic functions is via recursion.
    … …  
    852850\subsection{Implementation}
    853851
    854 Tuples are implemented in the \CFA translator via a transformation into \emph{generic types}.
     852Tuples are implemented in the \CFA translator via a transformation into \newterm{generic types}.
    855853For each $N$, the first time an $N$-tuple is seen in a scope a generic type with $N$ type parameters is generated, \eg:
    856854\begin{lstlisting}
    … …  
    903901Similarly, tuple member expressions are recursively expanded into a list of member access expressions.
    904902
    905 Expressions that may contain side effects are made into \emph{unique expressions} before being expanded by the flattening conversion.
     903Expressions that may contain side effects are made into \newterm{unique expressions} before being expanded by the flattening conversion.
    906904Each unique expression is assigned an identifier and is guaranteed to be executed exactly once:
    907905\begin{lstlisting}
    … …  
    10521050\label{s:WithClauseStatement}
    10531051
    1054 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:
    1055 \begin{cfa}
    1056 struct S {                                                              $\C{// aggregate}$
    1057         char c;                                                         $\C{// fields}$
     1052Grouping heterogenous data into \newterm{aggregate}s (structure/union) is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers:
     1053\begin{cfa}
     1054struct S {                                                                      $\C{// aggregate}$
     1055        char c;                                                                 $\C{// fields}$
    10581056        int i;
    10591057        double d;
    … …  
    10611059S s, as[10];
    10621060\end{cfa}
    1063 However, routines manipulating aggregates have repeition of the aggregate name to access its containing fields:
     1061However, routines manipulating aggregates must repeat the aggregate name to access its containing fields:
    10641062\begin{cfa}
    10651063void f( S s ) {
    1066         `s.`c; `s.`i; `s.`d;                            $\C{// access containing fields}$
     1064        `s.`c; `s.`i; `s.`d;                                    $\C{// access containing fields}$
    10671065}
    10681066\end{cfa}
    … …  
    10701068\begin{C++}
    10711069class C {
    1072         char c;                                                         $\C{// fields}$
     1070        char c;                                                                 $\C{// fields}$
    10731071        int i;
    10741072        double d;
    1075         int mem() {                                                     $\C{// implicit "this" parameter}$
    1076                 `this->`c; `this->`i; `this->`d;$\C{// access containing fields}$
     1073        int mem() {                                                             $\C{// implicit "this" parameter}$
     1074                `this->`c; `this->`i; `this->`d;        $\C{// access containing fields}$
    10771075        }
    10781076}
    10791077\end{C++}
    1080 Nesting of member routines in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of nested lexical-scoping.
     1078Nesting of member routines in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
     1079However, for other aggregate parameters, qualification is necessary:
     1080\begin{cfa}
     1081struct T { double m, n; };
     1082int C::mem( T & t ) {                                           $\C{// multiple aggregate parameters}$
     1083        c; i; d;                                                                $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$
     1084        `t.`m; `t.`n;                                                   $\C{// must qualify}$
     1085}
     1086\end{cfa}
    10811087
    10821088% In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided.
    10831089% In any programming language, some functions have a naturally close relationship with a particular data type.
    1084 % 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.
     1090% Object-oriented programming allows this close relationship to be codified in the language by making such functions \newterm{class methods} of their related data type.
    10851091% Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type.
    10861092% 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.
    … …  
    10881094% \TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.}
    10891095
    1090 \CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing field identifiers.
    1091 Hence, the qualified fields become variables, and making it easier to optimize field references in a block.
    1092 \begin{cfa}
    1093 void f( S s ) `with( s )` {                             $\C{// with clause}$
    1094         c; i; d;                                                        $\C{\color{red}// s.c, s.i, s.d}$
     1096To simplify the programmer experience, \CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
     1097Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block.
     1098\begin{cfa}
     1099void f( S s ) `with( s )` {                                     $\C{// with clause}$
     1100        c; i; d;                                                                $\C{\color{red}// s.c, s.i, s.d}$
    10951101}
    10961102\end{cfa}
    … …  
    10981104\begin{cfa}
    10991105int mem( S & this ) `with( this )` {            $\C{// with clause}$
    1100         c; i; d;                                                        $\C{\color{red}// this.c, this.i, this.d}$
    1101 }
    1102 \end{cfa}
    1103 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:
    1104 \begin{cfa}
    1105 struct T { double m, n; };
     1106        c; i; d;                                                                $\C{\color{red}// this.c, this.i, this.d}$
     1107}
     1108\end{cfa}
     1109with the generality of opening multiple aggregate-parameters:
     1110\begin{cfa}
    11061111int mem( S & s, T & t ) `with( s, t )` {        $\C{// multiple aggregate parameters}$
    1107         c; i; d;                                                        $\C{\color{red}// s.c, s.i, s.d}$
    1108         m; n;                                                           $\C{\color{red}// t.m, t.n}$
    1109 }
    1110 \end{cfa}
    1111 The equivalent object-oriented style is:
    1112 \begin{cfa}
    1113 int S::mem( T & t ) {                                   $\C{// multiple aggregate parameters}$
    1114         c; i; d;                                                        $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$
    1115         `t.`m; `t.`n;
     1112        c; i; d;                                                                $\C{\color{red}// s.c, s.i, s.d}$
     1113        m; n;                                                                   $\C{\color{red}// t.m, t.n}$
     1114}
     1115\end{cfa}
     1116
     1117In detail, the @with@ clause/statement has the form:
     1118\begin{cfa}
     1119$\emph{with-statement}$:
     1120        'with' '(' $\emph{expression-list}$ ')' $\emph{compound-statement}$
     1121\end{cfa}
     1122and may appear as the body of a routine or nested within a routine body.
     1123Each expression in the expression-list provides a type and object.
     1124The type must be an aggregate type.
     1125(Enumerations are already opened.)
     1126The object is the implicit qualifier for the open structure-fields.
     1127
     1128All expressions in the expression list are open in ``parallel'' within the compound statement.
     1129This semantic is different from Pascal, which nests the openings.
     1130The difference between parallel and nesting occurs for fields with the same name but different type:
     1131\begin{cfa}
     1132struct S { int i; int j; double m; } s, w;
     1133struct T { int i; int k; int m } t, w;
     1134with( s, t ) {
     1135        j + k;                                                                  $\C{// unambiguous, s.j + t.m}$
     1136        m = 5.0;                                                                $\C{// unambiguous, t.m = 5.0}$
     1137        m = 1;                                                                  $\C{// unambiguous, s.m = 1}$
     1138        int a = s.i + m;                                                $\C{// unambiguous, a = s.i + t.i}$
     1139        int b = s.i + t.i;                                              $\C{// unambiguous, qualification}$
     1140        sout | (double)m | endl;                                $\C{// unambiguous, cast}$
     1141        i;                                                                              $\C{// ambiguous}$
     1142}
     1143\end{cfa}
     1144\CFA's ability to overload variables means usages of field with the same names can be automatically disambiguated, eliminating most qualification.
     1145Qualification or a cast is used to disambiguate.
     1146A cast may be necessary to disambiguate between the overload variables in a @with@ expression:
     1147\begin{cfa}
     1148with( w ) { ... }                                                       $\C{// ambiguous, same name and no context}$
     1149with( (S)w ) { ... }                                            $\C{// unambiguous}$
     1150\end{cfa}
     1151
     1152\begin{cfa}
     1153struct S { int i, j; } sv;
     1154with( sv ) {
     1155        S & sr = sv;
     1156        with( sr ) {
     1157                S * sp = &sv;
     1158                with( *sp ) {
     1159                        i = 3; j = 4;                                   $\C{\color{red}// sp-{\textgreater}i, sp-{\textgreater}j}$
     1160                }
     1161                i = 3; j = 4;                                           $\C{\color{red}// sr.i, sr.j}$
     1162        }
     1163        i = 3; j = 4;                                                   $\C{\color{red}// sv.i, sv.j}$
    11161164}
    11171165\end{cfa}
    … …  
    11221170        struct S1 { ... } s1;
    11231171        struct S2 { ... } s2;
    1124         `with( s1 )` {                                          $\C{// with statement}$
     1172        `with( s1 )` {                                                  $\C{// with statement}$
    11251173                // access fields of s1 without qualification
    1126                 `with( s2 )` {                                  $\C{// nesting}$
     1174                `with( s2 )` {                                          $\C{// nesting}$
    11271175                        // access fields of s1 and s2 without qualification
    11281176                }
    … …  
    11341182\end{cfa}
    11351183
    1136 When opening multiple structures, fields with the same name and type are ambiguous and must be fully qualified.
    1137 For fields with the same name but different type, context/cast can be used to disambiguate.
    1138 \begin{cfa}
    1139 struct S { int i; int j; double m; } a, c;
    1140 struct T { int i; int k; int m } b, c;
    1141 `with( a, b )` {
    1142         j + k;                                                  $\C{// unambiguous, unique names define unique types}$
    1143         i;                                                              $\C{// ambiguous, same name and type}$
    1144         a.i + b.i;                                              $\C{// unambiguous, qualification defines unique names}$
    1145         m;                                                              $\C{// ambiguous, same name and no context to define unique type}$
    1146         m = 5.0;                                                $\C{// unambiguous, same name and context defines unique type}$
    1147         m = 1;                                                  $\C{// unambiguous, same name and context defines unique type}$
    1148 }
    1149 `with( c )` { ... }                                     $\C{// ambiguous, same name and no context}$
    1150 `with( (S)c )` { ... }                                  $\C{// unambiguous, same name and cast defines unique type}$
    1151 \end{cfa}
    1152 
    1153 The components in the "with" clause
    1154 
    1155   with ( a, b, c ) { ... }
    1156 
    1157 serve 2 purposes: each component provides a type and object. The type must be a
    1158 structure type. Enumerations are already opened, and I think a union is opened
    1159 to some extent, too. (Or is that just unnamed unions?) The object is the target
    1160 that the naked structure-fields apply to. The components are open in "parallel"
    1161 at the scope of the "with" clause/statement, so opening "a" does not affect
    1162 opening "b", etc. This semantic is different from Pascal, which nests the
    1163 openings.
    1164 
    1165 Having said the above, it seems reasonable to allow a "with" component to be an
    1166 expression. The type is the static expression-type and the object is the result
    1167 of the expression. Again, the type must be an aggregate. Expressions require
    1168 parenthesis around the components.
    1169 
    1170   with( a, b, c ) { ... }
    1171 
    1172 Does this now make sense?
    1173 
    1174 Having written more CFA code, it is becoming clear to me that I *really* want
    1175 the "with" to be implemented because I hate having to type all those object
    1176 names for fields. It's a great way to drive people away from the language.
    1177 
    11781184
    11791185\subsection{Exception Handling ???}
    … …  
    11901196\subsection{Alternative Declaration Syntax}
    11911197
     1198\newcommand{\R}[1]{\Textbf{#1}}
     1199\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
     1200\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
     1201
     1202C declaration syntax is notoriously confusing and error prone.
     1203For example, many C programmers are confused by a declaration as simple as:
     1204\begin{cquote}
     1205\lstDeleteShortInline@%
     1206\begin{tabular}{@{}ll@{}}
     1207\begin{cfa}
     1208int * x[5]
     1209\end{cfa}
     1210&
     1211\raisebox{-0.75\totalheight}{\input{Cdecl}}
     1212\end{tabular}
     1213\lstMakeShortInline@%
     1214\end{cquote}
     1215Is this an array of 5 pointers to integers or a pointer to an array of 5 integers?
     1216If there is any doubt, it implies productivity and safety issues even for basic programs.
     1217Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site.
     1218For example, a routine returning a pointer to an array of integers is defined and used in the following way:
     1219\begin{cfa}
     1220int `(*`f`())[`5`]` {...};                              $\C{// definition}$
     1221 ... `(*`f`())[`3`]` += 1;                              $\C{// usage}$
     1222\end{cfa}
     1223Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
     1224While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
     1225
     1226\CFA provides its own type, variable and routine declarations, using a different syntax.
     1227The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
     1228In the following example, \R{red} is the base type and \B{blue} is qualifiers.
     1229The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
     1230\begin{cquote}
     1231\lstDeleteShortInline@%
     1232\lstset{moredelim=**[is][\color{blue}]{+}{+}}
     1233\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     1234\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
     1235\begin{cfa}
     1236+[5] *+ `int` x1;
     1237+* [5]+ `int` x2;
     1238+[* [5] int]+ f`( int p )`;
     1239\end{cfa}
     1240&
     1241\begin{cfa}
     1242`int` +*+ x1 +[5]+;
     1243`int` +(*+x2+)[5]+;
     1244+int (*+f`( int p )`+)[5]+;
     1245\end{cfa}
     1246\end{tabular}
     1247\lstMakeShortInline@%
     1248\end{cquote}
     1249The only exception is bit field specification, which always appear to the right of the base type.
     1250% Specifically, the character @*@ is used to indicate a pointer, square brackets @[@\,@]@ are used to represent an array or function return value, and parentheses @()@ are used to indicate a routine parameter.
     1251However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
     1252For instance, variables @x@ and @y@ of type pointer to integer are defined in \CFA as follows:
     1253\begin{cquote}
     1254\lstDeleteShortInline@%
     1255\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     1256\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
     1257\begin{cfa}
     1258`*` int x, y;
     1259\end{cfa}
     1260&
     1261\begin{cfa}
     1262int `*`x, `*`y;
     1263\end{cfa}
     1264\end{tabular}
     1265\lstMakeShortInline@%
     1266\end{cquote}
     1267The downside of this semantics is the need to separate regular and pointer declarations:
     1268\begin{cquote}
     1269\lstDeleteShortInline@%
     1270\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     1271\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
     1272\begin{cfa}
     1273`*` int x;
     1274int y;
     1275\end{cfa}
     1276&
     1277\begin{cfa}
     1278int `*`x, y;
     1279
     1280\end{cfa}
     1281\end{tabular}
     1282\lstMakeShortInline@%
     1283\end{cquote}
     1284which is prescribing a safety benefit.
     1285Other examples are:
     1286\begin{cquote}
     1287\lstDeleteShortInline@%
     1288\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
     1289\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
     1290\begin{cfa}
     1291[ 5 ] int z;
     1292[ 5 ] * char w;
     1293* [ 5 ] double v;
     1294struct s {
     1295        int f0:3;
     1296        * int f1;
     1297        [ 5 ] * int f2;
     1298};
     1299\end{cfa}
     1300&
     1301\begin{cfa}
     1302int z[ 5 ];
     1303char * w[ 5 ];
     1304double (* v)[ 5 ];
     1305struct s {
     1306        int f0:3;
     1307        int * f1;
     1308        int * f2[ 5 ]
     1309};
     1310\end{cfa}
     1311&
     1312\begin{cfa}
     1313// array of 5 integers
     1314// array of 5 pointers to char
     1315// pointer to array of 5 doubles
     1316
     1317// common bit field syntax
     1318
     1319
     1320
     1321\end{cfa}
     1322\end{tabular}
     1323\lstMakeShortInline@%
     1324\end{cquote}
     1325
     1326All type qualifiers, \eg @const@, @volatile@, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
     1327\begin{cquote}
     1328\lstDeleteShortInline@%
     1329\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
     1330\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\
     1331\begin{cfa}
     1332const * const int x;
     1333const * [ 5 ] const int y;
     1334\end{cfa}
     1335&
     1336\begin{cfa}
     1337int const * const x;
     1338const int (* const y)[ 5 ]
     1339\end{cfa}
     1340&
     1341\begin{cfa}
     1342// const pointer to const integer
     1343// const pointer to array of 5 const integers
     1344\end{cfa}
     1345\end{tabular}
     1346\lstMakeShortInline@%
     1347\end{cquote}
     1348All declaration qualifiers, \eg @extern@, @static@, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
     1349The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg:
     1350\begin{cquote}
     1351\lstDeleteShortInline@%
     1352\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
     1353\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
     1354\begin{cfa}
     1355extern [ 5 ] int x;
     1356static * const int y;
     1357\end{cfa}
     1358&
     1359\begin{cfa}
     1360int extern x[ 5 ];
     1361const int static * y;
     1362\end{cfa}
     1363&
     1364\begin{cfa}
     1365// externally visible array of 5 integers
     1366// internally visible pointer to constant int
     1367\end{cfa}
     1368\end{tabular}
     1369\lstMakeShortInline@%
     1370\end{cquote}
     1371
     1372The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine @sizeof@:
     1373\begin{cquote}
     1374\lstDeleteShortInline@%
     1375\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     1376\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
     1377\begin{cfa}
     1378y = (* int)x;
     1379i = sizeof([ 5 ] * int);
     1380\end{cfa}
     1381&
     1382\begin{cfa}
     1383y = (int *)x;
     1384i = sizeof(int * [ 5 ]);
     1385\end{cfa}
     1386\end{tabular}
     1387\lstMakeShortInline@%
     1388\end{cquote}
     1389
     1390Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
     1391Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
     1392Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX-like systems.
     1393
    11921394
    11931395\subsection{References}
    11941396
    1195 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.
    1196 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.
    1197 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.
    1198 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.
    1199 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.
    1200 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 @&?@.
     1397All variables in C have an \newterm{address}, a \newterm{value}, and a \newterm{type};
     1398at 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.
     1399The C type-system does not always track the relationship between a value and its address;
     1400a value that does not have a corresponding address is called a \newterm{rvalue} (for ``right-hand value''), while a value that does have an address is called a \newterm{lvalue} (for ``left-hand value'').
     1401For example, 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.
     1402Despite the nomenclature of ``left-hand'' and ``right-hand'', an expression's classification as lvalue or rvalue is entirely dependent on whether it has an address or not; in imperative programming, the address of a value is used for both reading and writing (mutating) a value, and as such lvalues can be converted to rvalues and read from, but rvalues cannot be mutated because they lack a location to store the updated value.
     1403
     1404Within a lexical scope, lvalue expressions have an \newterm{address interpretation} for writing a value or a \newterm{value interpretation} to read a value.
     1405For example, in @x = y@, @x@ has an address interpretation, while @y@ has a value interpretation.
     1406Though this duality of interpretation is useful, C lacks a direct mechanism to pass lvalues between contexts, instead relying on \newterm{pointer types} to serve a similar purpose.
     1407In C, for any type @T@ there is a pointer type @T *@, the value of which is the address of a value of type @T@.
     1408A pointer rvalue can be explicitly \newterm{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 @&?@.
    12011409
    12021410\begin{cfa}
    12031411int x = 1, y = 2, * p1, * p2, ** p3;
    1204 p1 = &x;  $\C{// p1 points to x}$
    1205 p2 = &y;  $\C{// p2 points to y}$
    1206 p3 = &p1;  $\C{// p3 points to p1}$
     1412p1 = &x;                                                                $\C{// p1 points to x}$
     1413p2 = &y;                                                                $\C{// p2 points to y}$
     1414p3 = &p1;                                                               $\C{// p3 points to p1}$
    12071415*p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
    12081416\end{cfa}
    … …  
    12101418Unfortunately, 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.
    12111419For both brevity and clarity, it would be desirable to have the compiler figure out how to elide the dereference operators in a complex expression such as the assignment to @*p2@ above.
    1212 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.
     1420However, since C defines a number of forms of \newterm{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.
    12131421To 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:
    12141422
    12151423\begin{cfa}
    1216 inx x = 1, y = 2, & r1, & r2, && r3;
     1424int x = 1, y = 2, & r1, & r2, && r3;
    12171425&r1 = &x;  $\C{// r1 points to x}$
    12181426&r2 = &y;  $\C{// r2 points to y}$
    … …  
    12361444This allows \CFA references to be default-initialized (\eg to a null pointer), and also to point to different addresses throughout their lifetime.
    12371445This rebinding is accomplished without adding any new syntax to \CFA, but simply by extending the existing semantics of the address-of operator in C.
     1446
    12381447In 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.
    12391448In \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.
    … …  
    12491458        if @L@ is an lvalue of type {@T &@$_1 \cdots$@ &@$_l$} where $l \ge 0$ references (@&@ symbols) then @&L@ has type {@T `*`&@$_{\color{red}1} \cdots$@ &@$_{\color{red}l}$}, \\ \ie @T@ pointer with $l$ references (@&@ symbols).
    12501459\end{itemize}
    1251 
    12521460Since 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.
    1253 By analogy to pointers, \CFA references also allow cv-qualifiers:
     1461
     1462By analogy to pointers, \CFA references also allow cv-qualifiers such as @const@:
    12541463
    12551464\begin{cfa}
    … …  
    12691478
    12701479More generally, this initialization of references from lvalues rather than pointers is an instance of a ``lvalue-to-reference'' conversion rather than an elision of the address-of operator; this conversion can actually be used in any context in \CFA an implicit conversion would be allowed.
    1271 Similarly, use of a the value pointed to by a reference in an rvalue context can be thought of as a ``reference-to-rvalue'' conversion, and \CFA also includes a qualifier-adding ``reference-to-reference'' conversion, analagous to the @T *@ to @const T *@ conversion in standard C.
     1480Similarly, use of a the value pointed to by a reference in an rvalue context can be thought of as a ``reference-to-rvalue'' conversion, and \CFA also includes a qualifier-adding ``reference-to-reference'' conversion, analogous to the @T *@ to @const T *@ conversion in standard C.
    12721481The final reference conversion included in \CFA is ``rvalue-to-reference'' conversion, implemented by means of an implicit temporary.
    12731482When an rvalue is used to initialize a reference, it is instead used to initialize a hidden temporary value with the same lexical scope as the reference, and the reference is initialized to the address of this temporary.
    12741483This allows complex values to be succinctly and efficiently passed to functions, without the syntactic overhead of explicit definition of a temporary variable or the runtime cost of pass-by-value.
    1275 \CC allows a similar binding, but only for @const@ references; the more general semantics of \CFA are an attempt to avoid the \emph{const hell} problem, in which addition of a @const@ qualifier to one reference requires a cascading chain of added qualifiers.
     1484\CC allows a similar binding, but only for @const@ references; the more general semantics of \CFA are an attempt to avoid the \newterm{const hell} problem, in which addition of a @const@ qualifier to one reference requires a cascading chain of added qualifiers.
     1485
    12761486
    12771487\subsection{Constructors and Destructors}
    … …  
    12791489One 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.
    12801490However, 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.
    1281 \CC is well-known for an approach to manual memory management that addresses both these issues, Resource Aquisition Is Initialization (RAII), implemented by means of special \emph{constructor} and \emph{destructor} functions; we have implemented a similar feature in \CFA.
     1491\CC is well-known for an approach to manual memory management that addresses both these issues, Resource Aquisition Is Initialization (RAII), implemented by means of special \newterm{constructor} and \newterm{destructor} functions; we have implemented a similar feature in \CFA.
    12821492While RAII is a common feature of object-oriented programming languages, its inclusion in \CFA does not violate the design principle that \CFA retain the same procedural paradigm as C.
    12831493In particular, \CFA does not implement class-based encapsulation: neither the constructor nor any other function has privileged access to the implementation details of a type, except through the translation-unit-scope method of opaque structs provided by C.
    … …  
    13111521\end{cfa}
    13121522
    1313 In the example above, a \emph{default constructor} (\ie one with no parameters besides the @this@ parameter) and destructor are defined for the @Array@ struct, a dynamic array of @int@.
    1314 @Array@ is an example of a \emph{managed type} in \CFA, a type with a non-trivial constructor or destructor, or with a field of a managed type.
     1523In the example above, a \newterm{default constructor} (\ie one with no parameters besides the @this@ parameter) and destructor are defined for the @Array@ struct, a dynamic array of @int@.
     1524@Array@ is an example of a \newterm{managed type} in \CFA, a type with a non-trivial constructor or destructor, or with a field of a managed type.
    13151525As in the example, all instances of managed types are implicitly constructed upon allocation, and destructed upon deallocation; this ensures proper initialization and cleanup of resources contained in managed types, in this case the @data@ array on the heap.
    13161526The exact details of the placement of these implicit constructor and destructor calls are omitted here for brevity, the interested reader should consult \cite{Schluntz17}.
    13171527
    13181528Constructor calls are intended to seamlessly integrate with existing C initialization syntax, providing a simple and familiar syntax to veteran C programmers and allowing constructor calls to be inserted into legacy C code with minimal code changes.
    1319 As such, \CFA also provides syntax for \emph{copy initialization} and \emph{initialization parameters}:
     1529As such, \CFA also provides syntax for \newterm{copy initialization} and \newterm{initialization parameters}:
    13201530
    13211531\begin{cfa}
    … …  
    13321542In addition to initialization syntax, \CFA provides two ways to explicitly call constructors and destructors.
    13331543Explicit calls to constructors double as a placement syntax, useful for construction of member fields in user-defined constructors and reuse of large storage allocations.
    1334 While the existing function-call syntax works for explicit calls to constructors and destructors, \CFA also provides a more concise \emph{operator syntax} for both:
     1544While the existing function-call syntax works for explicit calls to constructors and destructors, \CFA also provides a more concise \newterm{operator syntax} for both:
    13351545
    13361546\begin{cfa}
    … …  
    13491559For compatibility with C, a copy constructor from the first union member type is also defined.
    13501560For @struct@ types, each of the four functions are implicitly defined to call their corresponding functions on each member of the struct.
    1351 To better simulate the behaviour of C initializers, a set of \emph{field constructors} is also generated for structures.
     1561To better simulate the behaviour of C initializers, a set of \newterm{field constructors} is also generated for structures.
    13521562A constructor is generated for each non-empty prefix of a structure's member-list which copy-constructs the members passed as parameters and default-constructs the remaining members.
    13531563To allow users to limit the set of constructors available for a type, when a user declares any constructor or destructor, the corresponding generated function and all field constructors for that type are hidden from expression resolution; similarly, the generated default constructor is hidden upon declaration of any constructor.
    … …  
    13551565
    13561566In rare situations user programmers may not wish to have constructors and destructors called; in these cases, \CFA provides an ``escape hatch'' to not call them.
    1357 If a variable is initialized using the syntax \lstinline|S x @= {}| it will be an \emph{unmanaged object}, and will not have constructors or destructors called.
     1567If a variable is initialized using the syntax \lstinline|S x @= {}| it will be an \newterm{unmanaged object}, and will not have constructors or destructors called.
    13581568Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg  \lstinline|Array a @= { 0, 0x0 }|, with the usual C initialization semantics.
    13591569In addition to the expressive power, \lstinline|@=| provides a simple path for migrating legacy C code to \CFA, by providing a mechanism to incrementally convert initializers; the \CFA design team decided to introduce a new syntax for this escape hatch because we believe that our RAII implementation will handle the vast majority of code in a desirable way, and we wished to maintain familiar syntax for this common case.
    … …  
    13641574\section{Literals}
    13651575
     1576C already includes limited polymorphism for literals -- @0@ can be either an integer or a pointer literal, depending on context, while the syntactic forms of literals of the various integer and floating-point types are very similar, differing from each other only in suffix.
     1577In keeping with the general \CFA approach of adding features while respecting ``the C way'' of doing things, we have extended both C's polymorphic zero and typed literal syntax to interoperate with user-defined types, while maintaining a backwards-compatible semantics.
    13661578
    13671579\subsection{0/1}
    13681580
    1369 \TODO{Some text already at the end of Section~\ref{sec:poly-fns}}
    1370 
     1581In C, @0@ has the special property that it is the only ``false'' value; by the standard, any value which compares equal to @0@ is false, while any value that compares unequal to @0@ is true.
     1582As such, an expression @x@ in any boolean context (such as the condition of an @if@ or @while@ statement, or the arguments to an @&&@, @||@, or ternary operator) can be rewritten as @x != 0@ without changing its semantics.
     1583The operator overloading feature of \CFA provides a natural means to implement this truth value comparison for arbitrary types, but the C type system is not precise enough to distinguish an equality comparison with @0@ from an equality comparison with an arbitrary integer or pointer.
     1584To provide this precision, \CFA introduces a new type @zero_t@ as type type of literal @0@ (somewhat analagous to @nullptr_t@ and @nullptr@ in \CCeleven); @zero_t@ can only take the value @0@, but has implicit conversions to the integer and pointer types so that standard C code involving @0@ continues to work properly.
     1585With this addition, the \CFA compiler rewrites @if (x)@ and similar expressions to @if ((x) != 0)@ or the appropriate analogue, and any type @T@ can be made ``truthy'' by defining an operator overload @int ?!=?(T, zero_t)@.
     1586\CC makes types truthy by adding a conversion to @bool@; prior to the addition of explicit cast operators in \CCeleven this approach had the pitfall of making truthy types transitively convertable to any numeric type; our design for \CFA avoids this issue.
     1587
     1588\CFA also includes a special type for @1@, @one_t@; like @zero_t@, @one_t@ has built-in implicit conversions to the various integral types so that @1@ maintains its expected semantics in legacy code.
     1589The addition of @one_t@ allows generic algorithms to handle the unit value uniformly for types where that is meaningful.
     1590\TODO{Make this sentence true} In particular, polymorphic functions in the \CFA prelude define @++x@ and @x++@ in terms of @x += 1@, allowing users to idiomatically define all forms of increment for a type @T@ by defining the single function @T& ?+=(T&, one_t)@; analogous overloads for the decrement operators are present as well.
    13711591
    13721592\subsection{Units}
    … …  
    13971617\end{cfa}
    13981618}%
    1399 
    14001619
    14011620\section{Evaluation}
    … …  
    15731792Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable.
    15741793
    1575 There is ongoing work on a wide range of \CFA feature extensions, including reference types, arrays with size, exceptions, concurrent primitives and modules.
     1794There is ongoing work on a wide range of \CFA feature extensions, including arrays with size, exceptions, concurrent primitives, modules, and user-defined conversions.
    15761795(While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these additional extensions.)
    15771796In addition, there are interesting future directions for the polymorphism design.
Note: See TracChangeset for help on using the changeset viewer.