Changeset d16f9fd for doc/papers/general


Ignore:
Timestamp:
Aug 10, 2018, 8:41:42 AM (6 years ago)
Author:
Peter A. Buhr <pabuhr@…>
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, no_list, persistent-indexer, pthread-emulation, qualifiedEnum
Children:
bd56b07
Parents:
581743f
Message:

changes and corrections to match SPE proofs

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/papers/general/Paper.tex

    r581743f rd16f9fd  
    11\documentclass[AMA,STIX1COL]{WileyNJD-v2}
     2\setlength\typewidth{170mm}
     3\setlength\textwidth{170mm}
    24
    35\articletype{RESEARCH ARTICLE}%
    46
    5 \received{26 April 2016}
    6 \revised{6 June 2016}
    7 \accepted{6 June 2016}
    8 
     7\received{12 March 2018}
     8\revised{8 May 2018}
     9\accepted{28 June 2018}
     10
     11\setlength\typewidth{168mm}
     12\setlength\textwidth{168mm}
    913\raggedbottom
    1014
     
    187191}
    188192
    189 \title{\texorpdfstring{\protect\CFA : Adding Modern Programming Language Features to C}{Cforall : Adding Modern Programming Language Features to C}}
     193\title{\texorpdfstring{\protect\CFA : Adding modern programming language features to C}{Cforall : Adding modern programming language features to C}}
    190194
    191195\author[1]{Aaron Moss}
    192196\author[1]{Robert Schluntz}
    193 \author[1]{Peter A. Buhr*}
     197\author[1]{Peter A. Buhr}
     198\author[]{\textcolor{blue}{Q1 AUTHOR NAMES CORRECT}}
    194199\authormark{MOSS \textsc{et al}}
    195200
    196 \address[1]{\orgdiv{Cheriton School of Computer Science}, \orgname{University of Waterloo}, \orgaddress{\state{Waterloo, ON}, \country{Canada}}}
    197 
    198 \corres{*Peter A. Buhr, Cheriton School of Computer Science, University of Waterloo, 200 University Avenue West, Waterloo, ON, N2L 3G1, Canada. \email{pabuhr{\char`\@}uwaterloo.ca}}
     201\address[1]{\orgdiv{Cheriton School of Computer Science}, \orgname{University of Waterloo}, \orgaddress{\state{Waterloo, Ontario}, \country{Canada}}}
     202
     203\corres{Peter A. Buhr, Cheriton School of Computer Science, University of Waterloo, 200 University Avenue West, Waterloo, ON N2L 3G1, Canada. \email{pabuhr{\char`\@}uwaterloo.ca}}
    199204
    200205\fundingInfo{Natural Sciences and Engineering Research Council of Canada}
    201206
    202207\abstract[Summary]{
    203 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems.
    204 This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
    205 Nevertheless, C, first standardized almost thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
    206 
    207 The goal of the \CFA project (pronounced ``C-for-all'') is to create an extension of C that provides modern safety and productivity features while still ensuring strong backwards compatibility with C and its programmers.
    208 Prior projects have attempted similar goals but failed to honour C programming-style;
    209 for instance, adding object-oriented or functional programming with garbage collection is a non-starter for many C developers.
    210 Specifically, \CFA is designed to have an orthogonal feature-set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code-bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and programmers.
    211 This paper presents a quick tour of \CFA features showing how their design avoids shortcomings of similar features in C and other C-like languages.
     208The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating systems.
     209This installation base and the programmers producing it represent a massive software engineering investment spanning decades and likely to continue for decades more.
     210Nevertheless, C, which was first standardized almost 30 \textcolor{blue}{CHANGE ``40'' TO ``30''} years ago, lacks many features that make programming in more modern languages safer and more productive.
     211The goal of the \CFA project (pronounced ``C for all'') is to create an extension of C that provides modern safety and productivity features while still ensuring strong backward compatibility with C and its programmers.
     212Prior projects have attempted similar goals but failed to honor the C programming style;
     213for instance, adding object-oriented or functional programming with garbage collection is a nonstarter for many C developers.
     214Specifically, \CFA is designed to have an orthogonal feature set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and programmers.
     215This paper presents a quick tour of \CFA features, showing how their design avoids shortcomings of similar features in C and other C-like languages.
    212216Experimental results are presented to validate several of the new features.
    213217}%
    214218
    215 \keywords{generic types, tuple types, variadic types, polymorphic functions, C, Cforall}
     219\keywords{C, Cforall, generic types, polymorphic functions, tuple types, variadic types}
    216220
    217221
    218222\begin{document}
    219 \linenumbers                                            % comment out to turn off line numbering
     223%\linenumbers                                            % comment out to turn off line numbering
    220224
    221225\maketitle
     
    224228\section{Introduction}
    225229
    226 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems.
    227 This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
    228 The TIOBE index~\cite{TIOBE} ranks the top 5 most \emph{popular} programming languages as: Java 15\%, \Textbf{C 12\%}, \Textbf{\CC 5.5\%}, Python 5\%, \Csharp 4.5\% = 42\%, where the next 50 languages are less than 4\% each, with a long tail.
    229 The top 3 rankings over the past 30 years are:
     230The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating systems.
     231This installation base and the programmers producing it represent a massive software engineering investment spanning decades and likely to continue for decades more.
     232The TIOBE index~\cite{TIOBE} \textcolor{blue}{CHANGE ``TIOBE'' TO ``The TIOBE index''} ranks the top five most \emph{popular} programming languages as Java 15\%, \Textbf{C 12\%}, \Textbf{\CC 5.5\%}, and Python 5\%, \Csharp 4.5\% = 42\%, where the next 50 languages are less than 4\% each with a long tail.
     233The top three rankings over the past 30 years are as follows.
     234\newpage
     235\textcolor{blue}{MOVE TABLE HERE}
    230236\begin{center}
    231237\setlength{\tabcolsep}{10pt}
    232 \lstDeleteShortInline@%
    233 \begin{tabular}{@{}rccccccc@{}}
    234                 & 2018  & 2013  & 2008  & 2003  & 1998  & 1993  & 1988  \\ \hline
    235 Java    & 1             & 2             & 1             & 1             & 18    & -             & -             \\
     238\fontsize{9bp}{11bp}\selectfont
     239\lstDeleteShortInline@%
     240\begin{tabular}{@{}cccccccc@{}}
     241                & 2018  & 2013  & 2008  & 2003  & 1998  & 1993  & 1988  \\
     242Java    & 1             & 2             & 1             & 1             & 18    & --    & --    \\
    236243\Textbf{C}& \Textbf{2} & \Textbf{1} & \Textbf{2} & \Textbf{2} & \Textbf{1} & \Textbf{1} & \Textbf{1} \\
    237244\CC             & 3             & 4             & 3             & 3             & 2             & 2             & 5             \\
     
    239246\lstMakeShortInline@%
    240247\end{center}
     248
    241249Love it or hate it, C is extremely popular, highly used, and one of the few systems languages.
    242250In many cases, \CC is often used solely as a better C.
    243 Nevertheless, C, first standardized almost forty years ago~\cite{ANSI89:C}, lacks many features that make programming in more modern languages safer and more productive.
    244 
    245 \CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that adds modern language-features to C, while maintaining source and runtime compatibility in the familiar C programming model.
    246 The four key design goals for \CFA~\cite{Bilson03} are:
    247 (1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;
    248 (2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler;
    249 (3) \CFA code must be at least as portable as standard C code;
    250 (4) Extensions introduced by \CFA must be translated in the most efficient way possible.
    251 These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used.
    252 \CC is used similarly, but has the disadvantages of multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
    253 
    254 All languages features discussed in this paper are working, except some advanced exception-handling features.
    255 Not discussed in this paper are the integrated concurrency-constructs and user-level threading-library~\cite{Delisle18}.
     251Nevertheless, C, which was first standardized almost 30 \textcolor{blue}{CHANGE ``40'' TO ``30''} years ago~\cite{ANSI89:C}, lacks many features that make programming in more modern languages safer and more productive.
     252
     253\CFA (pronounced ``C for all'' and written \CFA or Cforall) is an evolutionary extension of the C programming language that adds modern language features to C, while maintaining source and runtime compatibility in the familiar C programming model.
     254The four key design goals for \CFA~\cite{Bilson03} are as follows:
     255(1) the behavior of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;
     256(2) the standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler;
     257(3) the \CFA code must be at least as portable as standard C code;
     258(4) extensions introduced by \CFA must be translated in the most efficient way possible.
     259These goals ensure that the existing C code bases can be converted into \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used.
     260\CC is used similarly but has the disadvantages of multiple legacy design choices that cannot be updated and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
     261
     262All language features discussed in this paper are working, except some advanced exception-handling features.
     263Not discussed in this paper are the integrated concurrency constructs and user-level threading library~\cite{Delisle18}.
    256264\CFA is an \emph{open-source} project implemented as a source-to-source translator from \CFA to the gcc-dialect of C~\cite{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
    257265% @plg2[9]% cd cfa-cc/src; cloc ArgTweak CodeGen CodeTools Common Concurrency ControlStruct Designators GenPoly InitTweak MakeLibCfa.cc MakeLibCfa.h Parser ResolvExpr SymTab SynTree Tuples driver prelude main.cc
     
    269277% SUM:                           223           8203           8263          46479
    270278% -------------------------------------------------------------------------------
    271 The \CFA translator is 200+ files and 46,000+ lines of code written in C/\CC.
    272 A translator versus a compiler makes it easier and faster to generate and debug C object-code rather than intermediate, assembler or machine code;
     279The \CFA translator is 200+ files and 46\,000+ lines of code written in C/\CC.
     280A translator versus a compiler makes it easier and faster to generate and debug the C object code rather than the intermediate, assembler, or machine code;
    273281ultimately, a compiler is necessary for advanced features and optimal performance.
    274282% The translator design is based on the \emph{visitor pattern}, allowing multiple passes over the abstract code-tree, which works well for incrementally adding new feature through additional visitor passes.
    275283Two key translator components are expression analysis, determining expression validity and what operations are required for its implementation, and code generation, dealing with multiple forms of overloading, polymorphism, and multiple return values by converting them into C code for a C compiler that supports none of these features.
    276 Details of these components are available in Bilson~\cite{Bilson03} Chapters 2 and 3, and form the base for the current \CFA translator.
     284Details of these components are available in chapters 2 and 3 in the work of Bilson~\cite{Bilson03} and form the base for the current \CFA translator.
    277285% @plg2[8]% cd cfa-cc/src; cloc libcfa
    278286% -------------------------------------------------------------------------------
     
    289297% SUM:                           100           1895           2785          11763
    290298% -------------------------------------------------------------------------------
    291 The \CFA runtime system is 100+ files and 11,000+ lines of code, written in \CFA.
     299The \CFA runtime system is 100+ files and 11\,000+ lines of code, written in \CFA.
    292300Currently, the \CFA runtime is the largest \emph{user} of \CFA providing a vehicle to test the language features and implementation.
    293301% @plg2[6]% cd cfa-cc/src; cloc tests examples benchmark
     
    316324
    317325
     326\vspace*{-6pt}
    318327\section{Polymorphic Functions}
    319328
    320 \CFA introduces both ad-hoc and parametric polymorphism to C, with a design originally formalized by Ditchfield~\cite{Ditchfield92}, and first implemented by Bilson~\cite{Bilson03}.
    321 Shortcomings are identified in existing approaches to generic and variadic data types in C-like languages and how these shortcomings are avoided in \CFA.
    322 Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions.
     329\CFA introduces both ad hoc and parametric polymorphism to C, with a design originally formalized by Ditchfield~\cite{Ditchfield92} and first implemented by Bilson~\cite{Bilson03}.
     330Shortcomings are identified in the existing approaches to generic and variadic data types in C-like languages and how these shortcomings are avoided in \CFA.
     331Specifically, the solution is both reusable and type checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions.
    323332The new constructs are empirically compared with C and \CC approaches via performance experiments in Section~\ref{sec:eval}.
    324333
    325334
    326 \subsection{Name Overloading}
     335\vspace*{-6pt}
     336\subsection{Name overloading}
    327337\label{s:NameOverloading}
    328338
    329339\begin{quote}
    330 There are only two hard things in Computer Science: cache invalidation and \emph{naming things} -- Phil Karlton
     340``There are only two hard things in Computer Science: cache invalidation and \emph{naming things}.''---Phil Karlton
    331341\end{quote}
    332342\vspace{-9pt}
    333 C already has a limited form of ad-hoc polymorphism in its basic arithmetic operators, which apply to a variety of different types using identical syntax.
     343C already has a limited form of ad hoc polymorphism in its basic arithmetic operators, which apply to a variety of different types using identical syntax.
    334344\CFA extends the built-in operator overloading by allowing users to define overloads for any function, not just operators, and even any variable;
    335345Section~\ref{sec:libraries} includes a number of examples of how this overloading simplifies \CFA programming relative to C.
    336346Code generation for these overloaded functions and variables is implemented by the usual approach of mangling the identifier names to include a representation of their type, while \CFA decides which overload to apply based on the same ``usual arithmetic conversions'' used in C to disambiguate operator overloads.
    337 As an example:
     347\textcolor{blue}{REMOVE ``We have the following as an example''}
     348\newpage
     349\textcolor{blue}{UPDATE FOLLOWING PROGRAM EXAMPLE WITH ADJUSTED COMMENTS TO FIT PAGE WIDTH.}
    338350\begin{cfa}
    339351int max = 2147483647;                                           $\C[4in]{// (1)}$
     
    341353int max( int a, int b ) { return a < b ? b : a; }  $\C{// (3)}$
    342354double max( double a, double b ) { return a < b ? b : a; }  $\C{// (4)}\CRT$
    343 max( 7, -max );                                         $\C{// uses (3) and (1), by matching int from constant 7}$
     355max( 7, -max );                                         $\C[3in]{// uses (3) and (1), by matching int from constant 7}$
    344356max( max, 3.14 );                                       $\C{// uses (4) and (2), by matching double from constant 3.14}$
    345357max( max, -max );                                       $\C{// ERROR, ambiguous}$
    346 int m = max( max, -max );                       $\C{// uses (3) and (1) twice, by matching return type}$
     358int m = max( max, -max );                       $\C{// uses (3) and (1) twice, by matching return type}\CRT$
    347359\end{cfa}
    348360
     
    353365As is shown later, there are a number of situations where \CFA takes advantage of available type information to disambiguate, where other programming languages generate ambiguities.
    354366
    355 \Celeven added @_Generic@ expressions~\cite[\S~6.5.1.1]{C11}, which is used with preprocessor macros to provide ad-hoc polymorphism;
     367\Celeven added @_Generic@ expressions (see section~6.5.1.1 of the ISO/IEC 9899~\cite{C11}), which is used with preprocessor macros to provide ad hoc polymorphism;
    356368however, this polymorphism is both functionally and ergonomically inferior to \CFA name overloading.
    357 The macro wrapping the generic expression imposes some limitations;
    358 \eg, it cannot implement the example above, because the variables @max@ are ambiguous with the functions @max@.
     369The macro wrapping the generic expression imposes some limitations, for instance, it cannot implement the example above, because the variables @max@ are ambiguous with the functions @max@.
    359370Ergonomic limitations of @_Generic@ include the necessity to put a fixed list of supported types in a single place and manually dispatch to appropriate overloads, as well as possible namespace pollution from the dispatch functions, which must all have distinct names.
    360 \CFA supports @_Generic@ expressions for backwards compatibility, but it is an unnecessary mechanism. \TODO{actually implement that}
     371\CFA supports @_Generic@ expressions for backward compatibility, but it is an unnecessary mechanism.
    361372
    362373% http://fanf.livejournal.com/144696.html
     
    365376
    366377
    367 \subsection{\texorpdfstring{\protect\lstinline{forall} Functions}{forall Functions}}
     378\vspace*{-10pt}
     379\subsection{\texorpdfstring{\protect\lstinline{forall} functions}{forall functions}}
    368380\label{sec:poly-fns}
    369381
    370 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):
     382The 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). \textcolor{blue}{REMOVE ``as follows''}
    371383\begin{cfa}
    372384`forall( otype T )` T identity( T val ) { return val; }
     
    375387This @identity@ function can be applied to any complete \newterm{object type} (or @otype@).
    376388The 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.
    377 The \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.
    378 If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@).
    379 
    380 In \CFA, the polymorphic runtime-cost is spread over each polymorphic call, because more arguments are passed to polymorphic functions;
    381 the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual-function calls.
    382 A design advantage is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat.
    383 
    384 Since 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.
    385 For example, the function @twice@ can be defined using the \CFA syntax for operator overloading:
     389The \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.
     390If this extra information is not needed, for instance, for a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@).
     391
     392In \CFA, the polymorphic runtime cost is spread over each polymorphic call, because more arguments are passed to polymorphic functions;
     393the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual function calls.
     394A design advantage is that, unlike \CC template functions, \CFA polymorphic functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat.
     395
     396Since 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.
     397For example, the function @twice@ can be defined using the \CFA syntax for operator overloading. \textcolor{blue}{REMOVE ``as follows''}
    386398\begin{cfa}
    387399forall( otype T `| { T ?+?(T, T); }` ) T twice( T x ) { return x `+` x; }  $\C{// ? denotes operands}$
    388400int val = twice( twice( 3.7 ) );  $\C{// val == 14}$
    389401\end{cfa}
    390 which works for any type @T@ with a matching addition operator.
    391 The polymorphism is achieved by creating a wrapper function for calling @+@ with @T@ bound to @double@, then passing this function to the first call of @twice@.
    392 There is now the option of using the same @twice@ and converting the result to @int@ on assignment, or creating another @twice@ with type parameter @T@ bound to @int@ because \CFA uses the return type~\cite{Cormack81,Baker82,Ada} in its type analysis.
    393 The first approach has a late conversion from @double@ to @int@ on the final assignment, while the second has an early conversion to @int@.
    394 \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition.
     402This works for any type @T@ with a matching addition operator.
     403The polymorphism is achieved by creating a wrapper function for calling @+@ with the @T@ bound to @double@ and then passing this function to the first call of @twice@.
     404There is now the option of using the same @twice@ and converting the result into @int@ on assignment or creating another @twice@ with the type parameter @T@ bound to @int@ because \CFA uses the return type~\cite{Cormack81,Baker82,Ada} in its type analysis.
     405The first approach has a late conversion from @double@ to @int@ on the final assignment, whereas the second has an early conversion to @int@.
     406\CFA minimizes the number of conversions and their potential to lose information;
     407hence, it selects the first approach, which corresponds with C programmer intuition.
    395408
    396409Crucial to the design of a new programming language are the libraries to access thousands of external software features.
    397 Like \CC, \CFA inherits a massive compatible library-base, where other programming languages must rewrite or provide fragile inter-language communication with C.
    398 A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@ to binary search a sorted float array:
     410Like \CC, \CFA inherits a massive compatible library base, where other programming languages must rewrite or provide fragile interlanguage communication with C.
     411A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@ to binary search a sorted float array. \textcolor{blue}{REMOVE ``as follows''}
    399412\begin{cfa}
    400413void * bsearch( const void * key, const void * base, size_t nmemb, size_t size,
     
    406419double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp ); $\C{// search sorted array}$
    407420\end{cfa}
    408 which can be augmented simply with generalized, type-safe, \CFA-overloaded wrappers:
     421This can be augmented simply with generalized, type-safe, \CFA-overloaded wrappers.
    409422\begin{cfa}
    410423forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) {
     
    420433\end{cfa}
    421434The nested function @comp@ provides the hidden interface from typed \CFA to untyped (@void *@) C, plus the cast of the result.
    422 Providing a hidden @comp@ function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
    423 As well, an alternate kind of return is made available: position versus pointer to found element.
    424 \CC's type-system cannot disambiguate between the two versions of @bsearch@ because it does not use the return type in overload resolution, nor can \CC separately compile a template @bsearch@.
     435% FIX
     436Providing a hidden @comp@ function in \CC is awkward as lambdas do not use C calling conventions and template declarations cannot appear in block scope.
     437In addition, an alternate kind of return is made available: position versus pointer to found element.
     438\CC's type system cannot disambiguate between the two versions of @bsearch@ because it does not use the return type in overload resolution, nor can \CC separately compile a template @bsearch@.
    425439
    426440\CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations (see Section~\ref{sec:libraries}).
     
    432446\end{cfa}
    433447
    434 Call-site inferencing and nested functions provide a localized form of inheritance.
     448Call site inferencing and nested functions provide a localized form of inheritance.
    435449For example, the \CFA @qsort@ only sorts in ascending order using @<@.
    436 However, it is trivial to locally change this behaviour:
     450However, it is trivial to locally change this behavior.
    437451\begin{cfa}
    438452forall( otype T | { int ?<?( T, T ); } ) void qsort( const T * arr, size_t size ) { /* use C qsort */ }
    439453int main() {
    440         int ?<?( double x, double y ) { return x `>` y; } $\C{// locally override behaviour}$
     454        int ?<?( double x, double y ) { return x `>` y; } $\C{// locally override behavior}$
    441455        qsort( vals, 10 );                                                      $\C{// descending sort}$
    442456}
    443457\end{cfa}
    444458The local version of @?<?@ performs @?>?@ overriding the built-in @?<?@ so it is passed to @qsort@.
    445 Hence, programmers can easily form local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
    446 
    447 To reduce duplication, it is possible to distribute a group of @forall@ (and storage-class qualifiers) over functions/types, so each block declaration is prefixed by the group (see example in Appendix~\ref{s:CforallStack}).
     459Therefore, programmers can easily form local environments, adding and modifying appropriate functions, to maximize the reuse of other existing functions and types.
     460
     461To reduce duplication, it is possible to distribute a group of @forall@ (and storage-class qualifiers) over functions/types, such that each block declaration is prefixed by the group (see the example in Appendix~\ref{s:CforallStack}).
    448462\begin{cfa}
    449463forall( otype `T` ) {                                                   $\C{// distribution block, add forall qualifier to declarations}$
     
    456470
    457471
    458 \vspace*{-2pt}
    459472\subsection{Traits}
    460473
    461 \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:
    462 
     474\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.
    463475\begin{cquote}
    464476\lstDeleteShortInline@%
     
    487499\end{cquote}
    488500
    489 Note, the @sumable@ trait does not include a copy constructor needed for the right side of @?+=?@ and return;
    490 it is provided by @otype@, which is syntactic sugar for the following trait:
     501Note that the @sumable@ trait does not include a copy constructor needed for the right side of @?+=?@ and return;
     502it is provided by @otype@, which is syntactic sugar for the following trait.
    491503\begin{cfa}
    492504trait otype( dtype T | sized(T) ) {  // sized is a pseudo-trait for types with known size and alignment
     
    497509};
    498510\end{cfa}
    499 Given 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.
    500 
    501 In 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.
     511Given 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.
     512
     513In 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.
    502514Hence, trait names play no part in type equivalence;
    503515the names are simply macros for a list of polymorphic assertions, which are expanded at usage sites.
    504 Nevertheless, trait names form a logical subtype-hierarchy with @dtype@ at the top, where traits often contain overlapping assertions, \eg operator @+@.
    505 Traits are used like interfaces in Java or abstract base-classes in \CC, but without the nominal inheritance-relationships.
    506 Instead, each polymorphic function (or generic type) defines the structural type needed for its execution (polymorphic type-key), and this key is fulfilled at each call site from the lexical environment, which is similar to Go~\cite{Go} interfaces.
    507 Hence, new lexical scopes and nested functions are used extensively to create local subtypes, as in the @qsort@ example, without having to manage a nominal-inheritance hierarchy.
     516Nevertheless, trait names form a logical subtype hierarchy with @dtype@ at the top, where traits often contain overlapping assertions, \eg operator @+@.
     517Traits are used like interfaces in Java or abstract base classes in \CC, but without the nominal inheritance relationships.
     518Instead, each polymorphic function (or generic type) defines the structural type needed for its execution (polymorphic type key), and this key is fulfilled at each call site from the lexical environment, which is similar to the Go~\cite{Go} interfaces.
     519Hence, new lexical scopes and nested functions are used extensively to create local subtypes, as in the @qsort@ example, without having to manage a nominal inheritance hierarchy.
    508520% (Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.)
    509521
     
    536548
    537549A significant shortcoming of standard C is the lack of reusable type-safe abstractions for generic data structures and algorithms.
    538 Broadly speaking, there are three approaches to implement abstract data-structures in C.
    539 One approach is to write bespoke data-structures for each context in which they are needed.
    540 While this approach is flexible and supports integration with the C type-checker and tooling, it is also tedious and error-prone, especially for more complex data structures.
    541 A second approach is to use @void *@-based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@, which allow reuse of code with common functionality.
    542 However, basing all polymorphism on @void *@ eliminates the type-checker's ability to ensure that argument types are properly matched, often requiring a number of extra function parameters, pointer indirection, and dynamic allocation that is not otherwise needed.
    543 A third approach to generic code is to use preprocessor macros, which does allow the generated code to be both generic and type-checked, but errors may be difficult to interpret.
     550Broadly speaking, there are three approaches to implement abstract data structures in C.
     551One approach is to write bespoke data structures for each context in which they are needed.
     552While this approach is flexible and supports integration with the C type checker and tooling, it is also tedious and error prone, especially for more complex data structures.
     553A second approach is to use @void *@-based polymorphism, \eg the C standard library functions @bsearch@ and @qsort@, which allow for the reuse of code with common functionality.
     554However, basing all polymorphism on @void *@ eliminates the type checker's ability to ensure that argument types are properly matched, often requiring a number of extra function parameters, pointer indirection, and dynamic allocation that is otherwise not needed.
     555A third approach to generic code is to use preprocessor macros, which does allow the generated code to be both generic and type checked, but errors may be difficult to interpret.
    544556Furthermore, writing and using preprocessor macros is unnatural and inflexible.
    545557
    546 \CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data-types.
    547 \CFA generic types integrate efficiently and naturally with the existing polymorphic functions, while retaining backwards compatibility with C and providing separate compilation.
     558\CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data types.
     559\CFA generic types integrate efficiently and naturally with the existing polymorphic functions, while retaining backward compatibility with C and providing separate compilation.
    548560However, for known concrete parameters, the generic-type definition can be inlined, like \CC templates.
    549561
    550 A generic type can be declared by placing a @forall@ specifier on a @struct@ or @union@ declaration, and instantiated using a parenthesized list of types after the type name:
     562A generic type can be declared by placing a @forall@ specifier on a @struct@ or @union@ declaration and instantiated using a parenthesized list of types after the type name.
    551563\begin{cquote}
    552564\lstDeleteShortInline@%
     
    576588
    577589\CFA classifies generic types as either \newterm{concrete} or \newterm{dynamic}.
    578 Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
     590Concrete types have a fixed memory layout regardless of type parameters, whereas dynamic types vary in memory layout depending on their type parameters.
    579591A \newterm{dtype-static} type has polymorphic parameters but is still concrete.
    580592Polymorphic pointers are an example of dtype-static types;
    581 given some type variable @T@, @T@ is a polymorphic type, as is @T *@, but @T *@ has a fixed size and can therefore be represented by @void *@ in code generation.
    582 
    583 \CFA generic types also allow checked argument-constraints.
    584 For example, the following declaration of a sorted set-type ensures the set key supports equality and relational comparison:
     593given some type variable @T@, @T@ is a polymorphic type, as is @T *@, but @T *@ has a fixed size and can, therefore, be represented by @void *@ in code generation.
     594
     595\CFA generic types also allow checked argument constraints.
     596For example, the following declaration of a sorted set type ensures the set key supports equality and relational comparison.
    585597\begin{cfa}
    586598forall( otype Key | { _Bool ?==?(Key, Key); _Bool ?<?(Key, Key); } ) struct sorted_set;
     
    588600
    589601
    590 \subsection{Concrete Generic-Types}
    591 
    592 The \CFA translator template-expands concrete generic-types into new structure types, affording maximal inlining.
    593 To enable inter-operation among equivalent instantiations of a generic type, the translator saves the set of instantiations currently in scope and reuses the generated structure declarations where appropriate.
    594 A function declaration that accepts or returns a concrete generic-type produces a declaration for the instantiated structure in the same scope, which all callers may reuse.
    595 For example, the concrete instantiation for @pair( const char *, int )@ is:
     602\subsection{Concrete generic types}
     603
     604The \CFA translator template expands concrete generic types into new structure types, affording maximal inlining.
     605To enable interoperation among equivalent instantiations of a generic type, the translator saves the set of instantiations currently in scope and reuses the generated structure declarations where appropriate.
     606A function declaration that accepts or returns a concrete generic type produces a declaration for the instantiated structure in the same scope, which all callers may reuse.
     607For example, the concrete instantiation for @pair( const char *, int )@ is \textcolor{blue}{REMOVE ``as follows.''}
    596608\begin{cfa}
    597609struct _pair_conc0 {
     
    600612\end{cfa}
    601613
    602 A concrete generic-type with dtype-static parameters is also expanded to a structure type, but this type is used for all matching instantiations.
    603 In the above example, the @pair( F *, T * )@ parameter to @value@ is such a type; its expansion is below and it is used as the type of the variables @q@ and @r@ as well, with casts for member access where appropriate:
     614A concrete generic type with dtype-static parameters is also expanded to a structure type, but this type is used for all matching instantiations.
     615In the above example, the @pair( F *, T * )@ parameter to @value@ is such a type; its expansion is below, and it is used as the type of the variables @q@ and @r@ as well, with casts for member access where appropriate.
    604616\begin{cfa}
    605617struct _pair_conc1 {
     
    609621
    610622
    611 \subsection{Dynamic Generic-Types}
    612 
    613 Though \CFA implements concrete generic-types efficiently, it also has a fully general system for dynamic generic types.
    614 As 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.
    615 Dynamic generic-types also have an \newterm{offset array} containing structure-member offsets.
    616 A dynamic generic-@union@ needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.
    617 Access 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.
     623\subsection{Dynamic generic types}
     624
     625Though \CFA implements concrete generic types efficiently, it also has a fully general system for dynamic generic types.
     626As 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.
     627Dynamic generic types also have an \newterm{offset array} containing structure-member offsets.
     628A dynamic generic @union@ needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.
     629Access to members of a dynamic structure is provided at runtime via base displacement addressing
     630% FIX
     631using the structure pointer and the member offset (similar to the @offsetof@ macro), moving a compile-time offset calculation to runtime.
    618632
    619633The offset arrays are statically generated where possible.
    620 If a dynamic generic-type is declared to be passed or returned by value from a polymorphic function, the translator can safely assume the generic type is complete (\ie has a known layout) at any call-site, and the offset array is passed from the caller;
     634If a dynamic generic type is declared to be passed or returned by value from a polymorphic function, the translator can safely assume that the generic type is complete (\ie has a known layout) at any call site, and the offset array is passed from the caller;
    621635if the generic type is concrete at the call site, the elements of this offset array can even be statically generated using the C @offsetof@ macro.
    622 As an example, the body of the second @value@ function is implemented as:
     636As an example, the body of the second @value@ function is implemented as \textcolor{blue}{REMOVE ``follows.''}
    623637\begin{cfa}
    624638_assign_T( _retval, p + _offsetof_pair[1] ); $\C{// return *p.second}$
    625639\end{cfa}
    626 @_assign_T@ is passed in as an implicit parameter from @otype T@, and takes two @T *@ (@void *@ in the generated code), a destination and a source; @_retval@ is the pointer to a caller-allocated buffer for the return value, the usual \CFA method to handle dynamically-sized return types.
    627 @_offsetof_pair@ is the offset array passed into @value@; this array is generated at the call site as:
     640\newpage
     641\noindent
     642\textcolor{blue}{NO PARAGRAPH INDENT} Here, @_assign_T@ is passed in as an implicit parameter from @otype T@, and takes two @T *@ (@void *@ in the generated code), a destination and a source, and @_retval@ is the pointer to a caller-allocated buffer for the return value, the usual \CFA method to handle dynamically sized return types.
     643@_offsetof_pair@ is the offset array passed into @value@;
     644this array is generated at the call site as \textcolor{blue}{REMOVE ``follows.''}
    628645\begin{cfa}
    629646size_t _offsetof_pair[] = { offsetof( _pair_conc0, first ), offsetof( _pair_conc0, second ) }
    630647\end{cfa}
    631648
    632 In some cases the offset arrays cannot be statically generated.
    633 For 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.
    634 \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.
     649In some cases, the offset arrays cannot be statically generated.
     650For 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.
     651\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.
    635652The \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.
    636653These 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).
     
    642659Whether a type is concrete, dtype-static, or dynamic is decided solely on the @forall@'s type parameters.
    643660This design allows opaque forward declarations of generic types, \eg @forall(otype T)@ @struct Box@ -- like in C, all uses of @Box(T)@ can be separately compiled, and callers from other translation units know the proper calling conventions to use.
    644 If the definition of a structure type is included in deciding whether a generic type is dynamic or concrete, some further types may be recognized as dtype-static (\eg @forall(otype T)@ @struct unique_ptr { T * p }@ does not depend on @T@ for its layout, but the existence of an @otype@ parameter means that it \emph{could}.), but preserving separate compilation (and the associated C compatibility) in the existing design is judged to be an appropriate trade-off.
     661If the definition of a structure type is included in deciding whether a generic type is dynamic or concrete, some further types may be recognized as dtype-static (\eg @forall(otype T)@ @struct unique_ptr { T * p }@ does not depend on @T@ for its layout, but the existence of an @otype@ parameter means that it \emph{could}.);
     662however, preserving separate compilation (and the associated C compatibility) in the existing design is judged to be an appropriate trade-off.
    645663
    646664
     
    655673}
    656674\end{cfa}
    657 Since @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 members of both pairs and the arguments to the comparison function match in type.
    658 
    659 Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \newterm{tag-structures}.
    660 Sometimes information is only used for type-checking and can be omitted at runtime, \eg:
     675Since @pair( T *, T * )@ is a concrete type, there are no implicit parameters passed to @lexcmp@;
     676hence, the generated code is identical to a function written in standard C using @void *@, yet the \CFA version is type checked to ensure members of both pairs and arguments to the comparison function match in type.
     677
     678Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \newterm{tag structures}.
     679Sometimes, information is only used for type checking and can be omitted at runtime. \textcolor{blue}{REMOVE ``As an example, we have the following''}
    661680\begin{cquote}
    662681\lstDeleteShortInline@%
     
    677696                                                        half_marathon;
    678697scalar(litres) two_pools = pool + pool;
    679 `marathon + pool;`      // ERROR, mismatched types
     698`marathon + pool;` // ERROR, mismatched types
    680699\end{cfa}
    681700\end{tabular}
    682701\lstMakeShortInline@%
    683702\end{cquote}
    684 @scalar@ is a dtype-static type, so all uses have a single structure definition, containing @unsigned long@, and can share the same implementations of common functions like @?+?@.
     703Here, @scalar@ is a dtype-static type;
     704hence, all uses have a single structure definition, containing @unsigned long@, and can share the same implementations of common functions like @?+?@.
    685705These implementations may even be separately compiled, unlike \CC template functions.
    686 However, the \CFA type-checker ensures matching types are used by all calls to @?+?@, preventing nonsensical computations like adding a length to a volume.
     706However, the \CFA type checker ensures matching types are used by all calls to @?+?@, preventing nonsensical computations like adding a length to a volume.
    687707
    688708
     
    690710\label{sec:tuples}
    691711
    692 In many languages, functions can return at most one value;
     712In many languages, functions can return, at most, one value;
    693713however, many operations have multiple outcomes, some exceptional.
    694714Consider C's @div@ and @remquo@ functions, which return the quotient and remainder for a division of integer and float values, respectively.
     
    701721double r = remquo( 13.5, 5.2, &q );                     $\C{// return remainder, alias quotient}$
    702722\end{cfa}
    703 @div@ aggregates the quotient/remainder in a structure, while @remquo@ aliases a parameter to an argument.
     723Here, @div@ aggregates the quotient/remainder in a structure, whereas @remquo@ aliases a parameter to an argument.
    704724Both approaches are awkward.
    705 Alternatively, a programming language can directly support returning multiple values, \eg in \CFA:
     725% FIX
     726Alternatively, a programming language can directly support returning multiple values, \eg \CFA provides the following. \textcolor{blue}{REPLACE ``in \CFA, we have the following'' WITH ``\CFA provides the following''}
    706727\begin{cfa}
    707728[ int, int ] div( int num, int den );           $\C{// return two integers}$
     
    714735This approach is straightforward to understand and use;
    715736therefore, why do few programming languages support this obvious feature or provide it awkwardly?
    716 To answer, there are complex consequences that cascade through multiple aspects of the language, especially the type-system.
    717 This section show these consequences and how \CFA handles them.
     737To answer, there are complex consequences that cascade through multiple aspects of the language, especially the type system.
     738This section shows these consequences and how \CFA handles them.
    718739
    719740
    720741\subsection{Tuple Expressions}
    721742
    722 The addition of multiple-return-value functions (MRVF) are \emph{useless} without a syntax for accepting multiple values at the call-site.
     743The addition of multiple-return-value functions (MRVFs) is \emph{useless} without a syntax for accepting multiple values at the call site.
    723744The simplest mechanism for capturing the return values is variable assignment, allowing the values to be retrieved directly.
    724745As 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}.
    725746
    726 However, 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:
     747However, 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 (SRVFs), \eg, \CFA provides the following. \textcolor{blue}{REPLACE ``As an example, we have the following'' WITH ``\CFA provides the following''}
    727748\begin{cfa}
    728749printf( "%d %d\n", div( 13, 5 ) );                      $\C{// return values seperated into arguments}$
    729750\end{cfa}
    730751Here, the values returned by @div@ are composed with the call to @printf@ by flattening the tuple into separate arguments.
    731 However, the \CFA type-system must support significantly more complex composition:
     752However, the \CFA type-system must support significantly more complex composition.
    732753\begin{cfa}
    733754[ int, int ] foo$\(_1\)$( int );                        $\C{// overloaded foo functions}$
     
    736757`bar`( foo( 3 ), foo( 3 ) );
    737758\end{cfa}
    738 The type-resolver only has the tuple return-types to resolve the call to @bar@ as the @foo@ parameters are identical, which involves unifying the possible @foo@ functions with @bar@'s parameter list.
    739 No combination of @foo@s are an exact match with @bar@'s parameters, so the resolver applies C conversions.
     759The type resolver only has the tuple return types to resolve the call to @bar@ as the @foo@ parameters are identical, which involves unifying the possible @foo@ functions with @bar@'s parameter list.
     760No combination of @foo@s is an exact match with @bar@'s parameters;
     761thus, the resolver applies C conversions.
     762% FIX
    740763The minimal cost is @bar( foo@$_1$@( 3 ), foo@$_2$@( 3 ) )@, giving (@int@, {\color{ForestGreen}@int@}, @double@) to (@int@, {\color{ForestGreen}@double@}, @double@) with one {\color{ForestGreen}safe} (widening) conversion from @int@ to @double@ versus ({\color{red}@double@}, {\color{ForestGreen}@int@}, {\color{ForestGreen}@int@}) to ({\color{red}@int@}, {\color{ForestGreen}@double@}, {\color{ForestGreen}@double@}) with one {\color{red}unsafe} (narrowing) conversion from @double@ to @int@ and two safe conversions.
    741764
    742765
    743 \subsection{Tuple Variables}
     766\subsection{Tuple variables}
    744767
    745768An important observation from function composition is that new variable names are not required to initialize parameters from an MRVF.
    746 \CFA also allows declaration of tuple variables that can be initialized from an MRVF, since it can be awkward to declare multiple variables of different types, \eg:
     769\CFA also allows declaration of tuple variables that can be initialized from an MRVF, since it can be awkward to declare multiple variables of different types.
     770\newpage
    747771\begin{cfa}
    748772[ int, int ] qr = div( 13, 5 );                         $\C{// tuple-variable declaration and initialization}$
    749773[ double, double ] qr = div( 13.5, 5.2 );
    750774\end{cfa}
    751 where the tuple variable-name serves the same purpose as the parameter name(s).
     775Here, the tuple variable name serves the same purpose as the parameter name(s).
    752776Tuple variables can be composed of any types, except for array types, since array sizes are generally unknown in C.
    753777
    754 One way to access the tuple-variable components is with assignment or composition:
     778One way to access the tuple variable components is with assignment or composition.
    755779\begin{cfa}
    756780[ q, r ] = qr;                                                          $\C{// access tuple-variable components}$
    757781printf( "%d %d\n", qr );
    758782\end{cfa}
    759 \CFA also supports \newterm{tuple indexing} to access single components of a tuple expression:
     783\CFA also supports \newterm{tuple indexing} to access single components of a tuple expression. \textcolor{blue}{REMOVE ``as follows''}
    760784\begin{cfa}
    761785[int, int] * p = &qr;                                           $\C{// tuple pointer}$
     
    768792
    769793
    770 \subsection{Flattening and Restructuring}
     794\subsection{Flattening and restructuring}
    771795
    772796In function call contexts, tuples support implicit flattening and restructuring conversions.
    773797Tuple flattening recursively expands a tuple into the list of its basic components.
    774 Tuple structuring packages a list of expressions into a value of tuple type, \eg:
     798Tuple structuring packages a list of expressions into a value of tuple type.
    775799\begin{cfa}
    776800int f( int, int );
     
    783807h( x, y );                                                                      $\C{// flatten and structure}$
    784808\end{cfa}
    785 In the call to @f@, @x@ is implicitly flattened so the components of @x@ are passed as the two arguments.
     809In the call to @f@, @x@ is implicitly flattened so the components of @x@ are passed as two arguments.
    786810In the call to @g@, the values @y@ and @10@ are structured into a single argument of type @[int, int]@ to match the parameter type of @g@.
    787 Finally, in the call to @h@, @x@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component of @x@ and @y@ are structured into the second argument of type @[int, int]@.
    788 The flexible structure of tuples permits a simple and expressive function call syntax to work seamlessly with both SRVF and MRVF, and with any number of arguments of arbitrarily complex structure.
    789 
    790 
    791 \subsection{Tuple Assignment}
     811Finally, in the call to @h@, @x@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component \textcolor{blue}{CHANGE ``components'' TO ``component''} of @x@ and @y@ are structured into the second argument of type @[int, int]@.
     812The flexible structure of tuples permits a simple and expressive function call syntax to work seamlessly with both SRVFs and MRVFs \textcolor{blue}{REMOVE ``and''} with any number of arguments of arbitrarily complex structure.
     813
     814
     815\subsection{Tuple assignment}
    792816
    793817An assignment where the left side is a tuple type is called \newterm{tuple assignment}.
    794 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 \newterm{multiple} and \newterm{mass assignment}, respectively.
     818There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a nontuple type, called \newterm{multiple} and \newterm{mass assignment}, respectively.
    795819\begin{cfa}
    796820int x = 10;
     
    802826[y, x] = 3.14;                                                          $\C{// mass assignment}$
    803827\end{cfa}
    804 Both kinds of tuple assignment have parallel semantics, so that each value on the left and right side is evaluated before any assignments occur.
     828Both kinds of tuple assignment have parallel semantics, so that each value on the left and right sides is evaluated before any assignments occur.
    805829As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function, \eg, @[x, y] = [y, x]@.
    806 This semantics means mass assignment differs from C cascading assignment (\eg @a = b = c@) in that conversions are applied in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment.
    807 For example, @[y, x] = 3.14@ performs the assignments @y = 3.14@ and @x = 3.14@, yielding @y == 3.14@ and @x == 3@;
    808 whereas, C cascading assignment @y = x = 3.14@ performs the assignments @x = 3.14@ and @y = x@, yielding @3@ in @y@ and @x@.
     830This semantics means mass assignment differs from C cascading
     831\newpage
     832assignment (\eg @a = b = c@) in that conversions are applied in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment.
     833For example, @[y, x] = 3.14@ performs the assignments @y = 3.14@ and @x = 3.14@, yielding @y == 3.14@ and @x == 3@, whereas C cascading assignment @y = x = 3.14@ performs the assignments @x = 3.14@ and @y = x@, yielding @3@ in @y@ and @x@.
    809834Finally, tuple assignment is an expression where the result type is the type of the left-hand side of the assignment, just like all other assignment expressions in C.
    810 This example shows mass, multiple, and cascading assignment used in one expression:
     835This example shows mass, multiple, and cascading assignment used in one expression.
    811836\begin{cfa}
    812837[void] f( [int, int] );
     
    815840
    816841
    817 \subsection{Member Access}
    818 
    819 It is also possible to access multiple members from a single expression using a \newterm{member-access}.
    820 The result is a single tuple-valued expression whose type is the tuple of the types of the members, \eg:
     842\subsection{Member access}
     843
     844It is also possible to access multiple members from a single expression using a \newterm{member access}.
     845The result is a single tuple-valued expression whose type is the tuple of the types of the members.
    821846\begin{cfa}
    822847struct S { int x; double y; char * z; } s;
     
    832857[int, int, int] y = x.[2, 0, 2];                        $\C{// duplicate: [y.0, y.1, y.2] = [x.2, x.0.x.2]}$
    833858\end{cfa}
    834 It is also possible for a member access to contain other member accesses, \eg:
     859It is also possible for a member access to contain other member accesses. \textcolor{blue}{REMOVE ``, as follows.''}
    835860\begin{cfa}
    836861struct A { double i; int j; };
     
    899924
    900925Tuples also integrate with \CFA polymorphism as a kind of generic type.
    901 Due to the implicit flattening and structuring conversions involved in argument passing, @otype@ and @dtype@ parameters are restricted to matching only with non-tuple types, \eg:
     926Due to the implicit flattening and structuring conversions involved in argument passing, @otype@ and @dtype@ parameters are restricted to matching only with nontuple types.
    902927\begin{cfa}
    903928forall( otype T, dtype U ) void f( T x, U * y );
    904929f( [5, "hello"] );
    905930\end{cfa}
    906 where @[5, "hello"]@ is flattened, giving argument list @5, "hello"@, and @T@ binds to @int@ and @U@ binds to @const char@.
     931Here, @[5, "hello"]@ is flattened, giving argument list @5, "hello"@, and @T@ binds to @int@ and @U@ binds to @const char@.
    907932Tuples, however, may contain polymorphic components.
    908933For example, a plus operator can be written to sum two triples.
     
    922947g( 5, 10.21 );
    923948\end{cfa}
     949\newpage
    924950Hence, function parameter and return lists are flattened for the purposes of type unification allowing the example to pass expression resolution.
    925951This relaxation is possible by extending the thunk scheme described by Bilson~\cite{Bilson03}.
     
    932958
    933959
    934 \subsection{Variadic Tuples}
     960\subsection{Variadic tuples}
    935961\label{sec:variadic-tuples}
    936962
    937 To define variadic functions, \CFA adds a new kind of type parameter, @ttype@ (tuple type).
    938 Matching against a @ttype@ parameter consumes all remaining argument components and packages them into a tuple, binding to the resulting tuple of types.
    939 In 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.
     963To define variadic functions, \CFA adds a new kind of type parameter, \ie @ttype@ (tuple type).
     964Matching against a @ttype@ parameter consumes all the remaining argument components and packages them into a tuple, binding to the resulting tuple of types.
     965In 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.
    940966As such, @ttype@ variables are also called \newterm{argument packs}.
    941967
     
    943969Since nothing is known about a parameter pack by default, assertion parameters are key to doing anything meaningful.
    944970Unlike variadic templates, @ttype@ polymorphic functions can be separately compiled.
    945 For example, a generalized @sum@ function:
     971For example, the following is a \textcolor{blue}{CHANGE ``As an example, we have the following'' TO ``For example, the following is a''} generalized @sum@ function.
    946972\begin{cfa}
    947973int sum$\(_0\)$() { return 0; }
     
    952978\end{cfa}
    953979Since @sum@\(_0\) does not accept any arguments, it is not a valid candidate function for the call @sum(10, 20, 30)@.
    954 In order to call @sum@\(_1\), @10@ is matched with @x@, and the argument resolution moves on to the argument pack @rest@, which consumes the remainder of the argument list and @Params@ is bound to @[20, 30]@.
     980In order to call @sum@\(_1\), @10@ is matched with @x@, and the argument resolution moves on to the argument pack @rest@, which consumes the remainder of the argument list, and @Params@ is bound to @[20, 30]@.
    955981The process continues until @Params@ is bound to @[]@, requiring an assertion @int sum()@, which matches @sum@\(_0\) and terminates the recursion.
    956982Effectively, this algorithm traces as @sum(10, 20, 30)@ $\rightarrow$ @10 + sum(20, 30)@ $\rightarrow$ @10 + (20 + sum(30))@ $\rightarrow$ @10 + (20 + (30 + sum()))@ $\rightarrow$ @10 + (20 + (30 + 0))@.
    957983
    958 It is reasonable to take the @sum@ function a step further to enforce a minimum number of arguments:
     984It is reasonable to take the @sum@ function a step further to enforce a minimum number of arguments.
    959985\begin{cfa}
    960986int sum( int x, int y ) { return x + y; }
     
    963989}
    964990\end{cfa}
    965 One more step permits the summation of any sumable type with all arguments of the same type:
     991One more step permits the summation of any sumable type with all arguments of the same type.
    966992\begin{cfa}
    967993trait sumable( otype T ) {
     
    9771003Unlike C variadic functions, it is unnecessary to hard code the number and expected types.
    9781004Furthermore, this code is extendable for any user-defined type with a @?+?@ operator.
    979 Summing arbitrary heterogeneous lists is possible with similar code by adding the appropriate type variables and addition operators.
     1005Summing \textcolor{blue}{REMOVE ``up''} arbitrary heterogeneous lists is possible with similar code by adding the appropriate type variables and addition operators.
    9801006
    9811007It is also possible to write a type-safe variadic print function to replace @printf@:
     
    9921018This example showcases a variadic-template-like decomposition of the provided argument list.
    9931019The individual @print@ functions allow printing a single element of a type.
    994 The polymorphic @print@ allows printing any list of types, where as each individual type has a @print@ function.
     1020The polymorphic @print@ allows printing any list of types, where each individual type has a @print@ function.
    9951021The individual print functions can be used to build up more complicated @print@ functions, such as @S@, which cannot be done with @printf@ in C.
    9961022This mechanism is used to seamlessly print tuples in the \CFA I/O library (see Section~\ref{s:IOLibrary}).
    9971023
    9981024Finally, it is possible to use @ttype@ polymorphism to provide arbitrary argument forwarding functions.
    999 For example, it is possible to write @new@ as a library function:
     1025For example, it is possible to write @new@ as a library function.
    10001026\begin{cfa}
    10011027forall( otype R, otype S ) void ?{}( pair(R, S) *, R, S );
     
    10061032\end{cfa}
    10071033The @new@ function provides the combination of type-safe @malloc@ with a \CFA constructor call, making it impossible to forget constructing dynamically allocated objects.
    1008 This function provides the type-safety of @new@ in \CC, without the need to specify the allocated type again, thanks to return-type inference.
     1034This function provides the type safety of @new@ in \CC, without the need to specify the allocated type again, due to return-type inference.
    10091035
    10101036
     
    10121038
    10131039Tuples are implemented in the \CFA translator via a transformation into \newterm{generic types}.
    1014 For each $N$, the first time an $N$-tuple is seen in a scope a generic type with $N$ type parameters is generated, \eg:
     1040For each $N$, the first time an $N$-tuple is seen in a scope, a generic type with $N$ type parameters is generated.
     1041For example, the following \textcolor{blue}{CHANGE ``, as follows:'' TO ``For example, the following''}
    10151042\begin{cfa}
    10161043[int, int] f() {
     
    10191046}
    10201047\end{cfa}
    1021 is transformed into:
     1048is transformed into
    10221049\begin{cfa}
    10231050forall( dtype T0, dtype T1 | sized(T0) | sized(T1) ) struct _tuple2 {
     
    10851112
    10861113The various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions.
    1087 A variable is generated to store the value produced by a statement expression, since its members may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg in a unique expression.
     1114A variable is generated to store the value produced by a statement expression, since its members may need to be constructed with a nontrivial constructor and it may need to be referred to multiple time, \eg in a unique expression.
    10881115The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language.
    10891116However, there are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this restriction is not new.
     
    10931120\section{Control Structures}
    10941121
    1095 \CFA identifies inconsistent, problematic, and missing control structures in C, and extends, modifies, and adds control structures to increase functionality and safety.
    1096 
    1097 
    1098 \subsection{\texorpdfstring{\protect\lstinline@if@ Statement}{if Statement}}
    1099 
    1100 The @if@ expression allows declarations, similar to @for@ declaration expression:
     1122\CFA identifies inconsistent, problematic, and missing control structures in C, as well as extends, modifies, and adds control structures to increase functionality and safety.
     1123
     1124
     1125\subsection{\texorpdfstring{\protect\lstinline@if@ statement}{if statement}}
     1126
     1127The @if@ expression allows declarations, similar to the @for@ declaration expression.
    11011128\begin{cfa}
    11021129if ( int x = f() ) ...                                          $\C{// x != 0}$
     
    11051132\end{cfa}
    11061133Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the @if@ expression, and the results are combined using the logical @&&@ operator.\footnote{\CC only provides a single declaration always compared not equal to 0.}
    1107 The scope of the declaration(s) is local to the @if@ statement but exist within both the ``then'' and ``else'' clauses.
    1108 
    1109 
    1110 \subsection{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}
     1134The scope of the declaration(s) is local to the @if@ statement but exists within both the ``then'' and ``else'' clauses.
     1135
     1136
     1137\subsection{\texorpdfstring{\protect\lstinline@switch@ statement}{switch statement}}
    11111138
    11121139There are a number of deficiencies with the C @switch@ statements: enumerating @case@ lists, placement of @case@ clauses, scope of the switch body, and fall through between case clauses.
    11131140
    1114 C has no shorthand for specifying a list of case values, whether the list is non-contiguous or contiguous\footnote{C provides this mechanism via fall through.}.
    1115 \CFA provides a shorthand for a non-contiguous list:
     1141C has no shorthand for specifying a list of case values, whether the list is noncontiguous or contiguous\footnote{C provides this mechanism via fall through.}.
     1142\CFA provides a shorthand for a noncontiguous list:
    11161143\begin{cquote}
    11171144\lstDeleteShortInline@%
     
    11281155\lstMakeShortInline@%
    11291156\end{cquote}
    1130 for a contiguous list:\footnote{gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, as a space is required after a number, otherwise the first period is a decimal point.}
     1157for a contiguous list:\footnote{gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, as a space is required after a number;
     1158otherwise, the first period is a decimal point.}
    11311159\begin{cquote}
    11321160\lstDeleteShortInline@%
     
    11591187}
    11601188\end{cfa}
    1161 \CFA precludes this form of transfer \emph{into} a control structure because it causes undefined behaviour, especially with respect to missed initialization, and provides very limited functionality.
    1162 
    1163 C allows placement of declaration within the @switch@ body and unreachable code at the start, resulting in undefined behaviour:
     1189\CFA precludes this form of transfer \emph{into} a control structure because it causes an undefined behavior, especially with respect to missed initialization, and provides very limited functionality.
     1190
     1191C allows placement of declaration within the @switch@ body and unreachable code at the start, resulting in an undefined behavior.
    11641192\begin{cfa}
    11651193switch ( x ) {
     
    11781206
    11791207C @switch@ provides multiple entry points into the statement body, but once an entry point is selected, control continues across \emph{all} @case@ clauses until the end of the @switch@ body, called \newterm{fall through};
    1180 @case@ clauses are made disjoint by the @break@ statement.
     1208@case@ clauses are made disjoint by the @break@
     1209\newpage
     1210\noindent
     1211statement.
    11811212While fall through \emph{is} a useful form of control flow, it does not match well with programmer intuition, resulting in errors from missing @break@ statements.
    1182 For backwards compatibility, \CFA provides a \emph{new} control structure, @choose@, which mimics @switch@, but reverses the meaning of fall through (see Figure~\ref{f:ChooseSwitchStatements}), similar to Go.
     1213For backward compatibility, \CFA provides a \emph{new} control structure, \ie @choose@, which mimics @switch@, but reverses the meaning of fall through (see Figure~\ref{f:ChooseSwitchStatements}), similar to Go.
    11831214
    11841215\begin{figure}
    11851216\centering
     1217\fontsize{9bp}{11bp}\selectfont
    11861218\lstDeleteShortInline@%
    11871219\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
     
    12201252\end{tabular}
    12211253\lstMakeShortInline@%
    1222 \caption{\lstinline|choose| versus \lstinline|switch| Statements}
     1254\caption{\lstinline|choose| versus \lstinline|switch| statements}
    12231255\label{f:ChooseSwitchStatements}
     1256\vspace*{-11pt}
    12241257\end{figure}
    12251258
    1226 Finally, Figure~\ref{f:FallthroughStatement} shows @fallthrough@ may appear in contexts other than terminating a @case@ clause, and have an explicit transfer label allowing separate cases but common final-code for a set of cases.
     1259Finally, Figure~\ref{f:FallthroughStatement} shows @fallthrough@ may appear in contexts other than terminating a @case@ clause and have an explicit transfer label allowing separate cases but common final code for a set of cases.
    12271260The target label must be below the @fallthrough@ and may not be nested in a control structure, \ie @fallthrough@ cannot form a loop, and the target label must be at the same or higher level as the containing @case@ clause and located at the same level as a @case@ clause;
    12281261the target label may be case @default@, but only associated with the current @switch@/@choose@ statement.
     
    12301263\begin{figure}
    12311264\centering
     1265\fontsize{9bp}{11bp}\selectfont
    12321266\lstDeleteShortInline@%
    12331267\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
     
    12581292\end{tabular}
    12591293\lstMakeShortInline@%
    1260 \caption{\lstinline|fallthrough| Statement}
     1294\caption{\lstinline|fallthrough| statement}
    12611295\label{f:FallthroughStatement}
     1296\vspace*{-11pt}
    12621297\end{figure}
    12631298
    12641299
    1265 \subsection{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
     1300\vspace*{-8pt}
     1301\subsection{\texorpdfstring{Labeled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labeled continue / break}}
    12661302
    12671303While C provides @continue@ and @break@ statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
    1268 Unfortunately, this restriction forces programmers to use @goto@ to achieve the equivalent control-flow for more than one level of nesting.
    1269 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.
     1304Unfortunately, this restriction forces programmers to use @goto@ to achieve the equivalent control flow for more than one level of nesting.
     1305To prevent having to switch to the @goto@, \CFA extends @continue@ and @break@ with a target label to support static multilevel exit~\cite{Buhr85}, as in Java.
    12701306For both @continue@ and @break@, the target label must be directly associated with a @for@, @while@ or @do@ statement;
    12711307for @break@, the target label can also be associated with a @switch@, @if@ or compound (@{}@) statement.
    1272 Figure~\ref{f:MultiLevelExit} shows @continue@ and @break@ indicating the specific control structure, and the corresponding C program using only @goto@ and labels.
    1273 The innermost loop has 7 exit points, which cause continuation or termination of one or more of the 7 nested control-structures.
     1308Figure~\ref{f:MultiLevelExit} shows @continue@ and @break@ indicating the specific control structure and the corresponding C program using only @goto@ and labels.
     1309The innermost loop has seven exit points, which cause a continuation or termination of one or more of the seven nested control structures.
    12741310
    12751311\begin{figure}
     1312\fontsize{9bp}{11bp}\selectfont
    12761313\lstDeleteShortInline@%
    12771314\begin{tabular}{@{\hspace{\parindentlnth}}l|@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
     
    13381375\end{tabular}
    13391376\lstMakeShortInline@%
    1340 \caption{Multi-level Exit}
     1377\caption{Multilevel exit}
    13411378\label{f:MultiLevelExit}
     1379\vspace*{-5pt}
    13421380\end{figure}
    13431381
    1344 With respect to safety, both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:
    1345 \begin{itemize}
     1382With respect to safety, both labeled @continue@ and @break@ are @goto@ restricted in the following ways.
     1383\begin{list}{$\bullet$}{\topsep=4pt\itemsep=0pt\parsep=0pt}
    13461384\item
    13471385They cannot create a loop, which means only the looping constructs cause looping.
     
    13491387\item
    13501388They cannot branch into a control structure.
    1351 This restriction prevents missing declarations and/or initializations at the start of a control structure resulting in undefined behaviour.
    1352 \end{itemize}
    1353 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.
    1354 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.
     1389This restriction prevents missing declarations and/or initializations at the start of a control structure resulting in an undefined behavior.
     1390\end{list}
     1391The advantage of the labeled @continue@/@break@ is allowing static multilevel 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.
     1392Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader (eye candy) that complex control flow is
     1393occurring in the body of the control structure.
    13551394With @goto@, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
    1356 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.
     1395Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting the existing constructs.
    13571396Otherwise, the implicit targets of the current @continue@ and @break@, \ie the closest enclosing loop or @switch@, change as certain constructs are added or removed.
    13581397
    13591398
    1360 \subsection{Exception Handling}
    1361 
    1362 The following framework for \CFA exception-handling is in place, excluding some runtime type-information and virtual functions.
     1399\vspace*{-5pt}
     1400\subsection{Exception handling}
     1401
     1402The following framework for \CFA exception handling is in place, excluding some runtime type information and virtual functions.
    13631403\CFA provides two forms of exception handling: \newterm{fix-up} and \newterm{recovery} (see Figure~\ref{f:CFAExceptionHandling})~\cite{Buhr92b,Buhr00a}.
    1364 Both mechanisms provide dynamic call to a handler using dynamic name-lookup, where fix-up has dynamic return and recovery has static return from the handler.
     1404Both mechanisms provide dynamic call to a handler using dynamic name lookup, where fix-up has dynamic return and recovery has static return from the handler.
    13651405\CFA restricts exception types to those defined by aggregate type @exception@.
    13661406The form of the raise dictates the set of handlers examined during propagation: \newterm{resumption propagation} (@resume@) only examines resumption handlers (@catchResume@); \newterm{terminating propagation} (@throw@) only examines termination handlers (@catch@).
    1367 If @resume@ or @throw@ have no exception type, it is a reresume/rethrow, meaning the currently exception continues propagation.
     1407If @resume@ or @throw@ has no exception type, it is a reresume/rethrow, which means that the current exception continues propagation.
    13681408If there is no current exception, the reresume/rethrow results in a runtime error.
    13691409
    13701410\begin{figure}
     1411\fontsize{9bp}{11bp}\selectfont
     1412\lstDeleteShortInline@%
    13711413\begin{cquote}
    1372 \lstDeleteShortInline@%
    13731414\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
    13741415\multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{Resumption}}   & \multicolumn{1}{c@{}}{\textbf{Termination}}   \\
     
    14011442\end{cfa}
    14021443\end{tabular}
    1403 \lstMakeShortInline@%
    14041444\end{cquote}
    1405 \caption{\CFA Exception Handling}
     1445\lstMakeShortInline@%
     1446\caption{\CFA exception handling}
    14061447\label{f:CFAExceptionHandling}
     1448\vspace*{-5pt}
    14071449\end{figure}
    14081450
    1409 The set of exception types in a list of catch clause may include both a resumption and termination handler:
     1451The set of exception types in a list of catch clauses may include both a resumption and a termination handler.
    14101452\begin{cfa}
    14111453try {
     
    14211463The termination handler is available because the resumption propagation did not unwind the stack.
    14221464
    1423 An additional feature is conditional matching in a catch clause:
     1465An additional feature is conditional matching in a catch clause.
    14241466\begin{cfa}
    14251467try {
     
    14301472   catch ( IOError err ) { ... }                        $\C{// handler error from other files}$
    14311473\end{cfa}
    1432 where the throw inserts the failing file-handle into the I/O exception.
    1433 Conditional catch cannot be trivially mimicked by other mechanisms because once an exception is caught, handler clauses in that @try@ statement are no longer eligible..
    1434 
    1435 The resumption raise can specify an alternate stack on which to raise an exception, called a \newterm{nonlocal raise}:
     1474Here, the throw inserts the failing file handle into the I/O exception.
     1475Conditional catch cannot be trivially mimicked by other mechanisms because once an exception is caught, handler clauses in that @try@ statement are no longer eligible.
     1476
     1477The resumption raise can specify an alternate stack on which to raise an exception, called a \newterm{nonlocal raise}.
    14361478\begin{cfa}
    14371479resume( $\emph{exception-type}$, $\emph{alternate-stack}$ )
     
    14411483Nonlocal raise is restricted to resumption to provide the exception handler the greatest flexibility because processing the exception does not unwind its stack, allowing it to continue after the handler returns.
    14421484
    1443 To facilitate nonlocal raise, \CFA provides dynamic enabling and disabling of nonlocal exception-propagation.
    1444 The constructs for controlling propagation of nonlocal exceptions are the @enable@ and the @disable@ blocks:
     1485To facilitate nonlocal raise, \CFA provides dynamic enabling and disabling of nonlocal exception propagation.
     1486The constructs for controlling propagation of nonlocal exceptions are the @enable@ and @disable@ blocks.
    14451487\begin{cquote}
    14461488\lstDeleteShortInline@%
     
    14481490\begin{cfa}
    14491491enable $\emph{exception-type-list}$ {
    1450         // allow non-local raise
     1492        // allow nonlocal raise
    14511493}
    14521494\end{cfa}
     
    14541496\begin{cfa}
    14551497disable $\emph{exception-type-list}$ {
    1456         // disallow non-local raise
     1498        // disallow nonlocal raise
    14571499}
    14581500\end{cfa}
     
    14621504The arguments for @enable@/@disable@ specify the exception types allowed to be propagated or postponed, respectively.
    14631505Specifying no exception type is shorthand for specifying all exception types.
    1464 Both @enable@ and @disable@ blocks can be nested, turning propagation on/off on entry, and on exit, the specified exception types are restored to their prior state.
    1465 Coroutines and tasks start with non-local exceptions disabled, allowing handlers to be put in place, before non-local exceptions are explicitly enabled.
     1506Both @enable@ and @disable@ blocks can be nested;
     1507turning propagation on/off on entry and on exit, the specified exception types are restored to their prior state.
     1508Coroutines and tasks start with nonlocal exceptions disabled, allowing handlers to be put in place, before nonlocal exceptions are explicitly enabled.
    14661509\begin{cfa}
    14671510void main( mytask & t ) {                                       $\C{// thread starts here}$
    1468         // non-local exceptions disabled
    1469         try {                                                                   $\C{// establish handles for non-local exceptions}$
    1470                 enable {                                                        $\C{// allow non-local exception delivery}$
     1511        // nonlocal exceptions disabled
     1512        try {                                                                   $\C{// establish handles for nonlocal exceptions}$
     1513                enable {                                                        $\C{// allow nonlocal exception delivery}$
    14711514                        // task body
    14721515                }
     
    14761519\end{cfa}
    14771520
    1478 Finally, \CFA provides a Java like  @finally@ clause after the catch clauses:
     1521\textcolor{blue}{PARAGRAPH INDENT} Finally, \CFA provides a Java-like  @finally@ clause after the catch clauses.
    14791522\begin{cfa}
    14801523try {
     
    14851528}
    14861529\end{cfa}
    1487 The finally clause is always executed, i.e., if the try block ends normally or if an exception is raised.
     1530The finally clause is always executed, \ie, if the try block ends normally or if an exception is raised.
    14881531If an exception is raised and caught, the handler is run before the finally clause.
    14891532Like a destructor (see Section~\ref{s:ConstructorsDestructors}), a finally clause can raise an exception but not if there is an exception being propagated.
    1490 Mimicking the @finally@ clause with mechanisms like RAII is non-trivial when there are multiple types and local accesses.
    1491 
    1492 
    1493 \subsection{\texorpdfstring{\protect\lstinline{with} Statement}{with Statement}}
     1533Mimicking the @finally@ clause with mechanisms like Resource Aquisition Is Initialization (RAII) is nontrivial when there are multiple types and local accesses.
     1534
     1535
     1536\subsection{\texorpdfstring{\protect\lstinline{with} statement}{with statement}}
    14941537\label{s:WithStatement}
    14951538
    1496 Heterogeneous data is often aggregated into a structure/union.
    1497 To reduce syntactic noise, \CFA provides a @with@ statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate member-qualification by opening a scope containing the member identifiers.
     1539Heterogeneous data are often aggregated into a structure/union.
     1540To reduce syntactic noise, \CFA provides a @with@ statement (see section~4.F in the Pascal User Manual and Report~\cite{Pascal}) to elide aggregate member qualification by opening a scope containing the member identifiers.
    14981541\begin{cquote}
    14991542\vspace*{-\baselineskip}%???
     
    15231566Object-oriented programming languages only provide implicit qualification for the receiver.
    15241567
    1525 In detail, the @with@ statement has the form:
     1568In detail, the @with@ statement has the form
    15261569\begin{cfa}
    15271570$\emph{with-statement}$:
     
    15291572\end{cfa}
    15301573and may appear as the body of a function or nested within a function body.
    1531 Each expression in the expression-list provides a type and object.
     1574Each expression in the expression list provides a type and object.
    15321575The type must be an aggregate type.
    15331576(Enumerations are already opened.)
    1534 The object is the implicit qualifier for the open structure-members.
     1577The object is the implicit qualifier for the open structure members.
    15351578
    15361579All expressions in the expression list are open in parallel within the compound statement, which is different from Pascal, which nests the openings from left to right.
    1537 The difference between parallel and nesting occurs for members with the same name and type:
     1580The difference between parallel and nesting occurs for members with the same name and type.
    15381581\begin{cfa}
    15391582struct S { int `i`; int j; double m; } s, w;    $\C{// member i has same type in structure types S and T}$
     
    15491592}
    15501593\end{cfa}
    1551 For parallel semantics, both @s.i@ and @t.i@ are visible, so @i@ is ambiguous without qualification;
    1552 for nested semantics, @t.i@ hides @s.i@, so @i@ implies @t.i@.
     1594For parallel semantics, both @s.i@ and @t.i@ are visible and, therefore, @i@ is ambiguous without qualification;
     1595for nested semantics, @t.i@ hides @s.i@ and, therefore, @i@ implies @t.i@.
    15531596\CFA's ability to overload variables means members with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates.
    15541597Qualification or a cast is used to disambiguate.
    15551598
    1556 There is an interesting problem between parameters and the function-body @with@, \eg:
     1599There is an interesting problem between parameters and the function body @with@.
    15571600\begin{cfa}
    15581601void ?{}( S & s, int i ) with ( s ) {           $\C{// constructor}$
     
    15601603}
    15611604\end{cfa}
    1562 Here, the assignment @s.i = i@ means @s.i = s.i@, which is meaningless, and there is no mechanism to qualify the parameter @i@, making the assignment impossible using the function-body @with@.
    1563 To solve this problem, parameters are treated like an initialized aggregate:
     1605Here, the assignment @s.i = i@ means @s.i = s.i@, which is meaningless, and there is no mechanism to qualify the parameter @i@, making the assignment impossible using the function body @with@.
     1606To solve this problem, parameters are treated like an initialized aggregate
    15641607\begin{cfa}
    15651608struct Params {
     
    15681611} params;
    15691612\end{cfa}
    1570 and implicitly opened \emph{after} a function-body open, to give them higher priority:
     1613\newpage
     1614and implicitly opened \emph{after} a function body open, to give them higher priority
    15711615\begin{cfa}
    15721616void ?{}( S & s, int `i` ) with ( s ) `{` `with( $\emph{\color{red}params}$ )` {
     
    15741618} `}`
    15751619\end{cfa}
    1576 Finally, a cast may be used to disambiguate among overload variables in a @with@ expression:
     1620Finally, a cast may be used to disambiguate among overload variables in a @with@ expression
    15771621\begin{cfa}
    15781622with ( w ) { ... }                                                      $\C{// ambiguous, same name and no context}$
    15791623with ( (S)w ) { ... }                                           $\C{// unambiguous, cast}$
    15801624\end{cfa}
    1581 and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
     1625and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate
    15821626\begin{cfa}
    15831627struct S { int i, j; } sv;
     
    16031647\CFA attempts to correct and add to C declarations, while ensuring \CFA subjectively ``feels like'' C.
    16041648An important part of this subjective feel is maintaining C's syntax and procedural paradigm, as opposed to functional and object-oriented approaches in other systems languages such as \CC and Rust.
    1605 Maintaining the C approach means that C coding-patterns remain not only useable but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
     1649Maintaining the C approach means that C coding patterns remain not only useable but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
    16061650Nevertheless, some features from other approaches are undeniably convenient;
    16071651\CFA attempts to adapt these features to the C paradigm.
    16081652
    16091653
    1610 \subsection{Alternative Declaration Syntax}
     1654\subsection{Alternative declaration syntax}
    16111655
    16121656C declaration syntax is notoriously confusing and error prone.
    1613 For example, many C programmers are confused by a declaration as simple as:
     1657For example, many C programmers are confused by a declaration as simple as the following. \textcolor{blue}{CHANGE ``simple a declaration as in'' TO ``declaration as simple as''}
    16141658\begin{cquote}
    16151659\lstDeleteShortInline@%
     
    16231667\lstMakeShortInline@%
    16241668\end{cquote}
    1625 Is this an array of 5 pointers to integers or a pointer to an array of 5 integers?
     1669Is this an array of five pointers to integers or a pointer to an array of five integers?
    16261670If there is any doubt, it implies productivity and safety issues even for basic programs.
    16271671Another example of confusion results from the fact that a function name and its parameters are embedded within the return type, mimicking the way the return value is used at the function's call site.
    1628 For example, a function returning a pointer to an array of integers is defined and used in the following way:
     1672For example, a function returning a pointer to an array of integers is defined and used in the following way.
    16291673\begin{cfa}
    16301674int `(*`f`())[`5`]` {...};                                      $\C{// definition}$
     
    16341678While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
    16351679
    1636 \CFA provides its own type, variable and function declarations, using a different syntax~\cite[pp.~856--859]{Buhr94a}.
    1637 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right.
     1680\newpage
     1681\CFA provides its own type, variable, and function declarations, using a different syntax~\cite[pp.~856--859]{Buhr94a}.
     1682The new declarations place qualifiers to the left of the base type, whereas C declarations place qualifiers to the right.
    16381683The qualifiers have the same meaning but are ordered left to right to specify a variable's type.
    16391684\begin{cquote}
     
    16611706\lstMakeShortInline@%
    16621707\end{cquote}
    1663 The only exception is bit-field specification, which always appear to the right of the base type.
     1708The only exception is bit-field specification, which always appears to the right of the base type.
    16641709% 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 function parameter.
    16651710However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
    1666 For instance, variables @x@ and @y@ of type pointer to integer are defined in \CFA as follows:
     1711For instance, variables @x@ and @y@ of type pointer to integer are defined in \CFA as \textcolor{blue}{REMOVE ``follows.''}
    16671712\begin{cquote}
    16681713\lstDeleteShortInline@%
     
    17271772\end{comment}
    17281773
    1729 All specifiers (@extern@, @static@, \etc) and qualifiers (@const@, @volatile@, \etc) are used in the normal way with the new declarations and also appear left to right, \eg:
     1774All specifiers (@extern@, @static@, \etc) and qualifiers (@const@, @volatile@, \etc) are used in the normal way with the new declarations and also appear left to right.
    17301775\begin{cquote}
    17311776\lstDeleteShortInline@%
    17321777\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    17331778\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
    1734 \begin{cfa}
     1779\begin{cfa}[basicstyle=\linespread{0.9}\fontsize{9bp}{12bp}\selectfont\sf]
    17351780extern const * const int x;
    17361781static const * [5] const int y;
    17371782\end{cfa}
    17381783&
    1739 \begin{cfa}
     1784\begin{cfa}[basicstyle=\linespread{0.9}\fontsize{9bp}{12bp}\selectfont\sf]
    17401785int extern const * const x;
    17411786static const int (* const y)[5]
    17421787\end{cfa}
    17431788&
    1744 \begin{cfa}
     1789\begin{cfa}[basicstyle=\linespread{0.9}\fontsize{9bp}{12bp}\selectfont\sf]
    17451790// external const pointer to const int
    17461791// internal const pointer to array of 5 const int
     
    17501795\end{cquote}
    17511796Specifiers must appear at the start of a \CFA function declaration\footnote{\label{StorageClassSpecifier}
    1752 The 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}}.
     1797The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature (see section~6.11.5(1) in ISO/IEC 9899~\cite{C11}).}.
    17531798
    17541799The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-function @sizeof@:
     
    17711816
    17721817The syntax of the new function-prototype declaration follows directly from the new function-definition syntax;
    1773 as well, parameter names are optional, \eg:
     1818also, parameter names are optional.
    17741819\begin{cfa}
    17751820[ int x ] f ( /* void */ );             $\C[2.5in]{// returning int with no parameters}$
     
    17791824[ * int, int ] j ( int );               $\C{// returning pointer to int and int with int parameter}$
    17801825\end{cfa}
    1781 This syntax allows a prototype declaration to be created by cutting and pasting source text from the function-definition header (or vice versa).
    1782 Like C, it is possible to declare multiple function-prototypes in a single declaration, where the return type is distributed across \emph{all} function names in the declaration list, \eg:
     1826This syntax allows a prototype declaration to be created by cutting and pasting the source text from the function-definition header (or vice versa).
     1827Like C, it is possible to declare multiple function prototypes in a single declaration, where the return type is distributed across \emph{all} function names in the declaration list.
    17831828\begin{cquote}
    17841829\lstDeleteShortInline@%
     
    17951840\lstMakeShortInline@%
    17961841\end{cquote}
    1797 where \CFA allows the last function in the list to define its body.
    1798 
    1799 The syntax for pointers to \CFA functions specifies the pointer name on the right, \eg:
     1842Here, \CFA allows the last function in the list to define its body.
     1843
     1844The syntax for pointers to \CFA functions specifies the pointer name on the right.
    18001845\begin{cfa}
    18011846* [ int x ] () fp;                              $\C{// pointer to function returning int with no parameters}$
     
    18041849* [ * int, int ] ( int ) jp;    $\C{// pointer to function returning pointer to int and int with int parameter}\CRT$
    18051850\end{cfa}
    1806 Note, the name of the function pointer is specified last, as for other variable declarations.
    1807 
    1808 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
    1809 Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
    1810 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX-like systems.
     1851\newpage
     1852\noindent
     1853Note that the name of the function pointer is specified last, as for other variable declarations.
     1854
     1855Finally, new \CFA declarations may appear together with C declarations in the same program block but cannot be mixed within a specific declaration.
     1856Therefore, a programmer has the option of either continuing to use traditional C declarations or taking advantage of the new style.
     1857Clearly, both styles need to be supported for some time due to existing C-style header files, particularly for UNIX-like systems.
    18111858
    18121859
     
    18161863All variables in C have an \newterm{address}, a \newterm{value}, and a \newterm{type};
    18171864at 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.
    1818 The C type-system does not always track the relationship between a value and its address;
    1819 a 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'').
    1820 For 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.
    1821 Despite 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.
     1865The C type system does not always track the relationship between a value and its address;
     1866a value that does not have a corresponding address is called an \newterm{rvalue} (for ``right-hand value''), whereas a value that does have an address is called an \newterm{lvalue} (for ``left-hand value'').
     1867For example, in @int x; x = 42;@ the variable expression @x@ on the left-hand side of the assignment is an lvalue, whereas the constant expression @42@ on the right-hand side of the assignment is an rvalue.
     1868Despite the nomenclature of ``left-hand'' and ``right-hand'', an expression's classification as an lvalue or an 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 into rvalues and read from, but rvalues cannot be mutated because they lack a location to store the updated value.
    18221869
    18231870Within a lexical scope, lvalue expressions have an \newterm{address interpretation} for writing a value or a \newterm{value interpretation} to read a value.
    1824 For example, in @x = y@, @x@ has an address interpretation, while @y@ has a value interpretation.
     1871For example, in @x = y@, @x@ has an address interpretation, whereas @y@ has a value interpretation.
    18251872While 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.
    18261873In C, for any type @T@ there is a pointer type @T *@, the value of which is the address of a value of type @T@.
    1827 A 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 @&?@.
    1828 
     1874A pointer rvalue can be explicitly \newterm{dereferenced} to the pointed-to lvalue with the dereference operator @*?@, whereas the rvalue representing the address of an lvalue can be obtained with the address-of operator @&?@.
    18291875\begin{cfa}
    18301876int x = 1, y = 2, * p1, * p2, ** p3;
     
    18341880*p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
    18351881\end{cfa}
    1836 
    18371882Unfortunately, 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 because of pointer arithmetic.
    18381883For both brevity and clarity, it is desirable for the compiler to figure out how to elide the dereference operators in a complex expression such as the assignment to @*p2@ above.
    1839 However, 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 programmer may write one when they mean the other, and precluding any simple algorithm for elision of dereference operators.
     1884However, 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 programmer may write one when they mean the other and precluding any simple algorithm for elision of dereference operators.
    18401885To solve these problems, \CFA introduces reference types @T &@;
    1841 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:
    1842 
     1886a @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.
    18431887\begin{cfa}
    18441888int x = 1, y = 2, & r1, & r2, && r3;
     
    18481892r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);       $\C{// implicit dereferencing}$
    18491893\end{cfa}
    1850 
    18511894Except for auto-dereferencing by the compiler, this reference example is exactly the same as the previous pointer example.
    1852 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.
    1853 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:
    1854 
     1895Hence, a reference behaves like a variable name---an lvalue expression that is interpreted as a value---but also has the type system track the address of that value.
     1896One 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;
     1897thus, the previous example implicitly acts like the following.
    18551898\begin{cfa}
    18561899`*`r2 = ((`*`r1 + `*`r2) * (`**`r3 - `*`r1)) / (`**`r3 - 15);
    18571900\end{cfa}
    1858 
    18591901References in \CFA are similar to those in \CC, with important improvements, which can be seen in the example above.
    18601902Firstly, \CFA does not forbid references to references.
    1861 This provides a much more orthogonal design for library implementors, obviating the need for workarounds such as @std::reference_wrapper@.
     1903This provides a much more orthogonal design for library \mbox{implementors}, obviating the need for workarounds such as @std::reference_wrapper@.
    18621904Secondly, \CFA references are rebindable, whereas \CC references have a fixed address.
    1863 Rebinding allows \CFA references to be default-initialized (\eg to a null pointer\footnote{
    1864 While effort has been made into non-null reference checking in \CC and Java, the exercise seems moot for any non-managed languages (C/\CC), given that it only handles one of many different error situations, \eg using a pointer after its storage is deleted.}) and point to different addresses throughout their lifetime, like pointers.
     1905Rebinding allows \CFA references to be default initialized (\eg to a null pointer\footnote{
     1906While effort has been made into non-null reference checking in \CC and Java, the exercise seems moot for any nonmanaged languages (C/\CC), given that it only handles one of many different error situations, \eg using a pointer after its storage is deleted.}) and point to different addresses throughout their lifetime, like pointers.
    18651907Rebinding is accomplished by extending the existing syntax and semantics of the address-of operator in C.
    18661908
    1867 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.
    1868 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.
     1909In C, the address of an lvalue is always an rvalue, as, in general, that address is not stored anywhere in memory and does not itself have an address.
     1910In \CFA, the address of a @T &@ is an lvalue @T *@, as the address of the underlying @T@ is stored in the reference and can thus be mutated there.
    18691911The 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.
    18701912This rebinding occurs to an arbitrary depth of reference nesting;
    18711913loosely speaking, nested address-of operators produce a nested lvalue pointer up to the depth of the reference.
    18721914These 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@.
    1873 More precisely:
     1915The precise rules are
    18741916\begin{itemize}
    18751917\item
    1876 if @R@ is an rvalue of type @T &@$_1\cdots$ @&@$_r$, where $r \ge 1$ references (@&@ symbols), than @&R@ has type @T `*`&@$_{\color{red}2}\cdots$ @&@$_{\color{red}r}$, \ie @T@ pointer with $r-1$ references (@&@ symbols).
     1918If @R@ is an rvalue of type @T &@$_1\cdots$ @&@$_r$, where $r \ge 1$ references (@&@ symbols), than @&R@ has type @T `*`&@$_{\color{red}2}\cdots$ @&@$_{\color{red}r}$, \ie @T@ pointer with $r-1$ references (@&@ symbols).
    18771919\item
    1878 if @L@ is an lvalue of type @T &@$_1\cdots$ @&@$_l$, where $l \ge 0$ references (@&@ symbols), than @&L@ has type @T `*`&@$_{\color{red}1}\cdots$ @&@$_{\color{red}l}$, \ie @T@ pointer with $l$ references (@&@ symbols).
     1920If @L@ is an lvalue of type @T &@$_1\cdots$ @&@$_l$, where $l \ge 0$ references (@&@ symbols), than @&L@ has type @T `*`&@$_{\color{red}1}\cdots$ @&@$_{\color{red}l}$, \ie @T@ pointer with $l$ references (@&@ symbols).
    18791921\end{itemize}
    1880 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 is made solely on convenience, \eg many pointer or value accesses.
     1922Since pointers and references share the same internal representation, code using either is equally performant;
     1923in fact, the \CFA compiler converts references into pointers internally, and the choice between them is made solely on convenience, \eg many pointer or value accesses.
    18811924
    18821925By analogy to pointers, \CFA references also allow cv-qualifiers such as @const@:
     
    18931936There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, and return/temporary binding.
    18941937In each of these contexts, the address-of operator on the target lvalue is elided.
    1895 The syntactic motivation is clearest when considering overloaded operator-assignment, \eg @int ?+=?(int &, int)@; given @int x, y@, the expected call syntax is @x += y@, not @&x += y@.
    1896 
    1897 More 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;
     1938The syntactic motivation is clearest when considering overloaded operator assignment, \eg @int ?+=?(int &, int)@; given @int x, y@, the expected call syntax is @x += y@, not @&x += y@.
     1939
     1940More generally, this initialization of references from lvalues rather than pointers is an instance of an ``lvalue-to-reference'' conversion rather than an elision of the address-of operator;
    18981941this conversion is used in any context in \CFA where an implicit conversion is allowed.
    1899 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, analogous to the @T *@ to @const T *@ conversion in standard C.
    1900 The final reference conversion included in \CFA is ``rvalue-to-reference'' conversion, implemented by means of an implicit temporary.
     1942Similarly, use of 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.
     1943The final reference conversion included in \CFA is an ``rvalue-to-reference'' conversion, implemented by means of an implicit temporary.
    19011944When 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.
    19021945\begin{cfa}
     
    19061949f( 3, x + y, (S){ 1.0, 7.0 }, (int [3]){ 1, 2, 3 } ); $\C{// pass rvalue to lvalue \(\Rightarrow\) implicit temporary}$
    19071950\end{cfa}
    1908 This 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.
    1909 \CC allows a similar binding, but only for @const@ references; the more general semantics of \CFA are an attempt to avoid the \newterm{const poisoning} problem~\cite{Taylor10}, in which addition of a @const@ qualifier to one reference requires a cascading chain of added qualifiers.
    1910 
    1911 
    1912 \subsection{Type Nesting}
    1913 
    1914 Nested types provide a mechanism to organize associated types and refactor a subset of members into a named aggregate (\eg sub-aggregates @name@, @address@, @department@, within aggregate @employe@).
    1915 Java nested types are dynamic (apply to objects), \CC are static (apply to the \lstinline[language=C++]@class@), and C hoists (refactors) nested types into the enclosing scope, meaning there is no need for type qualification.
    1916 Since \CFA in not object-oriented, adopting dynamic scoping does not make sense;
    1917 instead \CFA adopts \CC static nesting, using the member-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@'' (see Figure~\ref{f:TypeNestingQualification}).
     1951This allows complex values to be succinctly and efficiently passed to functions, without the syntactic overhead of the explicit definition of a temporary variable or the runtime cost of pass-by-value.
     1952\CC allows a similar binding, but only for @const@ references; the more general semantics of \CFA are an attempt to avoid the \newterm{const poisoning} problem~\cite{Taylor10}, in which the addition of a @const@ qualifier to one reference requires a cascading chain of added qualifiers.
     1953
     1954
     1955\subsection{Type nesting}
     1956
     1957Nested types provide a mechanism to organize associated types and refactor a subset of members into a named aggregate (\eg subaggregates @name@, @address@, @department@, within aggregate @employe@).
     1958Java nested types are dynamic (apply to objects), \CC are static (apply to the \lstinline[language=C++]@class@), and C hoists (refactors) nested types into the enclosing scope, which means there is no need for type qualification.
     1959Since \CFA in not object oriented, adopting dynamic scoping does not make sense;
     1960instead, \CFA adopts \CC static nesting, using the member-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@'' (see Figure~\ref{f:TypeNestingQualification}).
     1961
    19181962\begin{figure}
    19191963\centering
     1964\fontsize{9bp}{11bp}\selectfont\sf
    19201965\lstDeleteShortInline@%
    19211966\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
     
    19792024\end{tabular}
    19802025\lstMakeShortInline@%
    1981 \caption{Type Nesting / Qualification}
     2026\caption{Type nesting / qualification}
    19822027\label{f:TypeNestingQualification}
     2028\vspace*{-8pt}
    19832029\end{figure}
     2030
    19842031In the C left example, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
    19852032In the \CFA right example, the types are not hoisted and accessible.
    19862033
    19872034
    1988 \subsection{Constructors and Destructors}
     2035\vspace*{-8pt}
     2036\subsection{Constructors and destructors}
    19892037\label{s:ConstructorsDestructors}
    19902038
    1991 One of the strengths (and weaknesses) of C is memory-management control, allowing resource release to be precisely specified versus unknown release with garbage-collected memory-management.
     2039One of the strengths (and weaknesses) of C is memory-management control, allowing resource release to be precisely specified versus unknown release with garbage-collected memory management.
    19922040However, this manual approach is verbose, and it is useful to manage resources other than memory (\eg file handles) using the same mechanism as memory.
    1993 \CC addresses these issues using Resource Aquisition Is Initialization (RAII), implemented by means of \newterm{constructor} and \newterm{destructor} functions;
     2041\CC addresses these issues using RAII, implemented by means of \newterm{constructor} and \newterm{destructor} functions;
    19942042\CFA adopts constructors and destructors (and @finally@) to facilitate RAII.
    1995 While constructors and destructors are a common feature of object-oriented programming-languages, they are an independent capability allowing \CFA to adopt them while retaining a procedural paradigm.
    1996 Specifically, \CFA constructors and destructors are denoted by name and first parameter-type versus name and nesting in an aggregate type.
     2043While constructors and destructors are a common feature of object-oriented programming languages, they are an independent capability allowing \CFA to adopt them while retaining a procedural paradigm.
     2044Specifically, \CFA constructors and destructors are denoted by name and first parameter type versus name and nesting in an aggregate type.
    19972045Constructor calls seamlessly integrate with existing C initialization syntax, providing a simple and familiar syntax to C programmers and allowing constructor calls to be inserted into legacy C code with minimal code changes.
    19982046
     
    20032051The constructor and destructor have return type @void@, and the first parameter is a reference to the object type to be constructed or destructed.
    20042052While the first parameter is informally called the @this@ parameter, as in object-oriented languages, any variable name may be used.
    2005 Both constructors and destructors allow additional parameters after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
    2006 Destruction parameters are useful for specifying storage-management actions, such as de-initialize but not deallocate.}.
    2007 \begin{cfa}
     2053Both constructors and destructors allow additional parameters after the @this@ parameter for specifying values for initialization/deinitialization\footnote{
     2054Destruction parameters are useful for specifying storage-management actions, such as deinitialize but not deallocate.}.
     2055\begin{cfa}[basicstyle=\linespread{0.9}\fontsize{9bp}{11bp}\selectfont\sf]
    20082056struct VLA { int size, * data; };                       $\C{// variable length array of integers}$
    20092057void ?{}( VLA & vla ) with ( vla ) { size = 10;  data = alloc( size ); }  $\C{// default constructor}$
     
    20142062\end{cfa}
    20152063@VLA@ is a \newterm{managed type}\footnote{
    2016 A managed type affects the runtime environment versus a self-contained type.}: a type requiring a non-trivial constructor or destructor, or with a member of a managed type.
     2064A managed type affects the runtime environment versus a self-contained type.}: a type requiring a nontrivial constructor or destructor, or with a member of a managed type.
    20172065A managed type is implicitly constructed at allocation and destructed at deallocation to ensure proper interaction with runtime resources, in this case, the @data@ array in the heap.
    2018 For details of the code-generation placement of implicit constructor and destructor calls among complex executable statements see~\cite[\S~2.2]{Schluntz17}.
    2019 
    2020 \CFA also provides syntax for \newterm{initialization} and \newterm{copy}:
     2066For details of the code-generation placement of implicit constructor and destructor calls among complex executable statements, see section~2.2 in the work of Schlintz~\cite{Schluntz17}.
     2067
     2068\CFA also provides syntax for \newterm{initialization} and \newterm{copy}. \textcolor{blue}{REMOVE ``, as follows''}
    20212069\begin{cfa}
    20222070void ?{}( VLA & vla, int size, char fill = '\0' ) {  $\C{// initialization}$
     
    20272075}
    20282076\end{cfa}
    2029 (Note, the example is purposely simplified using shallow-copy semantics.)
    2030 An initialization constructor-call has the same syntax as a C initializer, except the initialization values are passed as arguments to a matching constructor (number and type of paremeters).
     2077(Note that the example is purposely simplified using shallow-copy semantics.)
     2078An initialization constructor call has the same syntax as a C initializer, except that the initialization values are passed as arguments to a matching constructor (number and type of parameters).
    20312079\begin{cfa}
    20322080VLA va = `{` 20, 0 `}`,  * arr = alloc()`{` 5, 0 `}`;
    20332081\end{cfa}
    2034 Note, the use of a \newterm{constructor expression} to initialize the storage from the dynamic storage-allocation.
     2082Note the use of a \newterm{constructor expression} to initialize the storage from the dynamic storage allocation.
    20352083Like \CC, the copy constructor has two parameters, the second of which is a value parameter with the same type as the first parameter;
    20362084appropriate care is taken to not recursively call the copy constructor when initializing the second parameter.
     
    20382086\CFA constructors may be explicitly called, like Java, and destructors may be explicitly called, like \CC.
    20392087Explicit calls to constructors double as a \CC-style \emph{placement syntax}, useful for construction of members in user-defined constructors and reuse of existing storage allocations.
    2040 Like the other operators in \CFA, there is a concise syntax for constructor/destructor function calls:
     2088Like the other operators in \CFA, there is a concise syntax for constructor/destructor function calls.
    20412089\begin{cfa}
    20422090{
     
    20542102To provide a uniform type interface for @otype@ polymorphism, the \CFA compiler automatically generates a default constructor, copy constructor, assignment operator, and destructor for all types.
    20552103These default functions can be overridden by user-generated versions.
    2056 For compatibility with the standard behaviour of C, the default constructor and destructor for all basic, pointer, and reference types do nothing, while the copy constructor and assignment operator are bitwise copies;
    2057 if default zero-initialization is desired, the default constructors can be overridden.
     2104For compatibility with the standard behavior of C, the default constructor and destructor for all basic, pointer, and reference types do nothing, whereas the copy constructor and assignment operator are bitwise copies;
     2105if default zero initialization is desired, the default constructors can be overridden.
    20582106For user-generated types, the four functions are also automatically generated.
    20592107@enum@ types are handled the same as their underlying integral type, and unions are also bitwise copied and no-op initialized and destructed.
    20602108For compatibility with C, a copy constructor from the first union member type is also defined.
    2061 For @struct@ types, each of the four functions are implicitly defined to call their corresponding functions on each member of the struct.
    2062 To better simulate the behaviour of C initializers, a set of \newterm{member constructors} is also generated for structures.
    2063 A constructor is generated for each non-empty prefix of a structure's member-list to copy-construct the members passed as parameters and default-construct the remaining members.
     2109For @struct@ types, each of the four functions is implicitly defined to call their corresponding functions on each member of the struct.
     2110To better simulate the behavior of C initializers, a set of \newterm{member constructors} is also generated for structures.
     2111A constructor is generated for each nonempty prefix of a structure's member list to copy-construct the members passed as parameters and default-construct the remaining members.
    20642112To 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 member constructors for that type are hidden from expression resolution;
    2065 similarly, the generated default constructor is hidden upon declaration of any constructor.
     2113similarly, the generated default constructor is hidden upon the declaration of any constructor.
    20662114These semantics closely mirror the rule for implicit declaration of constructors in \CC\cite[p.~186]{ANSI98:C++}.
    20672115
    2068 In some circumstance programmers may not wish to have implicit constructor and destructor generation and calls.
    2069 In these cases, \CFA provides the initialization syntax \lstinline|S x `@=` {}|, and the object becomes unmanaged, so implicit constructor and destructor calls are not generated.
     2116In some circumstance, programmers may not wish to have implicit constructor and destructor generation and calls.
     2117In these cases, \CFA provides the initialization syntax \lstinline|S x `@=` {}|, and the object becomes unmanaged;
     2118hence, implicit \mbox{constructor} and destructor calls are not generated.
    20702119Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics.
    20712120The same syntax can be used in a compound literal, \eg \lstinline|a = (VLA)`@`{ 0, 0x0 }|, to create a C-style literal.
    2072 The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert to implicit initialization.
     2121The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert into implicit initialization.
    20732122
    20742123
     
    20782127\section{Literals}
    20792128
    2080 C 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 float types are very similar, differing from each other only in suffix.
    2081 In keeping with the general \CFA approach of adding features while respecting the ``C-style'' of doing things, C's polymorphic constants and typed literal syntax are extended to interoperate with user-defined types, while maintaining a backwards-compatible semantics.
     2129C already includes limited polymorphism for literals---@0@ can be either an integer or a pointer literal, depending on context, whereas the syntactic forms of literals of the various integer and float types are very similar, differing from each other only in suffix.
     2130In keeping with the general \CFA approach of adding features while respecting the ``C style'' of doing things, C's polymorphic constants and typed literal syntax are extended to interoperate with user-defined types, while maintaining a backward-compatible semantics.
    20822131
    20832132A simple example is allowing the underscore, as in Ada, to separate prefixes, digits, and suffixes in all \CFA constants, \eg @0x`_`1.ffff`_`ffff`_`p`_`128`_`l@, where the underscore is also the standard separator in C identifiers.
    2084 \CC uses a single quote as a separator but it is restricted among digits, precluding its use in the literal prefix or suffix, \eg @0x1.ffff@@`'@@ffffp128l@, and causes problems with most IDEs, which must be extended to deal with this alternate use of the single quote.
     2133\CC uses a single quote as a separator, but it is restricted among digits, precluding its use in the literal prefix or suffix, \eg @0x1.ffff@@`'@@ffffp128l@, and causes problems with most \textcolor{blue}{Q2 CHANGE ``IDEs'' TO ``integrated development environments (IDEs)''}, which must be extended to deal with this alternate use of the single quote.
    20852134
    20862135
     
    21252174
    21262175In C, @0@ has the special property that it is the only ``false'' value;
    2127 by the standard, any value that compares equal to @0@ is false, while any value that compares unequal to @0@ is true.
    2128 As such, an expression @x@ in any boolean context (such as the condition of an @if@ or @while@ statement, or the arguments to @&&@, @||@, or @?:@\,) can be rewritten as @x != 0@ without changing its semantics.
     2176by the standard, any value that compares equal to @0@ is false, whereas any value that compares unequal to @0@ is true.
     2177As such, an expression @x@ in any Boolean context (such as the condition of an @if@ or @while@ statement, or the arguments to @&&@, @||@, or @?:@\,) can be rewritten as @x != 0@ without changing its semantics.
    21292178Operator overloading in \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.
    21302179To provide this precision, \CFA introduces a new type @zero_t@ as the type of literal @0@ (somewhat analagous to @nullptr_t@ and @nullptr@ in \CCeleven);
     
    21322181With this addition, \CFA rewrites @if (x)@ and similar expressions to @if ( (x) != 0 )@ or the appropriate analogue, and any type @T@ is ``truthy'' by defining an operator overload @int ?!=?( T, zero_t )@.
    21332182\CC makes types truthy by adding a conversion to @bool@;
    2134 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;
     2183prior to the addition of explicit cast operators in \CCeleven, this approach had the pitfall of making truthy types transitively convertible into any numeric type;
    21352184\CFA avoids this issue.
    21362185
     
    21432192
    21442193
    2145 \subsection{User Literals}
     2194\subsection{User literals}
    21462195
    21472196For readability, it is useful to associate units to scale literals, \eg weight (stone, pound, kilogram) or time (seconds, minutes, hours).
    2148 The left of Figure~\ref{f:UserLiteral} shows the \CFA alternative call-syntax (postfix: literal argument before function name), using the backquote, to convert basic literals into user literals.
     2197The left of Figure~\ref{f:UserLiteral} shows the \CFA alternative call syntax (postfix: literal argument before function name), using the backquote, to convert basic literals into user literals.
    21492198The backquote is a small character, making the unit (function name) predominate.
    2150 For examples, the multi-precision integer-type in Section~\ref{s:MultiPrecisionIntegers} has user literals:
     2199For examples, the multiprecision integer type in Section~\ref{s:MultiPrecisionIntegers} has the following user literals.
    21512200{\lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}}
    21522201\begin{cfa}
     
    21542203y = "12345678901234567890123456789"|`mp| + "12345678901234567890123456789"|`mp|;
    21552204\end{cfa}
    2156 Because \CFA uses a standard function, all types and literals are applicable, as well as overloading and conversions, where @?`@ denotes a postfix-function name and @`@ denotes a postfix-function call.
     2205Because \CFA uses a standard function, all types and literals are applicable, as well as overloading and conversions, where @?`@ \textcolor{blue}{USE CHARACTER \lstinline@`@ NOT \textsf{'}} denotes a postfix-function name and @`@ \textcolor{blue}{USE CHARACTER \lstinline@`@ NOT `} denotes a postfix-function call.
    21572206}%
    21582207\begin{cquote}
     
    21962245\end{cquote}
    21972246
    2198 The right of Figure~\ref{f:UserLiteral} shows the equivalent \CC version using the underscore for the call-syntax.
     2247The right of Figure~\ref{f:UserLiteral} shows the equivalent \CC version using the underscore for the call syntax.
    21992248However, \CC restricts the types, \eg @unsigned long long int@ and @long double@ to represent integral and floating literals.
    22002249After which, user literals must match (no conversions);
     
    22032252\begin{figure}
    22042253\centering
     2254\fontsize{9bp}{11bp}\selectfont
    22052255\lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}}
    22062256\lstDeleteShortInline@%
     
    22582308\end{tabular}
    22592309\lstMakeShortInline@%
    2260 \caption{User Literal}
     2310\caption{User literal}
    22612311\label{f:UserLiteral}
    22622312\end{figure}
     
    22662316\label{sec:libraries}
    22672317
    2268 As stated in Section~\ref{sec:poly-fns}, \CFA inherits a large corpus of library code, where other programming languages must rewrite or provide fragile inter-language communication with C.
     2318As stated in Section~\ref{sec:poly-fns}, \CFA inherits a large corpus of library code, where other programming languages must rewrite or provide fragile interlanguage communication with C.
    22692319\CFA has replacement libraries condensing hundreds of existing C names into tens of \CFA overloaded names, all without rewriting the actual computations.
    2270 In many cases, the interface is an inline wrapper providing overloading during compilation but zero cost at runtime.
     2320In many cases, the interface is an inline wrapper providing overloading during compilation but of zero cost at runtime.
    22712321The following sections give a glimpse of the interface reduction to many C libraries.
    22722322In many cases, @signed@/@unsigned@ @char@, @short@, and @_Complex@ functions are available (but not shown) to ensure expression computations remain in a single type, as conversions can distort results.
     
    22762326
    22772327C library @limits.h@ provides lower and upper bound constants for the basic types.
    2278 \CFA name overloading is used to condense these typed constants, \eg:
     2328\CFA name overloading is used to condense these typed constants.
    22792329\begin{cquote}
    22802330\lstDeleteShortInline@%
     
    22952345\lstMakeShortInline@%
    22962346\end{cquote}
    2297 The result is a significant reduction in names to access typed constants, \eg:
     2347The result is a significant reduction in names to access typed constants. \textcolor{blue}{REMOVE ``, as follows.''}
    22982348\begin{cquote}
    22992349\lstDeleteShortInline@%
     
    23212371
    23222372C library @math.h@ provides many mathematical functions.
    2323 \CFA function overloading is used to condense these mathematical functions, \eg:
     2373\CFA function overloading is used to condense these mathematical functions.
    23242374\begin{cquote}
    23252375\lstDeleteShortInline@%
     
    23402390\lstMakeShortInline@%
    23412391\end{cquote}
    2342 The result is a significant reduction in names to access math functions, \eg:
     2392The result is a significant reduction in names to access math functions. \textcolor{blue}{REMOVE ``, as follows.''}
    23432393\begin{cquote}
    23442394\lstDeleteShortInline@%
     
    23592409\lstMakeShortInline@%
    23602410\end{cquote}
    2361 While \Celeven has type-generic math~\cite[\S~7.25]{C11} in @tgmath.h@ to provide a similar mechanism, these macros are limited, matching a function name with a single set of floating type(s).
     2411While \Celeven has type-generic math (see section~7.25 of the ISO/IEC 9899\cite{C11}) in @tgmath.h@ to provide a similar mechanism, these macros are limited, matching a function name with a single set of floating type(s).
    23622412For example, it is impossible to overload @atan@ for both one and two arguments;
    2363 instead the names @atan@ and @atan2@ are required (see Section~\ref{s:NameOverloading}).
    2364 The key observation is that only a restricted set of type-generic macros are provided for a limited set of function names, which do not generalize across the type system, as in \CFA.
     2413instead, the names @atan@ and @atan2@ are required (see Section~\ref{s:NameOverloading}).
     2414The key observation is that only a restricted set of type-generic macros is provided for a limited set of function names, which do not generalize across the type system, as in \CFA.
    23652415
    23662416
     
    23682418
    23692419C library @stdlib.h@ provides many general functions.
    2370 \CFA function overloading is used to condense these utility functions, \eg:
     2420\CFA function overloading is used to condense these utility functions.
    23712421\begin{cquote}
    23722422\lstDeleteShortInline@%
     
    23872437\lstMakeShortInline@%
    23882438\end{cquote}
    2389 The result is a significant reduction in names to access utility functions, \eg:
     2439The result is a significant reduction in names to access the utility functions. \textcolor{blue}{REMOVE ``, as follows.''}
    23902440\begin{cquote}
    23912441\lstDeleteShortInline@%
     
    24062456\lstMakeShortInline@%
    24072457\end{cquote}
    2408 In additon, there are polymorphic functions, like @min@ and @max@, that work on any type with operators @?<?@ or @?>?@.
    2409 
    2410 The following shows one example where \CFA \emph{extends} an existing standard C interface to reduce complexity and provide safety.
    2411 C/\Celeven provide a number of complex and overlapping storage-management operation to support the following capabilities:
    2412 \begin{description}%[topsep=3pt,itemsep=2pt,parsep=0pt]
     2458In addition, there are polymorphic functions, like @min@ and @max@, that work on any type with operator @?<?@ or @?>?@.
     2459
     2460The following shows one example where \CFA \textcolor{blue}{ADD SPACE} \emph{extends} an existing standard C interface to reduce complexity and provide safety.
     2461C/\Celeven provide a number of complex and overlapping storage-management operations to support the following capabilities.
     2462\begin{list}{}{\itemsep=0pt\parsep=0pt\labelwidth=0pt\leftmargin\parindent\itemindent-\leftmargin\let\makelabel\descriptionlabel}
    24132463\item[fill]
    24142464an allocation with a specified character.
    24152465\item[resize]
    24162466an existing allocation to decrease or increase its size.
    2417 In either case, new storage may or may not be allocated and, if there is a new allocation, as much data from the existing allocation is copied.
     2467In either case, new storage may or may not be allocated, and if there is a new allocation, as much data from the existing allocation are copied.
    24182468For an increase in storage size, new storage after the copied data may be filled.
     2469\newpage
    24192470\item[align]
    24202471an allocation on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes.
     
    24222473allocation with a specified number of elements.
    24232474An array may be filled, resized, or aligned.
    2424 \end{description}
    2425 Table~\ref{t:StorageManagementOperations} shows the capabilities provided by C/\Celeven allocation-functions and how all the capabilities can be combined into two \CFA functions.
    2426 \CFA storage-management functions extend the C equivalents by overloading, providing shallow type-safety, and removing the need to specify the base allocation-size.
    2427 Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage-allocation performing the same operations with the same type safety.
     2475\end{list}
     2476Table~\ref{t:StorageManagementOperations} shows the capabilities provided by C/\Celeven allocation functions and how all the capabilities can be combined into two \CFA functions.
     2477\CFA storage-management functions extend the C equivalents by overloading, providing shallow type safety, and removing the need to specify the base allocation size.
     2478Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage allocation performing the same operations with the same type safety.
    24282479
    24292480\begin{table}
    2430 \caption{Storage-Management Operations}
     2481\caption{Storage-management operations}
    24312482\label{t:StorageManagementOperations}
    24322483\centering
    24332484\lstDeleteShortInline@%
    24342485\lstMakeShortInline~%
    2435 \begin{tabular}{@{}r|r|l|l|l|l@{}}
    2436 \multicolumn{1}{c}{}&           & \multicolumn{1}{c|}{fill}     & resize        & align & array \\
    2437 \hline
     2486\begin{tabular}{@{}rrllll@{}}
     2487\multicolumn{1}{c}{}&           & \multicolumn{1}{c}{fill}      & resize        & align & array \\
    24382488C               & ~malloc~                      & no                    & no            & no            & no    \\
    24392489                & ~calloc~                      & yes (0 only)  & no            & no            & yes   \\
     
    24412491                & ~memalign~            & no                    & no            & yes           & no    \\
    24422492                & ~posix_memalign~      & no                    & no            & yes           & no    \\
    2443 \hline
    24442493C11             & ~aligned_alloc~       & no                    & no            & yes           & no    \\
    2445 \hline
    24462494\CFA    & ~alloc~                       & yes/copy              & no/yes        & no            & yes   \\
    24472495                & ~align_alloc~         & yes                   & no            & yes           & yes   \\
     
    24532501\begin{figure}
    24542502\centering
     2503\fontsize{9bp}{11bp}\selectfont
    24552504\begin{cfa}[aboveskip=0pt,xleftmargin=0pt]
    24562505size_t  dim = 10;                                                       $\C{// array dimension}$
     
    24902539\end{tabular}
    24912540\lstMakeShortInline@%
    2492 \caption{\CFA versus C Storage-Allocation}
     2541\caption{\CFA versus C storage allocation}
    24932542\label{f:StorageAllocation}
    24942543\end{figure}
    24952544
    24962545Variadic @new@ (see Section~\ref{sec:variadic-tuples}) cannot support the same overloading because extra parameters are for initialization.
    2497 Hence, there are @new@ and @anew@ functions for single and array variables, and the fill value is the arguments to the constructor, \eg:
     2546Hence, there are @new@ and @anew@ functions for single and array variables, and the fill value is the arguments to the constructor.
    24982547\begin{cfa}
    24992548struct S { int i, j; };
     
    25022551S * as = anew( dim, 2, 3 );                                     $\C{// each array element initialized to 2, 3}$
    25032552\end{cfa}
    2504 Note, \CC can only initialize array elements via the default constructor.
    2505 
    2506 Finally, the \CFA memory-allocator has \newterm{sticky properties} for dynamic storage: fill and alignment are remembered with an object's storage in the heap.
     2553Note that \CC can only initialize array elements via the default constructor.
     2554
     2555Finally, the \CFA memory allocator has \newterm{sticky properties} for dynamic storage: fill and alignment are remembered with an object's storage in the heap.
    25072556When a @realloc@ is performed, the sticky properties are respected, so that new storage is correctly aligned and initialized with the fill character.
    25082557
     
    25112560\label{s:IOLibrary}
    25122561
    2513 The goal of \CFA I/O is to simplify the common cases, while fully supporting polymorphism and user defined types in a consistent way.
     2562The goal of \CFA I/O is to simplify the common cases, while fully supporting polymorphism and user-defined types in a consistent way.
    25142563The approach combines ideas from \CC and Python.
    25152564The \CFA header file for the I/O library is @fstream@.
     
    25402589\lstMakeShortInline@%
    25412590\end{cquote}
    2542 The \CFA form has half the characters of the \CC form, and is similar to Python I/O with respect to implicit separators.
     2591The \CFA form has half the characters of the \CC form and is similar to Python I/O with respect to implicit separators.
    25432592Similar simplification occurs for tuple I/O, which prints all tuple values separated by ``\lstinline[showspaces=true]@, @''.
    25442593\begin{cfa}
     
    25732622\lstMakeShortInline@%
    25742623\end{cquote}
    2575 There is a weak similarity between the \CFA logical-or operator and the Shell pipe-operator for moving data, where data flows in the correct direction for input but the opposite direction for output.
     2624There is a weak similarity between the \CFA logical-or operator and the Shell pipe operator for moving data, where data flow in the correct direction for input but in the opposite direction for output.
    25762625\begin{comment}
    25772626The implicit separator character (space/blank) is a separator not a terminator.
     
    25942643\end{itemize}
    25952644\end{comment}
    2596 There are functions to set and get the separator string, and manipulators to toggle separation on and off in the middle of output.
    2597 
    2598 
    2599 \subsection{Multi-precision Integers}
     2645There are functions to set and get the separator string and manipulators to toggle separation on and off in the middle of output.
     2646
     2647
     2648\subsection{Multiprecision integers}
    26002649\label{s:MultiPrecisionIntegers}
    26012650
    2602 \CFA has an interface to the GMP multi-precision signed-integers~\cite{GMP}, similar to the \CC interface provided by GMP.
    2603 The \CFA interface wraps GMP functions into operator functions to make programming with multi-precision integers identical to using fixed-sized integers.
    2604 The \CFA type name for multi-precision signed-integers is @Int@ and the header file is @gmp@.
    2605 Figure~\ref{f:GMPInterface} shows a multi-precision factorial-program contrasting the GMP interface in \CFA and C.
    2606 
    2607 \begin{figure}
     2651\CFA has an interface to the \textcolor{blue}{Q3 CHANGE ``GMP multiprecision'' TO ``GNU multiple precision (GMP)''} signed integers~\cite{GMP}, similar to the \CC interface provided by GMP.
     2652The \CFA interface wraps GMP functions into operator functions to make programming with multiprecision integers identical to using fixed-sized integers.
     2653The \CFA type name for multiprecision signed integers is @Int@ and the header file is @gmp@.
     2654Figure~\ref{f:GMPInterface} shows a multiprecision factorial program contrasting the GMP interface in \CFA and C.
     2655
     2656\begin{figure}[b]
    26082657\centering
     2658\fontsize{9bp}{11bp}\selectfont
    26092659\lstDeleteShortInline@%
    26102660\begin{tabular}{@{}l@{\hspace{3\parindentlnth}}l@{}}
     
    26372687\end{tabular}
    26382688\lstMakeShortInline@%
    2639 \caption{GMP Interface \CFA versus C}
     2689\caption{GMP interface \CFA versus C}
    26402690\label{f:GMPInterface}
    26412691\end{figure}
    26422692
    26432693
     2694\vspace{-4pt}
    26442695\section{Polymorphism Evaluation}
    26452696\label{sec:eval}
     
    26502701% Though \CFA provides significant added functionality over C, these features have a low runtime penalty.
    26512702% In fact, it is shown that \CFA's generic programming can enable faster runtime execution than idiomatic @void *@-based C code.
    2652 The experiment is a set of generic-stack micro-benchmarks~\cite{CFAStackEvaluation} in C, \CFA, and \CC (see implementations in Appendix~\ref{sec:BenchmarkStackImplementations}).
     2703The experiment is a set of generic-stack microbenchmarks~\cite{CFAStackEvaluation} in C, \CFA, and \CC (see implementations in Appendix~\ref{sec:BenchmarkStackImplementations}).
    26532704Since all these languages share a subset essentially comprising standard C, maximal-performance benchmarks should show little runtime variance, differing only in length and clarity of source code.
    26542705A more illustrative comparison measures the costs of idiomatic usage of each language's features.
    2655 Figure~\ref{fig:BenchmarkTest} shows the \CFA benchmark tests for a generic stack based on a singly linked-list.
     2706Figure~\ref{fig:BenchmarkTest} shows the \CFA benchmark tests for a generic stack based on a singly linked list.
    26562707The benchmark test is similar for the other languages.
    26572708The experiment uses element types @int@ and @pair(short, char)@, and pushes $N=40M$ elements on a generic stack, copies the stack, clears one of the stacks, and finds the maximum value in the other stack.
    26582709
    26592710\begin{figure}
     2711\fontsize{9bp}{11bp}\selectfont
    26602712\begin{cfa}[xleftmargin=3\parindentlnth,aboveskip=0pt,belowskip=0pt]
    26612713int main() {
     
    26772729}
    26782730\end{cfa}
    2679 \caption{\protect\CFA Benchmark Test}
     2731\caption{\protect\CFA benchmark test}
    26802732\label{fig:BenchmarkTest}
     2733\vspace*{-10pt}
    26812734\end{figure}
    26822735
    2683 The structure of each benchmark implemented is: C with @void *@-based polymorphism, \CFA with parametric polymorphism, \CC with templates, and \CC using only class inheritance for polymorphism, called \CCV.
     2736The structure of each benchmark implemented is C with @void *@-based polymorphism, \CFA with parametric polymorphism, \CC with templates, and \CC using only class inheritance for polymorphism, called \CCV.
    26842737The \CCV variant illustrates an alternative object-oriented idiom where all objects inherit from a base @object@ class, mimicking a Java-like interface;
    2685 hence runtime checks are necessary to safely down-cast objects.
    2686 The most notable difference among the implementations is in memory layout of generic types: \CFA and \CC inline the stack and pair elements into corresponding list and pair nodes, while C and \CCV lack such a capability and instead must store generic objects via pointers to separately-allocated objects.
    2687 Note, the C benchmark uses unchecked casts as C has no runtime mechanism to perform such checks, while \CFA and \CC provide type-safety statically.
     2738hence, runtime checks are necessary to safely downcast objects.
     2739The most notable difference among the implementations is in memory layout of generic types: \CFA and \CC inline the stack and pair elements into corresponding list and pair nodes, whereas C and \CCV lack such capability and, instead, must store generic objects via pointers to separately allocated objects.
     2740Note that the C benchmark uses unchecked casts as C has no runtime mechanism to perform such checks, whereas \CFA and \CC provide type safety statically.
    26882741
    26892742Figure~\ref{fig:eval} and Table~\ref{tab:eval} show the results of running the benchmark in Figure~\ref{fig:BenchmarkTest} and its C, \CC, and \CCV equivalents.
    2690 The graph plots the median of 5 consecutive runs of each program, with an initial warm-up run omitted.
    2691 All code is compiled at \texttt{-O2} by gcc or g++ 6.4.0, with all \CC code compiled as \CCfourteen.
    2692 The benchmarks are run on an Ubuntu 16.04 workstation with 16 GB of RAM and a 6-core AMD FX-6300 CPU with 3.5 GHz maximum clock frequency.
     2743The graph plots the median of five consecutive runs of each program, with an initial warm-up run omitted.
     2744All code is compiled at \texttt{-O2} by gcc or g++ 6.4.0, with all \CC code compiled as \CCfourteen. \textcolor{blue}{CHANGE ``\CC{}fourteen'' TO ``\CCfourteen''}
     2745The benchmarks are run on an Ubuntu 16.04 workstation with 16 GB of RAM and a 6-core AMD FX-6300 CPU with 3.5 GHz \textcolor{blue}{REMOVE ``of''} maximum clock frequency.
    26932746
    26942747\begin{figure}
    26952748\centering
    2696 \input{timing}
    2697 \caption{Benchmark Timing Results (smaller is better)}
     2749\resizebox{0.7\textwidth}{!}{\input{timing}}
     2750\caption{Benchmark timing results (smaller is better)}
    26982751\label{fig:eval}
     2752\vspace*{-10pt}
    26992753\end{figure}
    27002754
    27012755\begin{table}
     2756\vspace*{-10pt}
    27022757\caption{Properties of benchmark code}
    27032758\label{tab:eval}
    27042759\centering
     2760\vspace*{-4pt}
    27052761\newcommand{\CT}[1]{\multicolumn{1}{c}{#1}}
    2706 \begin{tabular}{rrrrr}
    2707                                                                         & \CT{C}        & \CT{\CFA}     & \CT{\CC}      & \CT{\CCV}             \\ \hline
    2708 maximum memory usage (MB)                       & 10,001        & 2,502         & 2,503         & 11,253                \\
     2762\begin{tabular}{lrrrr}
     2763                                                                        & \CT{C}        & \CT{\CFA}     & \CT{\CC}      & \CT{\CCV}             \\
     2764maximum memory usage (MB)                       & 10\,001       & 2\,502        & 2\,503        & 11\,253               \\
    27092765source code size (lines)                        & 201           & 191           & 125           & 294                   \\
    27102766redundant type annotations (lines)      & 27            & 0                     & 2                     & 16                    \\
    27112767binary size (KB)                                        & 14            & 257           & 14            & 37                    \\
    27122768\end{tabular}
     2769\vspace*{-16pt}
    27132770\end{table}
    27142771
    2715 The C and \CCV variants are generally the slowest with the largest memory footprint, because of their less-efficient memory layout and the pointer-indirection necessary to implement generic types;
     2772The C and \CCV variants are generally the slowest with the largest memory footprint, due to their less-efficient memory layout and the pointer indirection necessary to implement generic types;
    27162773this inefficiency is exacerbated by the second level of generic types in the pair benchmarks.
    2717 By contrast, the \CFA and \CC variants run in roughly equivalent time for both the integer and pair because of equivalent storage layout, with the inlined libraries (\ie no separate compilation) and greater maturity of the \CC compiler contributing to its lead.
    2718 \CCV is slower than C largely due to the cost of runtime type-checking of down-casts (implemented with @dynamic_cast@);
     2774By contrast, the \CFA and \CC variants run in roughly equivalent time for both the integer and pair because of the equivalent storage layout, with the inlined libraries (\ie no separate compilation) and greater maturity of the \CC compiler contributing to its lead.
     2775\CCV is slower than C largely due to the cost of runtime type checking of downcasts (implemented with @dynamic_cast@).
    27192776The outlier for \CFA, pop @pair@, results from the complexity of the generated-C polymorphic code.
    27202777The gcc compiler is unable to optimize some dead code and condense nested calls;
     
    27222779Finally, the binary size for \CFA is larger because of static linking with the \CFA libraries.
    27232780
    2724 \CFA is also competitive in terms of source code size, measured as a proxy for programmer effort. The line counts in Table~\ref{tab:eval} include implementations of @pair@ and @stack@ types for all four languages for purposes of direct comparison, though it should be noted that \CFA and \CC have pre-written data structures in their standard libraries that programmers would generally use instead. Use of these standard library types has minimal impact on the performance benchmarks, but shrinks the \CFA and \CC benchmarks to 39 and 42 lines, respectively.
     2781\CFA is also competitive in terms of source code size, measured as a proxy for programmer effort. The line counts in Table~\ref{tab:eval} include implementations of @pair@ and @stack@ types for all four languages for purposes of direct comparison, although it should be noted that \CFA and \CC have prewritten data structures in their standard libraries that programmers would generally use instead. Use of these standard library types has minimal impact on the performance benchmarks, but shrinks the \CFA and \CC benchmarks to 39 and 42 lines, respectively.
    27252782The difference between the \CFA and \CC line counts is primarily declaration duplication to implement separate compilation; a header-only \CFA library would be similar in length to the \CC version.
    2726 On the other hand, C does not have a generic collections-library in its standard distribution, resulting in frequent reimplementation of such collection types by C programmers.
    2727 \CCV does not use the \CC standard template library by construction, and in fact includes the definition of @object@ and wrapper classes for @char@, @short@, and @int@ in its line count, which inflates this count somewhat, as an actual object-oriented language would include these in the standard library;
     2783On the other hand, C does not have a generic collections library in its standard distribution, resulting in frequent reimplementation of such collection types by C programmers.
     2784\CCV does not use the \CC standard template library by construction and, in fact, includes the definition of @object@ and wrapper classes for @char@, @short@, and @int@ in its line count, which inflates this count somewhat, as an actual object-oriented language would include these in the standard library;
    27282785with their omission, the \CCV line count is similar to C.
    27292786We justify the given line count by noting that many object-oriented languages do not allow implementing new interfaces on library types without subclassing or wrapper types, which may be similarly verbose.
    27302787
    2731 Line-count is a fairly rough measure of code complexity;
    2732 another important factor is how much type information the programmer must specify manually, especially where that information is not compiler-checked.
    2733 Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts, \eg @object@ to @integer@ when popping a stack.
     2788Line count is a fairly rough measure of code complexity;
     2789another important factor is how much type information the programmer must specify manually, especially where that information is not compiler checked.
     2790Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts, \eg @object@ to @integer@ when popping a stack.
    27342791To quantify this manual typing, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is respecified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression.
    2735 The \CC benchmark uses two redundant type annotations to create a new stack nodes, while the C and \CCV benchmarks have several such annotations spread throughout their code.
     2792The \CC benchmark uses two redundant type annotations to create a new stack nodes, whereas the C and \CCV benchmarks have several such annotations spread throughout their code.
    27362793The \CFA benchmark is able to eliminate all redundant type annotations through use of the polymorphic @alloc@ function discussed in Section~\ref{sec:libraries}.
    27372794
    2738 We conjecture these results scale across most generic data-types as the underlying polymorphism implement is constant.
    2739 
    2740 
     2795We conjecture that these results scale across most generic data types as the underlying polymorphism implement is constant.
     2796
     2797
     2798\vspace*{-8pt}
    27412799\section{Related Work}
    27422800\label{s:RelatedWork}
     
    27542812\CC provides three disjoint polymorphic extensions to C: overloading, inheritance, and templates.
    27552813The overloading is restricted because resolution does not use the return type, inheritance requires learning object-oriented programming and coping with a restricted nominal-inheritance hierarchy, templates cannot be separately compiled resulting in compilation/code bloat and poor error messages, and determining how these mechanisms interact and which to use is confusing.
    2756 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.
     2814In 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.
    27572815The key mechanism to support separate compilation is \CFA's \emph{explicit} use of assumed type properties.
    2758 Until \CC concepts~\cite{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way to specify the requirements of a generic function beyond compilation errors during template expansion;
     2816Until \CC concepts~\cite{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way of specifying the requirements of a generic function beyond compilation errors during template expansion;
    27592817furthermore, \CC concepts are restricted to template polymorphism.
    27602818
    27612819Cyclone~\cite{Grossman06} also provides capabilities for polymorphic functions and existential types, similar to \CFA's @forall@ functions and generic types.
    2762 Cyclone existential types can include function pointers in a construct similar to a virtual function-table, but these pointers must be explicitly initialized at some point in the code, a tedious and potentially error-prone process.
     2820Cyclone existential types can include function pointers in a construct similar to a virtual function table, but these pointers must be explicitly initialized at some point in the code, which is a tedious and potentially error-prone process.
    27632821Furthermore, Cyclone's polymorphic functions and types are restricted to abstraction over types with the same layout and calling convention as @void *@, \ie only pointer types and @int@.
    27642822In \CFA terms, all Cyclone polymorphism must be dtype-static.
    27652823While 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.
    2766 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.
     2824Smith and Volpano~\cite{Smith98} present Polymorphic C, an ML dialect with polymorphic functions, C-like syntax, and pointer types;
     2825it lacks many of C's features, most notably structure types, and hence, is not a practical C replacement.
    27672826
    27682827Objective-C~\cite{obj-c-book} is an industrially successful extension to C.
    2769 However, Objective-C is a radical departure from C, using an object-oriented model with message-passing.
     2828However, Objective-C is a radical departure from C, using an object-oriented model with message passing.
    27702829Objective-C did not support type-checked generics until recently \cite{xcode7}, historically using less-efficient runtime checking of object types.
    2771 The GObject~\cite{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage-collection to C;
    2772 these features are more intrusive additions than those provided by \CFA, in addition to the runtime overhead of reference-counting.
    2773 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.
    2774 Java~\cite{Java8} included generic types in Java~5, which are type-checked at compilation and type-erased at runtime, similar to \CFA's.
    2775 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.
     2830The GObject~\cite{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage collection to C;
     2831these features are more intrusive additions than those provided by \CFA, in addition to the runtime overhead of reference counting.
     2832Vala~\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.
     2833Java~\cite{Java8} included generic types in Java~5, which are type checked at compilation and type erased at runtime, similar to \CFA's.
     2834However, in Java, each object carries its own table of method pointers, whereas \CFA passes the method pointers separately to maintain a C-compatible layout.
    27762835Java is also a garbage-collected, object-oriented language, with the associated resource usage and C-interoperability burdens.
    27772836
    2778 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.
     2837D~\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.
    27792838However, 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.
    27802839D and Go are garbage-collected languages, imposing the associated runtime overhead.
    27812840The necessity of accounting for data transfer between managed runtimes and the unmanaged C runtime complicates foreign-function interfaces to C.
    27822841Furthermore, while generic types and functions are available in Go, they are limited to a small fixed set provided by the compiler, with no language facility to define more.
    2783 D restricts garbage collection to its own heap by default, while Rust is not garbage-collected, and thus has a lighter-weight runtime more interoperable with C.
     2842D restricts garbage collection to its own heap by default, whereas Rust is not garbage collected and, thus, has a lighter-weight runtime more interoperable with C.
    27842843Rust also possesses much more powerful abstraction capabilities for writing generic code than Go.
    2785 On the other hand, Rust's borrow-checker provides strong safety guarantees but is complex and difficult to learn and imposes a distinctly idiomatic programming style.
     2844On the other hand, Rust's borrow checker provides strong safety guarantees but is complex and difficult to learn and imposes a distinctly idiomatic programming style.
    27862845\CFA, with its more modest safety features, allows direct ports of C code while maintaining the idiomatic style of the original source.
    27872846
    27882847
    2789 \subsection{Tuples/Variadics}
    2790 
     2848\vspace*{-18pt}
     2849\subsection{Tuples/variadics}
     2850
     2851\vspace*{-5pt}
    27912852Many programming languages have some form of tuple construct and/or variadic functions, \eg SETL, C, KW-C, \CC, D, Go, Java, ML, and Scala.
    27922853SETL~\cite{SETL} is a high-level mathematical programming language, with tuples being one of the primary data types.
    27932854Tuples in SETL allow subscripting, dynamic expansion, and multiple assignment.
    2794 C provides variadic functions through @va_list@ objects, but the programmer is responsible for managing the number of arguments and their types, so the mechanism is type unsafe.
     2855C provides variadic functions through @va_list@ objects, but the programmer is responsible for managing the number of arguments and their types;
     2856thus, the mechanism is type unsafe.
    27952857KW-C~\cite{Buhr94a}, a predecessor of \CFA, introduced tuples to C as an extension of the C syntax, taking much of its inspiration from SETL.
    27962858The main contributions of that work were adding MRVF, tuple mass and multiple assignment, and record-member access.
    2797 \CCeleven introduced @std::tuple@ as a library variadic template structure.
     2859\CCeleven introduced @std::tuple@ as a library variadic-template structure.
    27982860Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values.
    27992861Operations include @std::get<N>@ to extract values, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons.
    2800 \CCseventeen proposes \emph{structured bindings}~\cite{Sutter15} to eliminate pre-declaring variables and use of @std::tie@ for binding the results.
    2801 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.
     2862\CCseventeen \textcolor{blue}{CHANGE ``\CC{}seventeen TO ``\CCseventeen''} proposes \emph{structured bindings}~\cite{Sutter15} to eliminate predeclaring variables and the use of @std::tie@ for binding the results.
     2863This extension requires the use of @auto@ to infer the types of the new variables; hence, complicated expressions with a nonobvious type must be documented with some other mechanism.
    28022864Furthermore, structured bindings are not a full replacement for @std::tie@, as it always declares new variables.
    28032865Like \CC, D provides tuples through a library variadic-template structure.
    28042866Go does not have tuples but supports MRVF.
    2805 Java's variadic functions appear similar to C's but are type-safe using homogeneous arrays, which are less useful than \CFA's heterogeneously-typed variadic functions.
     2867Java's variadic functions appear similar to C's but are type safe using homogeneous arrays, which are less useful than \CFA's heterogeneously typed variadic functions.
    28062868Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML~\cite{sml}, Haskell, and Scala~\cite{Scala}, which decompose tuples using pattern matching.
    28072869
    28082870
     2871\vspace*{-18pt}
    28092872\subsection{C Extensions}
    28102873
    2811 \CC is the best known C-based language, and is similar to \CFA in that both are extensions to C with source and runtime backwards compatibility.
    2812 Specific difference between \CFA and \CC have been identified in prior sections, with a final observation that \CFA has equal or fewer tokens to express the same notion in many cases.
     2874\vspace*{-5pt}
     2875\CC is the best known C-based language and is similar to \CFA in that both are extensions to C with source and runtime backward compatibility.
     2876Specific differences between \CFA and \CC have been identified in prior sections, with a final observation that \CFA has equal or fewer tokens to express the same notion in many cases.
    28132877The key difference in design philosophies is that \CFA is easier for C programmers to understand by maintaining a procedural paradigm and avoiding complex interactions among extensions.
    28142878\CC, on the other hand, has multiple overlapping features (such as the three forms of polymorphism), many of which have complex interactions with its object-oriented design.
    2815 As a result, \CC has a steep learning curve for even experienced C programmers, especially when attempting to maintain performance equivalent to C legacy-code.
    2816 
    2817 There are several other C extension-languages with less usage and even more dramatic changes than \CC.
    2818 Objective-C and Cyclone are two other extensions to C with different design goals than \CFA, as discussed above.
     2879As a result, \CC has a steep learning curve for even experienced C programmers, especially when attempting to maintain performance equivalent to C legacy code.
     2880
     2881There are several other C extension languages with less usage and even more dramatic changes than \CC.
     2882\mbox{Objective-C} and Cyclone are two other extensions to C with different design goals than \CFA, as discussed above.
    28192883Other languages extend C with more focused features.
    28202884$\mu$\CC~\cite{uC++book}, CUDA~\cite{Nickolls08}, ispc~\cite{Pharr12}, and Sierra~\cite{Leissa14} add concurrent or data-parallel primitives to C or \CC;
    2821 data-parallel features have not yet been added to \CFA, but are easily incorporated within its design, while concurrency primitives similar to those in $\mu$\CC have already been added~\cite{Delisle18}.
    2822 Finally, CCured~\cite{Necula02} and Ironclad \CC~\cite{DeLozier13} attempt to provide a more memory-safe C by annotating pointer types with garbage collection information; type-checked polymorphism in \CFA covers several of C's memory-safety issues, but more aggressive approaches such as annotating all pointer types with their nullability or requiring runtime garbage collection are contradictory to \CFA's backwards compatibility goals.
     2885data-parallel features have not yet been added to \CFA, but are easily incorporated within its design, whereas concurrency primitives similar to those in $\mu$\CC have already been added~\cite{Delisle18}.
     2886Finally, CCured~\cite{Necula02} and Ironclad \CC~\cite{DeLozier13} attempt to provide a more memory-safe C by annotating pointer types with garbage collection information; type-checked polymorphism in \CFA covers several of C's memory-safety issues, but more aggressive approaches such as annotating all pointer types with their nullability or requiring runtime garbage collection are contradictory to \CFA's backward compatibility goals.
    28232887
    28242888
    28252889\section{Conclusion and Future Work}
    28262890
    2827 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.
    2828 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.
    2829 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.
    2830 The contributions are a powerful type-system using parametric polymorphism and overloading, generic types, tuples, advanced control structures, and extended declarations, which all have complex interactions.
     2891The 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.
     2892While 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.
     2893The 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.
     2894The contributions are a powerful type system using parametric polymorphism and overloading, generic types, tuples, advanced control structures, and extended declarations, which all have complex interactions.
    28312895The work is a challenging design, engineering, and implementation exercise.
    28322896On the surface, the project may appear as a rehash of similar mechanisms in \CC.
    28332897However, every \CFA feature is different than its \CC counterpart, often with extended functionality, better integration with C and its programmers, and always supporting separate compilation.
    2834 All of these new features are being used by the \CFA development-team to build the \CFA runtime-system.
     2898All of these new features are being used by the \CFA development team to build the \CFA runtime system.
    28352899Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable.
    28362900
    28372901While all examples in the paper compile and run, there are ongoing efforts to reduce compilation time, provide better debugging, and add more libraries;
    28382902when this work is complete in early 2019, a public beta release will be available at \url{https://github.com/cforall/cforall}.
    2839 There is also new work on a number of \CFA features, including arrays with size, runtime type-information, virtual functions, user-defined conversions, and modules.
    2840 While \CFA polymorphic functions use dynamic virtual-dispatch with low runtime overhead (see Section~\ref{sec:eval}), it is not as low as \CC template-inlining.
    2841 Hence it may be beneficial to provide a mechanism for performance-sensitive code.
    2842 Two promising approaches are an @inline@ annotation at polymorphic function call sites to create a template-specialization of the function (provided the code is visible) or placing an @inline@ annotation on polymorphic function-definitions to instantiate a specialized version for some set of types (\CC template specialization).
    2843  These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code-bloat.
    2844 In general, we believe separate compilation, producing smaller code, works well with loaded hardware-caches, which may offset the benefit of larger inlined-code.
     2903There is also new work on a number of \CFA features, including arrays with size, runtime type information, virtual functions, user-defined conversions, and modules.
     2904While \CFA polymorphic functions use dynamic virtual dispatch with low runtime overhead (see Section~\ref{sec:eval}), it is not as low as \CC template inlining.
     2905Hence, it may be beneficial to provide a mechanism for performance-sensitive code.
     2906Two promising approaches are an @inline@ annotation at polymorphic function call sites to create a template specialization of the function (provided the code is visible) or placing an @inline@ annotation on polymorphic function definitions to instantiate a specialized version for some set of types (\CC template specialization).
     2907 These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code bloat.
     2908In general, we believe separate compilation, producing smaller code, works well with loaded hardware caches, which may offset the benefit of larger inlined code.
    28452909
    28462910
    28472911\section{Acknowledgments}
    28482912
    2849 The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, Thierry Delisle, Andrew Beach and Brice Dobry on the features described in this paper, and thank Magnus Madsen for feedback on the writing.
    2850 Funding for this project has been provided by Huawei Ltd.\ (\url{http://www.huawei.com}), and Aaron Moss and Peter Buhr are partially funded by the Natural Sciences and Engineering Research Council of Canada.
     2913The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, Thierry Delisle, Andrew Beach, and Brice Dobry on the features described in this paper and thank Magnus Madsen for feedback on the writing.
     2914Funding for this project was provided by Huawei Ltd (\url{http://www.huawei.com}), and Aaron Moss and Peter Buhr were partially funded by the Natural Sciences and Engineering Research Council of Canada.
    28512915
    28522916{%
     
    29312995
    29322996
     2997\enlargethispage{1000pt}
    29332998\subsection{\CFA}
    29342999\label{s:CforallStack}
     
    29973062
    29983063
     3064\newpage
    29993065\subsection{\CC}
    30003066
Note: See TracChangeset for help on using the changeset viewer.