Changes in / [c51b5a3:af68f0a]


Ignore:
Files:
13 deleted
11 edited

Legend:

Unmodified
Added
Removed

  • doc/LaTeXmacros/common.tex

    rc51b5a3 raf68f0a  
    1111%% Created On       : Sat Apr  9 10:06:17 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Wed Apr  5 23:19:42 2017
    14 %% Update Count     : 255
     13%% Last Modified On : Fri Feb 10 11:32:36 2017
     14%% Update Count     : 249
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    256256}%
    257257
    258 \newcommand{\CFADefaults}{%
     258\newcommand{\CFADefaultStyle}{%
    259259\lstset{
    260260language=CFA,
    … …  
    267267escapechar=§,                                                                                   % LaTeX escape in CFA code §...§ (section symbol), emacs: C-q M-'
    268268mathescape=true,                                                                                % LaTeX math escape in CFA code $...$
    269 keepspaces=true,                                                                                %
     269%keepspaces=true,                                                                               %
    270270showstringspaces=false,                                                                 % do not show spaces with cup
    271271showlines=true,                                                                                 % show blank lines at end of code
    … …  
    281281moredelim=[is][\lstset{keywords={}}]{¶}{¶},                     % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    282282}% lstset
    283 }% CFADefaults
    284 \newcommand{\CFAStyle}{%
    285 \CFADefaults
    286283% inline code ©...© (copyright symbol) emacs: C-q M-)
    287284\lstMakeShortInline©                                                                    % single-character for \lstinline
    288 }% CFAStyle
    289 
    290 \lstnewenvironment{cfa}[1][]
    291 {\CFADefaults\lstset{#1}}
    292 {}
    293 
     285}%CFADefaultStyle
    294286
    295287% Local Variables: %

  • doc/bibliography/cfa.bib

    rc51b5a3 raf68f0a  
    30593059}
    30603060
    3061 @online{GObject,
    3062     keywords = {GObject},
    3063     contributor = {a3moss@uwaterloo.ca},
    3064     author = {{The GNOME Project}},
    3065     title = {{GObject} Reference Manual},
    3066     year = 2014,
    3067     url = {https://developer.gnome.org/gobject/stable/},
    3068     urldate = {2017-04-04}
    3069 }
    3070 
    30713061@article{Choi91,
    30723062    keywords    = {contra-variance, functions},
    … …  
    36453635    contributer = {pabuhr@plg},
    36463636    author      = {James Gosling and Bill Joy and Guy Steele and Gilad Bracha and Alex Buckley},
    3647     title       = {{Java} Language Specification},
     3637    title       = {The {Java} Language Specification},
    36483638    publisher   = {Oracle},
    36493639    year        = 2015,
    3650     edition     = {Java SE8},
     3640    edition     = {Java SE 8},
    36513641}
    36523642
    … …  
    45634553}
    45644554
    4565 @manual{obj-c-book,
    4566     keywords = {objective-c},
    4567     contributor = {a3moss@uwaterloo.ca},
    4568     author = {{Apple Computer Inc.}},
    4569     title = {The {Objective-C} Programming Language},
    4570     publisher = {Apple Computer Inc.},
    4571     address = {Cupertino, CA},
    4572     year = 2003
    4573 }
    4574 
    4575 @online{xcode7,
    4576     keywords    = {objective-c},
    4577     contributor = {a3moss@uwaterloo.ca},
    4578     author      = {{Apple Computer Inc.}},
    4579     title       = {{Xcode} 7 Release Notes},
    4580     year        = 2015,
    4581     note        = {\href{https://developer.apple.com/library/content/documentation/Xcode/Conceptual/RN-Xcode-Archive/Chapters/xc7_release_notes.html}{https://developer.apple.com/\-library/\-content/\-documentation/\-Xcode/\-Conceptual/\-RN-Xcode-Archive/\-Chapters/\-xc7\_release\_notes.html}},
    4582     urldate     = {2017-04-04}
    4583 }
    4584 
    45854555@book{Beta,
    45864556    keywords    = {Beta, object oriented, concurrency, exceptions},
    … …  
    48694839    journal     = {Computer Languages},
    48704840    year        = 1987,
    4871     volume      = 12,
    4872     number      = {3/4},
    4873     pages       = {163-172},
     4841    volume      = 12, number = {3/4}, pages = {163-172},
    48744842    abstract    = {
    48754843        Packages in the Ada language provide a mechanism for extending the
    … …  
    58835851    organization= {The Rust Project Developers},
    58845852    year        = 2015,
    5885     note        = {\href{https://doc.rust-lang.org/reference.html}{https://\-doc.rust-lang\-.org/\-reference.html}},
     5853    note        = {\href{https://doc.rust-lang.org/reference.html}{https://\-doc.rust-lang.org/\-reference.html}},
    58865854}
    58875855
    … …  
    65816549}
    65826550
    6583 @online{TIOBE,
    6584     contributer = {pabuhr@plg},
    6585     author      = {{TIOBE Index}},
    6586     year        = {March 2017},
    6587     url         = {http://www.tiobe.com/tiobe_index},
    6588 }
    6589 
    65906551@misc{Bumbulis90,
    65916552    keywords    = {parameter inference, ForceN},
    … …  
    65946555    title       = {Towards Making Signatures First-Class},
    65956556    howpublished= {personal communication},
    6596     month       = sep,
    6597     year        = 1990,
     6557    month       = sep, year = 1990,
    65986558    note        = {}
    65996559}
    … …  
    69016861}
    69026862
    6903 @online{Vala,
    6904     keywords = {GObject, Vala},
    6905     contributor = {a3moss@uwaterloo.ca},
    6906     author = {{The GNOME Project}},
    6907     title = {Vala Reference Manual},
    6908     year = 2017,
    6909     url = {https://wiki.gnome.org/Projects/Vala/Manual},
    6910     urldate = {2017-04-04}
    6911 }
    6912 
    69136863@inproceedings{Amdahl67,
    69146864    author      = {Gene M. Amdahl},

  • doc/generic_types/acmart.cls

    rc51b5a3 raf68f0a  
    354354\let\@footnotemark@nolink\@footnotemark
    355355\let\@footnotetext@nolink\@footnotetext
    356 \RequirePackage[bookmarksnumbered,breaklinks]{hyperref}
     356\RequirePackage[bookmarksnumbered]{hyperref}
    357357\urlstyle{rm}
    358358\ifcase\ACM@format@nr

  • doc/generic_types/generic_types.tex

    rc51b5a3 raf68f0a  
    2828\newcommand{\CCseventeen}{\rm C\kern-.1em\hbox{+\kern-.25em+}17\xspace} % C++17 symbolic name
    2929\newcommand{\CCtwenty}{\rm C\kern-.1em\hbox{+\kern-.25em+}20\xspace} % C++20 symbolic name
    30 \newcommand{\CS}{C\raisebox{-0.7ex}{\Large$^\sharp$}\xspace}
    31 \newcommand{\Textbf}[1]{{\color{red}\textbf{#1}}}
    3230
    3331\newcommand{\TODO}[1]{\textbf{TODO}: {\itshape #1}} % TODO included
    … …  
    5149stringstyle=\tt,                                                                                % use typewriter font
    5250tabsize=4,                                                                                              % 4 space tabbing
    53 xleftmargin=\parindentlnth,                                                             % indent code to paragraph indentation
     51xleftmargin=\parindent,                                                                 % indent code to paragraph indentation
    5452%mathescape=true,                                                                               % LaTeX math escape in CFA code $...$
    5553escapechar=\$,                                                                                  % LaTeX escape in CFA code
    … …  
    126124\maketitle
    127125
    128 
    129 \section{Introduction and Background}
    130 
    131 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects. This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
    132 The \citet{TIOBE} ranks the top 5 most popular programming languages as: Java 16\%, \Textbf{C 7\%}, \Textbf{\CC 5\%}, \CS 4\%, Python 4\% = 36\%, where the next 50 languages are less than 3\% each with a long tail. The top 3 rankings over the past 30 years are:
    133 \lstDeleteShortInline@
    134 \begin{center}
    135 \setlength{\tabcolsep}{10pt}
    136 \begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
    137                 & 2017  & 2012  & 2007  & 2002  & 1997  & 1992  & 1987          \\
    138 \hline
    139 Java    & 1             & 1             & 1             & 3             & 13    & -             & -                     \\
    140 \hline
    141 \Textbf{C}      & \Textbf{2}& \Textbf{2}& \Textbf{2}& \Textbf{1}& \Textbf{1}& \Textbf{1}& \Textbf{1}    \\
    142 \hline
    143 \CC             & 3             & 3             & 3             & 3             & 2             & 2             & 4                     \\
    144 \end{tabular}
    145 \end{center}
    146 \lstMakeShortInline@
    147 Love it or hate it, C is extremely popular, highly used, and one of the few system's languages.
    148 In many cases, \CC is often used solely as a better C.
    149 Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
    150 
    151 \CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. The four key design goals for \CFA~\citep{Bilson03} are:
    152 (1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;
    153 (2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler;
    154 (3) \CFA code must be at least as portable as standard C code;
    155 (4) Extensions introduced by \CFA must be translated in the most efficient way possible.
    156 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. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance.
    157 
    158 This paper identifies shortcomings in existing approaches to generic and variadic data types in C-like languages and presents a design for generic and variadic types avoiding those shortcomings. 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. The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance.
    159 
     126\section{Introduction \& Background}
     127
     128\CFA\footnote{Pronounced ``C-for-all'', and written \CFA or Cforall.} is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. Four key design goals were set out in the original design of \CFA~\citep{Bilson03}:
     129\begin{enumerate}
     130\item The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler.
     131\item Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler.
     132\item \CFA code must be at least as portable as standard C code.
     133\item Extensions introduced by \CFA must be translated in the most efficient way possible.
     134\end{enumerate}
     135These goals ensure existing C code-bases can be converted to \CFA incrementally and with minimal effort, and C programmers can productively generate \CFA code without training beyond the features they wish to employ. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance.
     136
     137\CFA has been previously extended with polymorphic functions and name overloading (including operator overloading) by \citet{Bilson03}, and deterministically-executed constructors and destructors by \citet{Schluntz17}. This paper builds on those contributions, identifying shortcomings in existing approaches to generic and variadic data types in C-like languages and presenting a design of generic and variadic types as as extension of the \CFA language that avoids those shortcomings. Particularly, the solution we present is both reusable and type-checked, as well as conforming to the design goals of \CFA and ergonomically using existing C abstractions. We have empirically compared our new design to both standard C and \CC; the results show that this design is \TODO{awesome, I hope}.
    160138
    161139\subsection{Polymorphic Functions}
    162140\label{sec:poly-fns}
    163141
    164 \CFA's polymorphism was originally formalized by \citet{Ditchfield92}, and first implemented by \citet{Bilson03}. The signature feature of \CFA is parametric-polymorphic functions where functions are generalized using a @forall@ clause (giving the language its name):
     142\CFA's polymorphism was originally formalized by \citet{Ditchfield92}, and first implemented by \citet{Bilson03}. The signature feature of \CFA is parametric-polymorphic functions; such functions are written using a @forall@ clause (which gives the language its name):
    165143\begin{lstlisting}
    166144`forall( otype T )` T identity( T val ) { return val; }
    167145int forty_two = identity( 42 );                         $\C{// T is bound to int, forty\_two == 42}$
    168146\end{lstlisting}
    169 The @identity@ function above can be applied to any complete \emph{object type} (or @otype@). The 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. 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. If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \emph{data type} (or @dtype@).
    170 
    171 Here, the runtime cost of polymorphism is spread over each polymorphic call, due to passing more arguments to polymorphic functions; preliminary experiments have shown this overhead is similar to \CC virtual function calls. An advantage of this design is that, unlike \CC template functions, \CFA polymorphic functions are compatible with C \emph{separate} compilation, preventing code bloat.
    172 
    173 Since bare polymorphic-types provide only a narrow set of available operations, \CFA provides a \emph{type assertion} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable. For example, the function @twice@ can be defined using the \CFA syntax for operator overloading:
    174 \begin{lstlisting}
    175 forall( otype T `| { T ?+?(T, T); }` ) T twice( T x ) { return x + x; } $\C{// ? denotes operands}$
     147The @identity@ function above can be applied to any complete object-type (or ``@otype@''). The type variable @T@ is transformed into a set of additional implicit parameters to @identity@ that encode sufficient information about @T@ to create and return a variable of that type. 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. If this extra information is not needed, \eg for a pointer, the type parameter can be declared as @dtype T@, where @dtype@ is short for ``data type''.
     148
     149Here, the runtime cost of polymorphism is spread over each polymorphic call, due to passing more arguments to polymorphic functions; preliminary experiments have shown this overhead to be similar to \CC virtual function calls. An advantage of this design is that, unlike \CC template functions, \CFA @forall@ functions are compatible with C separate compilation.
     150
     151Since bare polymorphic-types provide only a narrow set of available operations, \CFA provides a \emph{type assertion} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type variable. For instance, @twice@ can be defined using the \CFA syntax for operator overloading:
     152\begin{lstlisting}
     153forall( otype T | { T `?`+`?`(T, T); } )        $\C{// ? denotes operands}$
     154  T twice( T x ) { return x + x; }                      $\C{// (2)}$
    176155int val = twice( twice( 3.7 ) );
    177156\end{lstlisting}
    178 which works for any type @T@ with a matching addition operator. 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@. 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{Ada} in its type analysis. The first approach has a late conversion from @int@ to @double@ on the final assignment, while the second has an eager conversion to @int@. \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition.
    179 
    180 Crucial to the design of a new programming language are the libraries to access thousands of external software features.
    181 \CFA inherits a massive compatible library-base, where other programming languages must rewrite or provide fragile inter-language communication with C.
    182 A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@ to binary search a sorted floating-point array:
     157which works for any type @T@ with an addition operator defined. The translator accomplishes this polymorphism by creating a wrapper function for calling @+@ with @T@ bound to @double@, then providing this function to the first call of @twice@. It then has the option of using the same @twice@ again 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 in its type analysis. The first approach has a late conversion from integer to floating-point on the final assignment, while the second has an eager conversion to integer. \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach.
     158
     159Monomorphic specializations of polymorphic functions can satisfy polymorphic type-assertions.
     160% \begin{lstlisting}
     161% forall(otype T `| { T twice(T); }`)           $\C{// type assertion}$
     162% T four_times(T x) { return twice( twice(x) ); }
     163% double twice(double d) { return d * 2.0; }    $\C{// (1)}$
     164% double magic = four_times(10.5);                      $\C{// T bound to double, uses (1) to satisfy type assertion}$
     165% \end{lstlisting}
     166\begin{lstlisting}
     167forall( otype T `| { int ?<?( T, T ); }` )      $\C{// type assertion}$
     168  void qsort( const T * arr, size_t size );
     169forall( otype T `| { int ?<?( T, T ); }` )      $\C{// type assertion}$
     170  T * bsearch( T key, const T * arr, size_t size );
     171double vals[10] = { /* 10 floating-point values */ };
     172qsort( vals, 10 );                                                      $\C{// sort array}$
     173double * val = bsearch( 5.0, vals, 10 );        $\C{// binary search sorted array for key}$
     174\end{lstlisting}
     175@qsort@ and @bsearch@ can only be called with arguments for which there exists a function named @<@ taking two arguments of the same type and returning an @int@ value.
     176Here, the built-in monomorphic specialization of @<@ for type @double@ is passed as an additional implicit parameter to the calls of @qsort@ and @bsearch@.
     177
     178Crucial to the design of a new programming language are the libraries to access thousands of external features.
     179\CFA inherits a massive compatible library-base, where other programming languages have to rewrite or provide fragile inter-language communication with C.
     180A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@, shown here searching a floating-point array:
    183181\begin{lstlisting}
    184182void * bsearch( const void * key, const void * base, size_t nmemb, size_t size,
    … …  
    186184int comp( const void * t1, const void * t2 ) { return *(double *)t1 < *(double *)t2 ? -1 :
    187185                                *(double *)t2 < *(double *)t1 ? 1 : 0; }
    188 double vals[10] = { /* 10 floating-point values */ };
    189186double key = 5.0;
    190 double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
    191 \end{lstlisting}
    192 which can be augmented simply with a generalized, type-safe, \CFA-overloaded wrappers:
     187double * val = (double *)bsearch( &key, vals, size, sizeof(vals[0]), comp );
     188\end{lstlisting}
     189but providing a type-safe \CFA overloaded wrapper.
    193190\begin{lstlisting}
    194191forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) {
    195192        int comp( const void * t1, const void * t2 ) { /* as above with double changed to T */ }
    196         return (T *)bsearch( &key, arr, size, sizeof(T), comp ); }
     193        return (T *)bsearch( &key, arr, size, sizeof(T), comp );
     194}
    197195forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
    198196        T *result = bsearch( key, arr, size );  $\C{// call first version}$
    199         return result ? result - arr : size; }  $\C{// pointer subtraction includes sizeof(T)}$
     197        return result ? result - arr : size;            $\C{// pointer subtraction includes sizeof(T)}$
     198}
    200199double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
    201200int posn = bsearch( 5.0, vals, 10 );
    202201\end{lstlisting}
    203202The nested routine @comp@ provides the hidden interface from typed \CFA to untyped (@void *@) C, plus the cast of the result.
    204 As well, an alternate kind of return is made available: position versus pointer to found element.
     203As well, an alternate kind of return is made available, position versus pointer to found element.
    205204\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 templated @bsearch@.
    206205
    207 \CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations.
    208 For example, it is possible to write a type-safe \CFA wrapper @malloc@ based on the C @malloc@:
    209 \begin{lstlisting}
    210 forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)(void *)malloc( (size_t)sizeof(T) ); }
    211 int * ip = malloc();                                            $\C{// select type and size from left-hand side}$
    212 double * dp = malloc();
    213 struct S {...} * sp = malloc();
    214 \end{lstlisting}
    215 where the return type supplies the type/size of the allocation, which is impossible in most type systems.
    216 
    217 Call-site inferencing and nested functions provide a localized form of inheritance. For example, the \CFA @qsort@ only sorts in ascending order using @<@. However, it is trivial to locally change this behaviour:
    218 \begin{lstlisting}
    219 forall( otype T | { int ?<?( T, T ); } ) void qsort( const T * arr, size_t size ) { /* use C qsort */ }
    220 {       int ?<?( double x, double y ) { return x `>` y; }       $\C{// locally override behaviour}$
     206Call-site inferencing and nested functions provide a localized form of inheritance. For example, @qsort@ only sorts in ascending order using @<@. However, it is trivial to locally change this behaviour:
     207\begin{lstlisting}
     208{   int ?<?( double x, double y ) { return x `>` y; }   $\C{// override behaviour}$
    221209        qsort( vals, size );                                    $\C{// descending sort}$
    222210}
    223211\end{lstlisting}
    224212Within the block, the nested version of @<@ performs @>@ and this local version overrides the built-in @<@ so it is passed to @qsort@.
    225 Hence, programmers can easily form a local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
    226 
    227 Finally, \CFA allows variable overloading:
     213Hence, programmers can easily form new local environments to maximize reuse of existing functions and types.
     214
     215Finally, variables may be overloaded:
    228216\lstDeleteShortInline@
    229217\par\smallskip
    … …  
    244232\smallskip\par\noindent
    245233Hence, the single name @MAX@ replaces all the C type-specific names: @SHRT_MAX@, @INT_MAX@, @DBL_MAX@.
    246 As well, restricted constant overloading is allowed for the values @0@ and @1@, which have special status in C, \eg the value @0@ is both an integer and a pointer literal, so its meaning depends on context.
    247 In addition, several operations are defined in terms values @0@ and @1@.
    248 For example,
    249 \begin{lstlisting}
    250 int x;
    251 if (x)        // if (x != 0)
    252         x++;    //   x += 1;
    253 \end{lstlisting}
    254 Every if statement in C compares the condition with @0@, and every increment and decrement operator is semantically equivalent to adding or subtracting the value @1@ and storing the result.
    255 Due to these rewrite rules, the values @0@ and @1@ have the types @zero_t@ and @one_t@ in \CFA, which allows overloading various operations for new types that seamlessly connect to all special @0@ and @1@ contexts.
    256 The types @zero_t@ and @one_t@ have special built in implicit conversions to the various integral types, and a conversion to pointer types for @0@, which allows standard C code involving @0@ and @1@ to work as normal.
    257 
    258234
    259235\subsection{Traits}
    260236
    261 \CFA provides \emph{traits} to name a group of type assertions, where the trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration:
     237\CFA provides \emph{traits} to name a group of type assertions:
     238% \begin{lstlisting}
     239% trait has_magnitude(otype T) {
     240%     _Bool ?<?(T, T);                                          $\C{// comparison operator for T}$
     241%     T -?(T);                                                          $\C{// negation operator for T}$
     242%     void ?{}(T*, zero_t);                                     $\C{// constructor from 0 literal}$
     243% };
     244% forall(otype M | has_magnitude(M))
     245% M abs( M m ) {
     246%     M zero = { 0 };                                                   $\C{// uses zero\_t constructor from trait}$
     247%     return m < zero ? -m : m;
     248% }
     249% forall(otype M | has_magnitude(M))
     250% M max_magnitude( M a, M b ) {
     251%     return abs(a) < abs(b) ? b : a;
     252% }
     253% \end{lstlisting}
    262254\begin{lstlisting}
    263255trait summable( otype T ) {
    264         void ?{}( T *, zero_t );                                $\C{// constructor from 0 literal}$
     256        void ?{}(T*, zero_t);                                   $\C{// constructor from 0 literal}$
    265257        T ?+?( T, T );                                                  $\C{// assortment of additions}$
    266258        T ?+=?( T *, T );
    267259        T ++?( T * );
    268         T ?++( T * ); };
    269 forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) {  // use trait
    270         `T` total = { `0` };                                    $\C{// instantiate T from 0 by calling its constructor}$
     260        T ?++( T * );
     261};
     262forall( otype T | summable( T ) )
     263  T sum( T a[$\,$], size_t size ) {
     264        T total = { 0 };                                                $\C{// instantiate T from 0}$
    271265        for ( unsigned int i = 0; i < size; i += 1 )
    272                 total `+=` a[i];                                        $\C{// select appropriate +}$
    273         return total; }
    274 \end{lstlisting}
     266                total += a[i];                                          $\C{// select appropriate +}$
     267        return total;
     268}
     269\end{lstlisting}
     270The trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration.
    275271
    276272In fact, the set of operators is incomplete, \eg no assignment, but @otype@ is syntactic sugar for the following implicit trait:
    277273\begin{lstlisting}
    278 trait otype( dtype T | sized(T) ) {  // sized is a pseudo-trait for types with known size and alignment
     274trait otype( dtype T | sized(T) ) {
     275        // sized is a compiler-provided pseudo-trait for types with known size and alignment}
    279276        void ?{}( T * );                                                $\C{// default constructor}$
    280277        void ?{}( T *, T );                                             $\C{// copy constructor}$
    281278        void ?=?( T *, T );                                             $\C{// assignment operator}$
    282         void ^?{}( T * ); };                                    $\C{// destructor}$
    283 \end{lstlisting}
    284 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.
    285 % As an example, the @sum@ function produces generated code something like the following (simplified for clarity and brevity)\TODO{fix example, maybe elide, it's likely too long with the more complicated function}:
    286 % \begin{lstlisting}
    287 % void abs( size_t _sizeof_M, size_t _alignof_M,
    288 %               void (*_ctor_M)(void*), void (*_copy_M)(void*, void*),
    289 %               void (*_assign_M)(void*, void*), void (*_dtor_M)(void*),
    290 %               _Bool (*_lt_M)(void*, void*), void (*_neg_M)(void*, void*),
    291 %       void (*_ctor_M_zero)(void*, int),
    292 %               void* m, void* _rtn ) {                         $\C{// polymorphic parameter and return passed as void*}$
    293 %                                                                                       $\C{// M zero = { 0 };}$
    294 %       void* zero = alloca(_sizeof_M);                 $\C{// stack allocate zero temporary}$
    295 %       _ctor_M_zero(zero, 0);                                  $\C{// initialize using zero\_t constructor}$
    296 %                                                                                       $\C{// return m < zero ? -m : m;}$
    297 %       void *_tmp = alloca(_sizeof_M);
    298 %       _copy_M( _rtn,                                                  $\C{// copy-initialize return value}$
    299 %               _lt_M( m, zero ) ?                                      $\C{// check condition}$
    300 %                (_neg_M(m, _tmp), _tmp) :                      $\C{// negate m}$
    301 %                m);
    302 %       _dtor_M(_tmp); _dtor_M(zero);                   $\C{// destroy temporaries}$
    303 % }
    304 % \end{lstlisting}
    305 
    306 Traits may be used for many of the same purposes as interfaces in Java or abstract base classes in \CC. Unlike Java interfaces or \CC base classes, \CFA types do not explicitly state any inheritance relationship to traits they satisfy, which is a form of structural inheritance, similar to the implementation of an interface in Go~\citep{Go}, as opposed to the nominal inheritance model of Java and \CC.
    307 
    308 Nominal inheritance can be simulated with traits using marker variables or functions:
     279        void ^?{}( T * );                                               $\C{// destructor}$
     280};
     281\end{lstlisting}
     282Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete struct type -- they can be stack-allocated using the @alloca@ compiler builtin, default or copy-initialized, assigned, and deleted. As an example, the @sum@ function produces generated code something like the following (simplified for clarity and brevity)\TODO{fix example, maybe elide, it's likely too long with the more complicated function}:
     283\begin{lstlisting}
     284void abs( size_t _sizeof_M, size_t _alignof_M,
     285                void (*_ctor_M)(void*), void (*_copy_M)(void*, void*),
     286                void (*_assign_M)(void*, void*), void (*_dtor_M)(void*),
     287                _Bool (*_lt_M)(void*, void*), void (*_neg_M)(void*, void*),
     288        void (*_ctor_M_zero)(void*, int),
     289                void* m, void* _rtn ) {                         $\C{// polymorphic parameter and return passed as void*}$
     290                                                                                        $\C{// M zero = { 0 };}$
     291        void* zero = alloca(_sizeof_M);                 $\C{// stack allocate zero temporary}$
     292        _ctor_M_zero(zero, 0);                                  $\C{// initialize using zero\_t constructor}$
     293                                                                                        $\C{// return m < zero ? -m : m;}$
     294        void *_tmp = alloca(_sizeof_M);
     295        _copy_M( _rtn,                                                  $\C{// copy-initialize return value}$
     296                _lt_M( m, zero ) ?                                      $\C{// check condition}$
     297                 (_neg_M(m, _tmp), _tmp) :                      $\C{// negate m}$
     298                 m);
     299        _dtor_M(_tmp); _dtor_M(zero);                   $\C{// destroy temporaries}$
     300}
     301\end{lstlisting}
     302
     303Semantically, traits are simply a named lists of type assertions, but they may be used for many of the same purposes that interfaces in Java or abstract base classes in \CC are used for. Unlike Java interfaces or \CC base classes, \CFA types do not explicitly state any inheritance relationship to traits they satisfy; this can be considered a form of structural inheritance, similar to implementation of an interface in Go, as opposed to the nominal inheritance model of Java and \CC. Nominal inheritance can be simulated with traits using marker variables or functions:
    309304\begin{lstlisting}
    310305trait nominal(otype T) {
    311306    T is_nominal;
    312307};
     308
    313309int is_nominal;                                                         $\C{// int now satisfies the nominal trait}$
    314310\end{lstlisting}
    315311
    316 Traits, however, are significantly more powerful than nominal-inheritance interfaces; most notably, traits may be used to declare a relationship \emph{among} multiple types, a property that may be difficult or impossible to represent in nominal-inheritance type systems:
     312Traits, however, are significantly more powerful than nominal-inheritance interfaces; most notably, traits may be used to declare a relationship among multiple types, a property that may be difficult or impossible to represent in nominal-inheritance type systems:
    317313\begin{lstlisting}
    318314trait pointer_like(otype Ptr, otype El) {
    319315    lvalue El *?(Ptr);                                          $\C{// Ptr can be dereferenced into a modifiable value of type El}$
    320316}
     317
    321318struct list {
    322319    int value;
    323     list *next;                                                         $\C{// may omit "struct" on type names as in \CC}$
     320    list *next;                                                         $\C{// may omit "struct" on type names}$
    324321};
     322
    325323typedef list *list_iterator;
    326324
    … …  
    335333One of the known shortcomings of standard C is that it does not provide reusable type-safe abstractions for generic data structures and algorithms. Broadly speaking, there are three approaches to create data structures in C. One approach is to write bespoke data structures for each context in which they are needed. 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. A second approach is to use @void*@-based polymorphism. This approach is taken by the C standard library functions @qsort@ and @bsearch@, and does allow the use of common code for common functionality. However, basing all polymorphism on @void*@ eliminates the type-checker's ability to ensure that argument types are properly matched, often requires a number of extra function parameters, and also adds pointer indirection and dynamic allocation to algorithms and data structures that would not otherwise require them. A third approach to generic code is to use pre-processor macros to generate it -- this approach does allow the generated code to be both generic and type-checked, though any errors produced may be difficult to interpret. Furthermore, writing and invoking C code as preprocessor macros is unnatural and somewhat inflexible.
    336334
    337 Other C-like languages such as \CC and Java use \emph{generic types} to produce type-safe abstract data types. \CFA implements generic types with some care taken that the generic types design for \CFA integrates efficiently and naturally with the existing polymorphic functions in \CFA while retaining backwards compatibility with C; maintaining separate compilation is a particularly important constraint on the design. However, where the concrete parameters of the generic type are known, there is no extra overhead for the use of a generic type, as for \CC templates.
     335Other C-like languages such as \CC and Java use \emph{generic types} to produce type-safe abstract data types. The authors have chosen to implement generic types as well, with some care taken that the generic types design for \CFA integrates efficiently and naturally with the existing polymorphic functions in \CFA while retaining backwards compatibility with C; maintaining separate compilation is a particularly important constraint on the design. However, where the concrete parameters of the generic type are known, there is not extra overhead for the use of a generic type.
    338336
    339337A 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:
    … …  
    360358\end{lstlisting}
    361359
    362 \CFA classifies generic types as either \emph{concrete} or \emph{dynamic}. Concrete generic types have a fixed memory layout regardless of type parameters, while dynamic generic types vary in their in-memory layout depending on their type parameters. A type may have polymorphic parameters but still be concrete; in \CFA such types are called \emph{dtype-static}. Polymorphic pointers are an example of dtype-static types -- @forall(dtype T) T*@ is a polymorphic type, but for any @T@ chosen, @T*@ has exactly the same in-memory representation as a @void*@, and can therefore be represented by a @void*@ in code generation.
    363 
    364 \CFA generic types may also specify constraints on their argument type to be checked by the compiler. For example, consider the following declaration of a sorted set-type, which ensures that the set key supports equality and relational comparison:
     360\CFA classifies generic types as either \emph{concrete} or \emph{dynamic}. Dynamic generic types vary in their in-memory layout depending on their type parameters, while concrete generic types have a fixed memory layout regardless of type parameters. A type may have polymorphic parameters but still be concrete; in \CFA such types are called \emph{dtype-static}. Polymorphic pointers are an example of dtype-static types -- @forall(dtype T) T*@ is a polymorphic type, but for any @T@ chosen, @T*@ has exactly the same in-memory representation as a @void*@, and can therefore be represented by a @void*@ in code generation.
     361
     362\CFA generic types may also specify constraints on their argument type to be checked by the compiler. For example, consider the following declaration of a sorted set type, which ensures that the set key supports comparison and tests for equality:
    365363\begin{lstlisting}
    366364forall(otype Key | { _Bool ?==?(Key, Key); _Bool ?<?(Key, Key); })
    367   struct sorted_set;
     365struct sorted_set;
    368366\end{lstlisting}
    369367
    … …  
    385383};
    386384\end{lstlisting}
    387 
    388385
    389386\subsection{Dynamic Generic Types}
    … …  
    862859Cyclone also provides capabilities for polymorphic functions and existential types~\citep{Grossman06}, similar in concept to \CFA's @forall@ functions and generic types. 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. Furthermore, Cyclone's polymorphic functions and types are restricted in that they may only abstract over types with the same layout and calling convention as @void*@, in practice only pointer types and @int@ - in \CFA terms, all Cyclone polymorphism must be dtype-static. This design provides the efficiency benefits discussed in Section~\ref{sec:generic-apps} for dtype-static polymorphism, but is more restrictive than \CFA's more general model.
    863860
    864 Apple's Objective-C \citep{obj-c-book} is another industrially successful set of extensions to C. The Objective-C language model is a fairly radical departure from C, adding object-orientation and message-passing. Objective-C implements variadic functions using the C @va_arg@ mechanism, and did not support type-checked generics until recently \citep{xcode7}, historically using less-efficient and more error-prone runtime checking of object types instead. The GObject framework \citep{GObject} also adds object-orientation with runtime type-checking and reference-counting garbage-collection to C; these are much more intrusive feature additions than those provided by \CFA, in addition to the runtime overhead of reference-counting. The Vala programming language \citep{Vala} compiles to GObject-based C, and so adds the burden of learning a separate language syntax to the aforementioned demerits of GObject as a modernization path for existing C code-bases. Java \citep{Java8} has had generic types and variadic functions since Java~5; Java's generic types are type-checked at compilation and type-erased at runtime, similar to \CFA's, though in Java each object carries its own table of method pointers, while \CFA passes the method pointers separately so as to maintain a C-compatible struct layout. Java variadic functions are simply syntactic sugar for an array of a single type, and therefore less useful than \CFA's heterogeneously-typed variadic functions. Java is also a garbage-collected, object-oriented language, with the associated resource usage and C-interoperability burdens.
    865 
    866 D \citep{D}, Go \citep{Go}, and Rust \citep{Rust} are modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in D and Go and \emph{traits} in Rust. However, each language represents dramatic departures from C in terms of language model, and none has the same level of compatibility with C as \CFA. D and Go are garbage-collected languages, imposing the associated runtime overhead. The necessity of accounting for data transfer between the managed Go runtime and the unmanaged C runtime complicates foreign-function interface between Go and C. Furthermore, 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. D restricts garbage collection to its own heap by default, while Rust is not garbage-collected, and thus has a lighter-weight runtime that is more easily interoperable with C. Rust also possesses much more powerful abstraction capabilities for writing generic code than Go. On the other hand, Rust's borrow-checker, while it does provide strong safety guarantees, is complex and difficult to learn, and imposes a distinctly idiomatic programming style on Rust. \CFA, with its more modest safety features, is significantly easier to port C code to, while maintaining the idiomatic style of the original source.
     861\TODO{Talk about GObject, other object-oriented frameworks for C (Objective-C)?}
     862
     863Go \citep{Go} and Rust \citep{Rust} are both modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in Go and \emph{traits} in Rust. However, both languages represent dramatic departures from C in terms of language model, and neither has the same level of compatibility with C as \CFA. Go is a garbage-collected language, imposing the associated runtime overhead, and complicating foreign-function calls with the necessity of accounting for data transfer between the managed Go runtime and the unmanaged C runtime. Furthermore, 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. Rust is not garbage-collected, and thus has a lighter-weight runtime that is more easily interoperable with C. It also possesses much more powerful abstraction capabilities for writing generic code than Go. On the other hand, Rust's borrow-checker, while it does provide strong safety guarantees, is complex and difficult to learn, and imposes a distinctly idiomatic programming style on Rust. \CFA, with its more modest safety features, is significantly easier to port C code to, while maintaining the idiomatic style of the original source.
    867864
    868865\section{Conclusion \& Future Work}

  • doc/proposals/concurrency/concurrency.tex

    rc51b5a3 raf68f0a  
    6161\newcommand{\uC}{$\mu$\CC}
    6262\newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace}
    63 \newcommand{\code}[1]{\lstinline[language=CFA]{#1}}
     63\newcommand{\code}[1]{\lstinline{#1}}
    6464\newcommand{\pseudo}[1]{\lstinline[language=Pseudo]{#1}}
    6565
    … …  
    160160Here, the constructor(\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual exclusion when constructing. This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} key word depending on whether or not reading an \code{size_t} is an atomic operation or not.
    161161
    162 Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without quualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity.
     162Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without wualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity.
    163163
    164164The next semantic decision is to establish when mutex/nomutex may be used as a type qualifier. Consider the following declarations:
    … …  
    368368\end{lstlisting}
    369369
    370 Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering.
    371 
    372 As for simple mutual exclusion, these semantics must also be extended to include \gls{group-acquire} :
     370Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This semantic can easily be extended to multi-monitor calls by offering the same guarantee.
    373371\begin{center}
    374372\begin{tabular}{ c @{\hskip 0.65in} c }
    375373Thread 1 & Thread 2 \\
    376374\begin{lstlisting}
    377 void foo(A & mutex a,
    378            A & mutex b) {
     375void foo(monitor & mutex a,
     376           monitor & mutex b) {
    379377        //...
    380378        wait(a.e);
    … …  
    384382foo(a, b);
    385383\end{lstlisting} &\begin{lstlisting}
    386 void bar(A & mutex a,
    387            A & mutex b) {
     384void bar(monitor & mutex a,
     385           monitor & mutex b) {
    388386        signal(a.e);
    389387}
    … …  
    395393\end{tabular}
    396394\end{center}
    397 
    398 To define the semantics of internal scheduling, it is important to look at nesting and \gls{group-acquire}. Indeed, beyond concerns about lock ordering, without scheduling the two following pseudo codes are mostly equivalent. In fact, if we assume monitors are ordered alphabetically, these two pseudo codes would probably lead to exactly the same implementation :
    399 
    400 \begin{table}[h!]
    401 \centering
    402 \begin{tabular}{c c}
    403 \begin{lstlisting}[language=pseudo]
    404 monitor A, B, C
    405 
    406 acquire A
    407         acquire B & C
    408 
    409                         //Do stuff
    410 
    411         release B & C
    412 release A
    413 \end{lstlisting} &\begin{lstlisting}[language=pseudo]
    414 monitor A, B, C
    415 
    416 acquire A
    417         acquire B
    418                 acquire C
    419                         //Do stuff
    420                 release C
    421         release B
    422 release A
     395A direct extension of the single monitor semantics is to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling):
     396
     397\begin{center}
     398\begin{tabular}{|c|c|c|}
     399Context 1 & Context 2 & Context 3 \\
     400\hline
     401\begin{lstlisting}
     402condition e;
     403
     404//acquire a & b
     405void foo(monitor & mutex a,
     406           monitor & mutex b) {
     407
     408        wait(e); //release a & b
     409}
     410
     411
     412
     413
     414
     415
     416foo(a,b);
     417\end{lstlisting} &\begin{lstlisting}
     418condition e;
     419
     420//acquire a
     421void bar(monitor & mutex a,
     422           monitor & nomutex b) {
     423        foo(a,b);
     424}
     425
     426//acquire a & b
     427void foo(monitor & mutex a,
     428           monitor & mutex b) {
     429        wait(e);  //release a & b
     430}
     431
     432bar(a, b);
     433\end{lstlisting} &\begin{lstlisting}
     434condition e;
     435
     436//acquire a
     437void bar(monitor & mutex a,
     438           monitor & nomutex b) {
     439        baz(a,b);
     440}
     441
     442//acquire b
     443void baz(monitor & nomutex a,
     444           monitor & mutex b) {
     445        wait(e);  //release b
     446}
     447
     448bar(a, b);
    423449\end{lstlisting}
    424450\end{tabular}
    425 \end{table}
    426 
    427 Once internal scheduling is introduce however, semantics of \gls{group-acquire} become relevant. For example, let us look into the semantics of the following pseudo-code :
    428 
    429 \begin{lstlisting}[language=Pseudo]
    430 1: monitor A, B, C
    431 2: condition c1
    432 3:
    433 4: acquire A
    434 5:              acquire A & B & C
    435 6:                              signal c1
    436 7:              release A & B & C
    437 8: release A
    438 \end{lstlisting}
    439 
    440 Without \gls{group-acquire} signal simply baton passes the monitor lock on the next release. In the case above, we therefore need to indentify the next release. If line 8 is picked at the release point, then the signal will attempt to pass A \& B \& C, without having ownership of B \& C. Since this violates mutual exclusion, we conclude that line 7 is the only valid location where signalling can occur. The traditionnal meaning of signalling is to transfer ownership of the monitor(s) and immediately schedule the longest waiting task. However, in the discussed case, the signalling thread expects to maintain ownership of monitor A. This can be expressed in two differents ways : 1) the thread transfers ownership of all locks and reacquires A when it gets schedulled again or 2) it transfers ownership of all three monitors and then expects the ownership of A to be transferred back.
    441 
    442 However, the question is does these behavior motivate supporting acquireing non-disjoint set of monitors. Indeed, if the previous example was modified to only acquire B \& C at line 5 (an release the accordingly) then in respects to scheduling, we could add the simplifying constraint that all monitors in a bulk will behave the same way, simplifying the problem back to a single monitor problem which has already been solved. For this constraint to be acceptble however, we need to demonstrate that in does not prevent any meaningful possibilities. And, indeed, we can look at the two previous interpretation of the above pseudo-code and conclude that supporting the acquiring of non-disjoint set of monitors does not add any expressiveness to the language.
    443 
    444 Option 1 reacquires the lock after the signal statement, this can be rewritten as follows without the need for non-disjoint sets :
    445 \begin{lstlisting}[language=Pseudo]
    446 monitor A, B, C
    447 condition c1
    448 
    449 acquire A & B & C
    450         signal c1
    451 release A & B & C
    452 acquire A
    453 
    454 release A
    455 \end{lstlisting}
    456 
    457 This pseudo code has almost exaclty the same semantics as the code acquiring intersecting sets of monitors.
    458 
    459 Option 2 uses two-way lock ownership transferring instead of reacquiring monitor A. Two-way monitor ownership transfer is normally done using signalBlock semantics, which immedietely transfers ownership of a monitor before getting the ownership back when the other thread no longer needs the monitor. While the example pseudo-code for Option 2 seems toe transfer ownership of A, B and C and only getting A back, this is not a requirement. Getting back all 3 monitors and releasing B and C differs only in performance. For this reason, the second option could arguably be rewritten as :
    460 
    461 \begin{lstlisting}[language=Pseudo]
    462 monitor A, B, C
    463 condition c1
    464 
    465 acquire A
    466         acquire B & C
    467                 signalBlock c1
    468         release B & C
    469 release A
    470 \end{lstlisting}
    471 
    472 Obviously, the difference between these two snippets of pseudo code is that the first one transfers ownership of A, B and C while the second one only transfers ownership of B and C. However, this limitation can be removed by allowing user to release extra monitors when using internal scheduling, referred to as extended internal scheduling (pattent pending) from this point on. Extended internal scheduling means the two following pseudo-codes are functionnaly equivalent :
    473 \begin{table}[h!]
    474 \centering
    475 \begin{tabular}{c @{\hskip 0.65in} c}
    476 \begin{lstlisting}[language=pseudo]
    477 monitor A, B, C
    478 condition c1
    479 
    480 acquire A
    481         acquire B & C
    482                 signalBlock c1 with A
    483         release B & C
    484 release A
    485 \end{lstlisting} &\begin{lstlisting}[language=pseudo]
    486 monitor A, B, C
    487 condition c1
    488 
    489 acquire A
    490         acquire A & B & C
    491                 signal c1
    492         release A & B & C
    493 release A
     451\end{center}
     452
     453Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
     454
     455
     456\begin{center}
     457\begin{tabular}{|c|c|c|}
     458\begin{lstlisting}
     459condition e;
     460
     461//acquire b
     462void foo(monitor & nomutex a,
     463           monitor & mutex b) {
     464        bar(a,b);
     465}
     466
     467//acquire a
     468void bar(monitor & mutex a,
     469           monitor & nomutex b) {
     470
     471        wait(e); //release a
     472                  //keep b
     473}
     474
     475foo(a, b);
     476\end{lstlisting} &\begin{lstlisting}
     477condition e;
     478
     479//acquire a & b
     480void foo(monitor & mutex a,
     481           monitor & mutex b) {
     482        bar(a,b);
     483}
     484
     485//acquire b
     486void bar(monitor & mutex a,
     487           monitor & nomutex b) {
     488
     489        wait(e); //release b
     490                  //keep a
     491}
     492
     493foo(a, b);
     494\end{lstlisting} &\begin{lstlisting}
     495condition e;
     496
     497//acquire a & b
     498void foo(monitor & mutex a,
     499           monitor & mutex b) {
     500        bar(a,b);
     501}
     502
     503//acquire none
     504void bar(monitor & nomutex a,
     505           monitor & nomutex b) {
     506
     507        wait(e); //release a & b
     508                  //keep none
     509}
     510
     511foo(a, b);
    494512\end{lstlisting}
    495513\end{tabular}
    496 \end{table}
    497 
    498 It must be stated that the extended internal scheduling only makes sense when using wait and signalBlock, since they need to prevent barging, which cannot be done in the context of signal since the ownership transfer is strictly one-directionnal.
    499 
    500 One critic that could arise is that extended internal schedulling is not composable since signalBlock must be explicitly aware of which context it is in. However, this argument is not relevant since acquire A, B and C in a context where a subset of them is already acquired cannot be achieved without spurriously releasing some locks or having an oracle aware of all monitors. Therefore, composability of internal scheduling is no more an issue than composability of monitors in general.
    501 
    502 The main benefit of using extended internal scheduling is that it offers the same expressiveness as intersecting monitor set acquiring but greatly simplifies the selection of a leader (or representative) for a group of monitor. Indeed, when using intersecting sets, it is not obvious which set intersects with other sets which means finding a leader representing only the smallest scope is a hard problem. Where as when using disjoint sets, any monitor that would be intersecting must be specified in the extended set, the leader can be chosen as any monitor in the primary set.
    503 
    504 % We need to make sure the semantics for internally scheduling N monitors are a natural extension of the single monitor semantics. For this reason, we introduce the concept of \gls{mon-ctx}. In terms of context internal scheduling means "releasing a \gls{mon-ctx} and waiting for an other thread to acquire the same \gls{mon-ctx} and baton-pass it back to the initial thread". This definitions requires looking into what a \gls{mon-ctx} is and what the semantics of waiting and baton-passing are.
    505 
    506 % \subsubsection{Internal scheduling: Context} \label{insched-context}
    507 % Monitor scheduling operations are defined in terms of the context they are in. In languages that only supports operations on a single monitor at once, the context is completly defined by which most recently acquired monitors. Indeed, acquiring several monitors will form a stack of monitors which will be released in FILO order. In \CFA, a \gls{mon-ctx} cannot be simply defined by the last monitor that was acquired since \gls{group-acquire} means multiple monitors can be "the last monitor acquired". The \gls{mon-ctx} is therefore defined as the last set of monitors to have been acquired. This means taht when any new monitor is acquired, the group it belongs to is the new \gls{mon-ctx}. Correspondingly, if any monitor is released, the \gls{mon-ctx} reverts back to the context that was used prior to the monitor being acquired. In the most common case, \gls{group-acquire} means every monitor of a group will be acquired in released at the same time. However, since every monitor has its own recursion level, \gls{group-acquire} does not prevent users from reacquiring certain monitors while acquireing new monitors in the same operation. For example :
    508 
    509 % \begin{lstlisting}
    510 % //Forward declarations
    511 % monitor a, b, c
    512 % void foo( monitor & mutex a,
    513 %             monitor & mutex b);
    514 % void bar( monitor & mutex a,
    515 %             monitor & mutex b);
    516 % void baz( monitor & mutex a,
    517 %             monitor & mutex b,
    518 %             monitor & mutex c);
    519 
    520 % //Routines defined inline to illustrate context changed compared to the stack
    521 
    522 % //main thread
    523 % foo(a, b) {
    524 %       //thread calls foo
    525 %       //acquiring context a & b
    526 
    527 %       baz(a, b) {
    528 %               //thread calls baz
    529 %               //no context change
    530 
    531 %               bar(a, b, c) {
    532 %                       //thread calls bar
    533 %                       //acquiring context a & b & c
    534 
    535 %                       //Do stuff
    536 
    537 %                       return;             
    538 %                       //call to bar returns
    539 %               }
    540 %               //context back to a & b
    541 
    542 %               return;
    543 %               //call to baz returns
    544 %       }
    545 %       //no context change
    546 
    547 %       return;
    548 %       //call to foo returns
    549 % }
    550 % //context back to initial state
    551 
    552 % \end{lstlisting}
    553 
    554 % As illustrated by the previous example, context changes can be caused by only one of the monitors comming into context or going out of context.
    555 
    556 % \subsubsection{Internal scheduling: Waiting} \label{insched-wait}
    557 
    558 % \subsubsection{Internal scheduling: Baton Passing} \label{insched-signal}
    559 % Baton passing in internal scheduling is done in terms of \code{signal} and \code{signalBlock}\footnote{Arguably, \code{signal_now} is a more evocative name and \code{signal} could be changed appropriately. }. While \code{signalBlock} is the more straight forward way of baton passing, transferring ownership immediately, it must rely on \code{signal} which is why t is discussed first.
    560 % \code{signal} has for effect to transfer the current context to another thread when the context would otherwise be released. This means that instead of releasing the concerned monitors, the first thread on the condition ready-queue is scheduled to run. The monitors are not released and when the signalled thread runs, it assumes it regained ownership of all the monitors it had in its context.
    561 
    562 % \subsubsection{Internal scheduling: Implementation} \label{insched-impl}
    563 % Too implement internal scheduling, three things are need : a data structure for waiting tasks, a data structure for signalled task and a leaving procedure to run the signalled task. In the case of both data structures, it is desireable to have to use intrusive data structures in order to prevent the need for any dynamic allocation. However, in both cases being able to queue several items in the same position in a queue is non trivial, even more so in the presence of concurrency. However, within a given \gls{mon-ctx}, all monitors have exactly the same behavior in regards to scheduling. Therefore, the problem of queuing multiple monitors at once can be ignored by choosing one monitor to represent every monitor in a context. While this could prove difficult in other situations, \gls{group-acquire} requires that the monitors be sorted according to some stable predicate. Since monitors are sorted in all contexts, the representative can simply be the first in the list. Choosing a representative means a simple intrusive queue inside the condition is sufficient to implement the data structure for both waiting and signalled monitors.
    564 
    565 % Since \CFA monitors don't have a complete image of the \gls{mon-ctx}, choosing the representative and maintaning the current context information cannot easily be done by any single monitors. However, as discussed in section [Missing section here], monitor mutual exclusion is implemented using an raii object which is already in charge of sorting monitors. This object has a complete picture of the \gls{mon-ctx} which means it is well suited to choose the reprensentative and detect context changes.
    566 
    567 % \newpage
    568 % \begin{lstlisting}
    569 % void ctor( monitor ** _monitors, int _count ) {
    570 %       bool ctx_changed = false;
    571 %       for( mon in _monitors ) {
    572 %               ctx_changed = acquire( mon ) || ctx_changed;
    573 %       }
    574 
    575 %       if( ctx_changed ) {
    576 %               set_representative();
    577 %               set_context();
    578 %       }
    579 % }
    580 
    581 % void dtor( monitor ** _monitors, int _count ) {
    582 %       if( context_will_exit( _monitors, count ) ) {
    583 %               baton_pass();
    584 %               return;
    585 %       }
    586 
    587 %       for( mon in _monitors ) {
    588 %               release( mon );
    589 %       }
    590 % }
    591 
    592 % \end{lstlisting}
    593 
    594 
    595 
    596 % A direct extension of the single monitor semantics is to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling):
    597 
    598 % \begin{table}[h!]
    599 % \centering
    600 % \begin{tabular}{|c|c|c|}
    601 % Context 1 & Context 2 & Context 3 \\
    602 % \hline
    603 % \begin{lstlisting}
    604 % condition e;
    605 
    606 % //acquire a & b
    607 % void foo(monitor & mutex a,
    608 %            monitor & mutex b) {
    609 
    610 %       wait(e); //release a & b
    611 % }
    612 
    613 
    614 
    615 
    616 
    617 
    618 % foo(a,b);
    619 % \end{lstlisting} &\begin{lstlisting}
    620 % condition e;
    621 
    622 % //acquire a
    623 % void bar(monitor & mutex a,
    624 %            monitor & nomutex b) {
    625 %       foo(a,b);
    626 % }
    627 
    628 % //acquire a & b
    629 % void foo(monitor & mutex a,
    630 %            monitor & mutex b) {
    631 %       wait(e);  //release a & b
    632 % }
    633 
    634 % bar(a, b);
    635 % \end{lstlisting} &\begin{lstlisting}
    636 % condition e;
    637 
    638 % //acquire a
    639 % void bar(monitor & mutex a,
    640 %            monitor & nomutex b) {
    641 %       baz(a,b);
    642 % }
    643 
    644 % //acquire b
    645 % void baz(monitor & nomutex a,
    646 %            monitor & mutex b) {
    647 %       wait(e);  //release b
    648 % }
    649 
    650 % bar(a, b);
    651 % \end{lstlisting}
    652 % \end{tabular}
    653 % \end{table}
    654 
    655 % Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
    656 
    657 
    658 % \begin{center}
    659 % \begin{tabular}{|c|c|c|}
    660 % \begin{lstlisting}
    661 % condition e;
    662 
    663 % //acquire b
    664 % void foo(monitor & nomutex a,
    665 %            monitor & mutex b) {
    666 %       bar(a,b);
    667 % }
    668 
    669 % //acquire a
    670 % void bar(monitor & mutex a,
    671 %            monitor & nomutex b) {
    672 
    673 %       wait(e); //release a
    674 %                 //keep b
    675 % }
    676 
    677 % foo(a, b);
    678 % \end{lstlisting} &\begin{lstlisting}
    679 % condition e;
    680 
    681 % //acquire a & b
    682 % void foo(monitor & mutex a,
    683 %            monitor & mutex b) {
    684 %       bar(a,b);
    685 % }
    686 
    687 % //acquire b
    688 % void bar(monitor & mutex a,
    689 %            monitor & nomutex b) {
    690 
    691 %       wait(e); //release b
    692 %                 //keep a
    693 % }
    694 
    695 % foo(a, b);
    696 % \end{lstlisting} &\begin{lstlisting}
    697 % condition e;
    698 
    699 % //acquire a & b
    700 % void foo(monitor & mutex a,
    701 %            monitor & mutex b) {
    702 %       bar(a,b);
    703 % }
    704 
    705 % //acquire none
    706 % void bar(monitor & nomutex a,
    707 %            monitor & nomutex b) {
    708 
    709 %       wait(e); //release a & b
    710 %                 //keep none
    711 % }
    712 
    713 % foo(a, b);
    714 % \end{lstlisting}
    715 % \end{tabular}
    716 % \end{center}
    717 % Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined.
    718 
    719 % These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines :
    720 % \begin{center}
    721 % \begin{tabular}{ c c c }
    722 % \begin{lstlisting}
    723 %       condition e;
    724 
    725 %       //acquire a & b
    726 %       void foo(monitor & mutex a,
    727 %                  monitor & mutex b) {
    728 %               bar(a,b);
    729 %       }
    730 
    731 %       //acquire b
    732 %       void bar(monitor & mutex a,
    733 %                  monitor & nomutex b) {
    734 
    735 %               wait(e); //release b
    736 %                         //keep a
    737 %       }
    738 
    739 %       foo(a, b);
    740 % \end{lstlisting} &\begin{lstlisting}
    741 %       =>
    742 % \end{lstlisting} &\begin{lstlisting}
    743 %       condition e;
    744 
    745 %       //acquire a & b
    746 %       void foo(monitor & mutex a,
    747 %                  monitor & mutex b) {
    748 %               wait_release(e,b); //release b
    749 %                                        //keep a
    750 %       }
    751 
    752 %       foo(a, b);
    753 % \end{lstlisting}
    754 % \end{tabular}
    755 % \end{center}
    756 
    757 % Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
    758 
    759 % Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section.
    760 % \\
     514\end{center}
     515Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined.
     516
     517These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines :
     518\begin{center}
     519\begin{tabular}{ c c c }
     520\begin{lstlisting}
     521        condition e;
     522
     523        //acquire a & b
     524        void foo(monitor & mutex a,
     525                   monitor & mutex b) {
     526                bar(a,b);
     527        }
     528
     529        //acquire b
     530        void bar(monitor & mutex a,
     531                   monitor & nomutex b) {
     532
     533                wait(e); //release b
     534                          //keep a
     535        }
     536
     537        foo(a, b);
     538\end{lstlisting} &\begin{lstlisting}
     539        =>
     540\end{lstlisting} &\begin{lstlisting}
     541        condition e;
     542
     543        //acquire a & b
     544        void foo(monitor & mutex a,
     545                   monitor & mutex b) {
     546                wait_release(e,b); //release b
     547                                         //keep a
     548        }
     549
     550        foo(a, b);
     551\end{lstlisting}
     552\end{tabular}
     553\end{center}
     554
     555Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
     556
     557Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section.
     558\\
    761559
    762560% ####### #     # #######         #####   #####  #     # ####### ######

  • doc/proposals/concurrency/glossary.tex

    rc51b5a3 raf68f0a  
    1414
    1515\longnewglossaryentry{group-acquire}
    16 {name={bulk acquiring}}
     16{name={bulked acquiring}}
    1717{
    1818Implicitly acquiring several monitors when entering a monitor.
    19 }
    20 
    21 \longnewglossaryentry{mon-ctx}
    22 {name={monitor context}}
    23 {
    24 The state of the current thread regarding which monitors are owned.
    2519}
    2620

  • doc/proposals/concurrency/style.tex

    rc51b5a3 raf68f0a  
    11\input{common}                                          % bespoke macros used in the document
    2 
    3 \CFADefaultStyle
    42
    53\lstset{

  • doc/proposals/concurrency/version

    rc51b5a3 raf68f0a  
    1 0.7.134
     10.7.61

  • doc/refrat/refrat.tex

    rc51b5a3 raf68f0a  
    1111%% Created On       : Wed Apr  6 14:52:25 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Wed Apr  5 23:23:28 2017
    14 %% Update Count     : 79
     13%% Last Modified On : Mon Feb 20 13:08:11 2017
     14%% Update Count     : 78
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    4848%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    4949
    50 \CFAStyle                                                                                               % use default CFA format-style
     50\CFADefaultStyle                                                                                % use default CFA format-style
    5151
    5252% inline code ©...© (copyright symbol) emacs: C-q M-)

  • doc/user/user.tex

    rc51b5a3 raf68f0a  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Wed Apr  5 23:19:40 2017
    14 %% Update Count     : 1412
     13%% Last Modified On : Thu Mar 23 09:53:57 2017
     14%% Update Count     : 1399
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    5050%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    5151
    52 \CFAStyle                                                                                               % use default CFA format-style
     52\CFADefaultStyle                                                                                % use default CFA format-style
    5353
    5454% inline code ©...© (copyright symbol) emacs: C-q M-)
    … …  
    154154\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    155155\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    156 \begin{cfa}
     156\begin{lstlisting}
    157157#include <fstream>
    158158int main( void ) {
    … …  
    160160        ®sout | x | y | z | endl;®
    161161}
    162 \end{cfa}
     162\end{lstlisting}
    163163&
    164164\begin{lstlisting}
    … …  
    245245For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
    246246Whereas, \CFA wraps each of these routines into ones with the common name ©abs©:
    247 \begin{cfa}
     247\begin{lstlisting}
    248248char abs( char );
    249 ®extern "C" {®
     249extern "C" {
    250250int abs( int );                                 §\C{// use default C routine for int}§
    251 ®}® // extern "C"
     251} // extern "C"
    252252long int abs( long int );
    253253long long int abs( long long int );
    … …  
    258258double _Complex abs( double _Complex );
    259259long double _Complex abs( long double _Complex );
    260 \end{cfa}
     260\end{lstlisting}
    261261The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
    262262Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
    … …  
    273273
    274274The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
    275 \begin{cfa}
     275\begin{lstlisting}
    276276cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
    277 \end{cfa}
     277\end{lstlisting}
    278278\CFA programs having the following ©gcc© flags turned on:
    279279\begin{description}
    … …  
    352352These preprocessor variables allow conditional compilation of programs that must work differently in these situations.
    353353For example, to toggle between C and \CFA extensions, using the following:
    354 \begin{cfa}
     354\begin{lstlisting}
    355355#ifndef __CFORALL__
    356356#include <stdio.h>                              §\C{// C header file}§
    … …  
    358358#include <fstream>                              §\C{// \CFA header file}§
    359359#endif
    360 \end{cfa}
     360\end{lstlisting}
    361361which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
    362362
    363363
    364 \section{Constants Underscores}
     364\section{Underscores in Constants}
    365365
    366366Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
    367 \begin{cfa}
     367\begin{lstlisting}
    3683682®_®147®_®483®_®648;                    §\C{// decimal constant}§
    36936956_ul;                                                  §\C{// decimal unsigned long constant}§
    … …  
    3763760x_1.ffff_ffff_p_128_l;                 §\C{// hexadecimal floating point long constant}§
    377377L_"\x_ff_ee";                                   §\C{// wide character constant}§
    378 \end{cfa}
     378\end{lstlisting}
    379379The rules for placement of underscores is as follows:
    380380\begin{enumerate}
    … …  
    396396
    397397
    398 \section{Backquote Identifiers}
    399 \label{s:BackquoteIdentifiers}
    400 
    401 \CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:
    402 \begin{cfa}
    403 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
    404 double ®`®choose®`® = 3.5;
    405 \end{cfa}
    406 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name.
    407 Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:
    408 \begin{cfa}
    409 // include file uses the CFA keyword "otype".
    410 #if ! defined( otype )                  §\C{// nesting ?}§
    411 #define otype `otype`
    412 #define __CFA_BFD_H__
    413 #endif // ! otype
    414 
    415 #include_next <bfd.h>                   §\C{// must have internal check for multiple expansion}§
    416 
    417 #if defined( otype ) && defined( __CFA_BFD_H__ )        §\C{// reset only if set}§
    418 #undef otype
    419 #undef __CFA_BFD_H__
    420 #endif // otype && __CFA_BFD_H__
    421 \end{cfa}
    422 
    423 
    424398\section{Declarations}
    425399\label{s:Declarations}
    … …  
    429403\begin{quote2}
    430404\begin{tabular}{@{}ll@{}}
    431 \begin{cfa}
     405\begin{lstlisting}
    432406int *x[5]
    433 \end{cfa}
     407\end{lstlisting}
    434408&
    435409\raisebox{-0.75\totalheight}{\input{Cdecl}}
    … …  
    440414Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site.
    441415For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    442 \begin{cfa}
     416\begin{lstlisting}
    443417int (*f())[5] {...};                    §\C{}§
    444418... (*f())[3] += 1;
    445 \end{cfa}
     419\end{lstlisting}
    446420Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
    447421While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
    … …  
    454428\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    455429\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    456 \begin{cfa}
     430\begin{lstlisting}
    457431ß[5] *ß ®int® x1;
    458432ß* [5]ß ®int® x2;
    459433ß[* [5] int]ß f®( int p )®;
    460 \end{cfa}
     434\end{lstlisting}
    461435&
    462 \begin{cfa}
     436\begin{lstlisting}
    463437®int® ß*ß x1 ß[5]ß;
    464438®int® ß(*ßx2ß)[5]ß;
    465439ßint (*ßf®( int p )®ß)[5]ß;
    466 \end{cfa}
     440\end{lstlisting}
    467441\end{tabular}
    468442\end{quote2}
    … …  
    474448\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    475449\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    476 \begin{cfa}
     450\begin{lstlisting}
    477451®*® int x, y;
    478 \end{cfa}
     452\end{lstlisting}
    479453&
    480 \begin{cfa}
     454\begin{lstlisting}
    481455int ®*®x, ®*®y;
    482 \end{cfa}
     456\end{lstlisting}
    483457\end{tabular}
    484458\end{quote2}
    … …  
    487461\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    488462\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    489 \begin{cfa}
     463\begin{lstlisting}
    490464®*® int x;
    491465int y;
    492 \end{cfa}
     466\end{lstlisting}
    493467&
    494 \begin{cfa}
     468\begin{lstlisting}
    495469int ®*®x, y;
    496470
    497 \end{cfa}
     471\end{lstlisting}
    498472\end{tabular}
    499473\end{quote2}
    … …  
    503477\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    504478\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    505 \begin{cfa}
     479\begin{lstlisting}
    506480[ 5 ] int z;
    507481[ 5 ] * char w;
    … …  
    512486        [ 5 ] * int f2;
    513487};
    514 \end{cfa}
     488\end{lstlisting}
    515489&
    516 \begin{cfa}
     490\begin{lstlisting}
    517491int z[ 5 ];
    518492char *w[ 5 ];
    … …  
    523497        int *f2[ 5 ]
    524498};
    525 \end{cfa}
     499\end{lstlisting}
    526500&
    527 \begin{cfa}
     501\begin{lstlisting}
    528502// array of 5 integers
    529503// array of 5 pointers to char
    … …  
    534508
    535509
    536 \end{cfa}
     510\end{lstlisting}
    537511\end{tabular}
    538512\end{quote2}
    … …  
    542516\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
    543517\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\
    544 \begin{cfa}
     518\begin{lstlisting}
    545519const * const int x;
    546520const * [ 5 ] const int y;
    547 \end{cfa}
     521\end{lstlisting}
    548522&
    549 \begin{cfa}
     523\begin{lstlisting}
    550524int const * const x;
    551525const int (* const y)[ 5 ]
    552 \end{cfa}
     526\end{lstlisting}
    553527&
    554 \begin{cfa}
     528\begin{lstlisting}
    555529// const pointer to const integer
    556530// const pointer to array of 5 const integers
    557 \end{cfa}
     531\end{lstlisting}
    558532\end{tabular}
    559533\end{quote2}
    … …  
    563537\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    564538\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    565 \begin{cfa}
     539\begin{lstlisting}
    566540extern [ 5 ] int x;
    567541static * const int y;
    568 \end{cfa}
     542\end{lstlisting}
    569543&
    570 \begin{cfa}
     544\begin{lstlisting}
    571545int extern x[ 5 ];
    572546const int static *y;
    573 \end{cfa}
     547\end{lstlisting}
    574548&
    575 \begin{cfa}
     549\begin{lstlisting}
    576550// externally visible array of 5 integers
    577551// internally visible pointer to constant int
    578 \end{cfa}
     552\end{lstlisting}
    579553\end{tabular}
    580554\end{quote2}
    … …  
    583557At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}}
    584558\eg:
    585 \begin{cfa}
     559\begin{lstlisting}
    586560x;                                                              §\C{// int x}§
    587561*y;                                                             §\C{// int *y}§
    588562f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
    589563f( p1, p2 ) {}                                  §\C{// int f( int p1, int p2 ) {}}§
    590 \end{cfa}
     564\end{lstlisting}
    591565
    592566Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
    … …  
    609583\begin{quote2}
    610584\begin{tabular}{@{}lll@{}}
    611 \begin{cfa}
     585\begin{lstlisting}
    612586int x;
    613587x = 3;
    614588int y;
    615589y = x;
    616 \end{cfa}
     590\end{lstlisting}
    617591&
    618592\raisebox{-0.45\totalheight}{\input{pointer1}}
    619593&
    620 \begin{cfa}
     594\begin{lstlisting}
    621595int * ®const® x = (int *)100
    622596*x = 3;                 // implicit dereference
    623597int * ®const® y = (int *)104;
    624598*y = *x;                // implicit dereference
    625 \end{cfa}
     599\end{lstlisting}
    626600\end{tabular}
    627601\end{quote2}
    … …  
    632606\begin{quote2}
    633607\begin{tabular}{@{}l|l@{}}
    634 \begin{cfa}
     608\begin{lstlisting}
    635609lda             r1,100                  // load address of x
    636610ld              r2,(r1)                   // load value of x
    637611lda             r3,104                  // load address of y
    638612st              r2,(r3)                   // store x into y
    639 \end{cfa}
     613\end{lstlisting}
    640614&
    641 \begin{cfa}
     615\begin{lstlisting}
    642616
    643617ld              r2,(100)                // load value of x
    644618
    645619st              r2,(104)                // store x into y
    646 \end{cfa}
     620\end{lstlisting}
    647621\end{tabular}
    648622\end{quote2}
    … …  
    655629\begin{quote2}
    656630\begin{tabular}{@{}ll@{}}
    657 \begin{cfa}
     631\begin{lstlisting}
    658632int x, y, ®*® p1, ®*® p2, ®**® p3;
    659633p1 = ®&®x;               // p1 points to x
    … …  
    661635p1 = ®&®y;               // p1 points to y
    662636p3 = &p2;               // p3 points to p2
    663 \end{cfa}
     637\end{lstlisting}
    664638&
    665639\raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}}
    … …  
    669643Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location.
    670644In many cases, a compiler might be able to infer the meaning:
    671 \begin{cfa}
     645\begin{lstlisting}
    672646p2 = p1 + x;                                    §\C{// compiler infers *p2 = *p1 + x;}§
    673 \end{cfa}
     647\end{lstlisting}
    674648because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
    675649\Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
    676650However, in C, the following cases are ambiguous, especially with pointer arithmetic:
    677 \begin{cfa}
     651\begin{lstlisting}
    678652p1 = p2;                                                §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§
    679653p1 = p1 + 1;                                    §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§
    680 \end{cfa}
     654\end{lstlisting}
    681655
    682656Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}.
    683657In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©.
    684 \begin{cfa}
     658\begin{lstlisting}
    685659p1 = p2;                                                §\C{// pointer address assignment}§
    686660*p1 = *p1 + 1;                                  §\C{// pointed-to value assignment / operation}§
    687 \end{cfa}
     661\end{lstlisting}
    688662which works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
    689663
    690664However, in most other situations, the pointed-to value is requested more often than the pointer address.
    691 \begin{cfa}
     665\begin{lstlisting}
    692666*p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
    693 \end{cfa}
     667\end{lstlisting}
    694668In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed.
    695669It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic:
    696 \begin{cfa}
     670\begin{lstlisting}
    697671p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15);
    698 \end{cfa}
     672\end{lstlisting}
    699673
    700674To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©.
    701 \begin{cfa}
     675\begin{lstlisting}
    702676int x, y, ®&® r1, ®&® r2, ®&&® r3;
    703677®&®r1 = &x;                                             §\C{// r1 points to x}§
    … …  
    706680®&&®r3 = ®&®&r2;                                §\C{// r3 points to r2}§
    707681r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
    708 \end{cfa}
     682\end{lstlisting}
    709683Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
    710684Hence, a reference behaves like the variable name for the current variable it is pointing-to.
    711685The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg:
    712 \begin{cfa}
     686\begin{lstlisting}
    713687r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);
    714 \end{cfa}
     688\end{lstlisting}
    715689is rewritten as:
    716 \begin{cfa}
     690\begin{lstlisting}
    717691®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
    718 \end{cfa}
     692\end{lstlisting}
    719693When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{
    720694The unary ©&© operator yields the address of its operand.
    … …  
    722696If the operand is the result of a unary ©*© operator, neither that operator nor the ©&© operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}}
    723697Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}):
    724 \begin{cfa}
     698\begin{lstlisting}
    725699(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving variable r1 not variable pointed-to by r1}§
    726 \end{cfa}
     700\end{lstlisting}
    727701Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
    728 \begin{cfa}
     702\begin{lstlisting}
    729703(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3}§
    730 \end{cfa}
     704\end{lstlisting}
    731705Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses.
    732 \begin{cfa}
     706\begin{lstlisting}
    733707int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
    734708                 &r1 = x,    &&r2 = r1,   &&&r3 = r2;
    … …  
    740714&&r3 = ...;                                             §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
    741715&&&r3 = p3;                                             §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
    742 \end{cfa}
     716\end{lstlisting}
    743717Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one.
    744718That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance.
    … …  
    750724
    751725As for a pointer, a reference may have qualifiers:
    752 \begin{cfa}
     726\begin{lstlisting}
    753727const int cx = 5;                               §\C{// cannot change cx;}§
    754728const int & cr = cx;                    §\C{// cannot change what cr points to}§
    … …  
    760734crc = 7;                                                §\C{// error, cannot change cx}§
    761735®&®crc = &cx;                                   §\C{// error, cannot change crc}§
    762 \end{cfa}
     736\end{lstlisting}
    763737Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg:
    764 \begin{cfa}
     738\begin{lstlisting}
    765739int & const r = *0;                             §\C{// where 0 is the int * zero}§
    766 \end{cfa}
     740\end{lstlisting}
    767741Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented.
    768742Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
    … …  
    772746\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    773747\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    774 \begin{cfa}
     748\begin{lstlisting}
    775749®const® * ®const® * const int ccp;
    776750®const® & ®const® & const int ccr;
    777 \end{cfa}
     751\end{lstlisting}
    778752&
    779 \begin{cfa}
     753\begin{lstlisting}
    780754const int * ®const® * ®const® ccp;
    781755
    782 \end{cfa}
     756\end{lstlisting}
    783757\end{tabular}
    784758\end{quote2}
    … …  
    788762There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding.
    789763For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
    790 \begin{cfa}
     764\begin{lstlisting}
    791765int * p = &x;                                   §\C{// both \&x and x are possible interpretations}§
    792766int & r = x;                                    §\C{// x unlikely interpretation, because of auto-dereferencing}§
    793 \end{cfa}
     767\end{lstlisting}
    794768Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression.
    795769Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator.
    796 \begin{cfa}
     770\begin{lstlisting}
    797771int & f( int & rp );                    §\C{// reference parameter and return}§
    798772z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
    799 \end{cfa}
     773\end{lstlisting}
    800774Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©.
    801775Since ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references.
    802776
    803777When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
    804 \begin{cfa}
     778\begin{lstlisting}
    805779void f( ®const® int & crp );
    806780void g( ®const® int * cpp );
    807781f( 3 );                   g( &3 );
    808782f( x + y );             g( &(x + y) );
    809 \end{cfa}
     783\end{lstlisting}
    810784Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
    811785(The ©&© is necessary for the pointer parameter to make the types match, and is a common requirement for a C programmer.)
    812786\CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.
    813 \begin{cfa}
     787\begin{lstlisting}
    814788void f( int & rp );
    815789void g( int * pp );
    816790f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
    817791f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
    818 \end{cfa}
     792\end{lstlisting}
    819793Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
    820794This conversion attempts to address the \newterm{const hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.}
    … …  
    822796
    823797While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave).
    824 \begin{cfa}
     798\begin{lstlisting}
    825799void f( int p ) {...}
    826800void (*fp)( int ) = &f;                 §\C{// pointer initialization}§
    … …  
    828802(*fp)(3);                                               §\C{// pointer invocation}§
    829803fp(3);                                                  §\C{// reference invocation}§
    830 \end{cfa}
     804\end{lstlisting}
    831805A routine variable is best described by a ©const© reference:
    832 \begin{cfa}
     806\begin{lstlisting}
    833807const void (&fp)( int ) = f;
    834808fp( 3 );
    835809fp = ...                                                §\C{// error, cannot change code}§
    836810&fp = ...;                                              §\C{// changing routine reference}§
    837 \end{cfa}
     811\end{lstlisting}
    838812because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{
    839813Dynamic code rewriting is possible but only in special circumstances.}
    840814\CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for them.
     815
     816
     817\section{Backquote Identifiers}
     818\label{s:BackquoteIdentifiers}
     819
     820\CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:
     821\begin{lstlisting}
     822int `otype` = 3;                                // make keyword an identifier
     823double `choose` = 3.5;
     824\end{lstlisting}
     825Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name.
     826Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:
     827\begin{lstlisting}
     828// include file uses the CFA keyword "otype".
     829#if ! defined( otype )                  // nesting ?
     830#define otype `otype`
     831#define __CFA_BFD_H__
     832#endif // ! otype
     833
     834#include_next <bfd.h>                   // must have internal check for multiple expansion
     835
     836#if defined( otype ) && defined( __CFA_BFD_H__ )        // reset only if set
     837#undef otype
     838#undef __CFA_BFD_H__
     839#endif // otype && __CFA_BFD_H__
     840\end{lstlisting}
    841841
    842842
    … …  
    847847\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    848848\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    849 \begin{cfa}
     849\begin{lstlisting}
    850850y = (®* int®)x;
    851851i = sizeof(®[ 5 ] * int®);
    852 \end{cfa}
     852\end{lstlisting}
    853853&
    854 \begin{cfa}
     854\begin{lstlisting}
    855855y = (®int *®)x;
    856856i = sizeof(®int *[ 5 ]®);
    857 \end{cfa}
     857\end{lstlisting}
    858858\end{tabular}
    859859\end{quote2}
    … …  
    864864\CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
    865865The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
    866 \begin{cfa}
     866\begin{lstlisting}
    867867®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
    868868        §\emph{routine body}§
    869869}
    870 \end{cfa}
     870\end{lstlisting}
    871871where routine ©f© has three output (return values) and three input parameters.
    872872Existing C syntax cannot be extended with multiple return types because it is impossible to embed a single routine name within multiple return type specifications.
    … …  
    876876The value of each local return variable is automatically returned at routine termination.
    877877Declaration qualifiers can only appear at the start of a routine definition, \eg:
    878 \begin{cfa}
     878\begin{lstlisting}
    879879®extern® [ int x ] g( int y ) {§\,§}
    880 \end{cfa}
     880\end{lstlisting}
    881881Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
    882882in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
    883 \begin{cfa}
     883\begin{lstlisting}
    884884[§\,§] g();                                             §\C{// no input or output parameters}§
    885885[ void ] g( void );                             §\C{// no input or output parameters}§
    886 \end{cfa}
     886\end{lstlisting}
    887887
    888888Routine f is called as follows:
    889 \begin{cfa}
     889\begin{lstlisting}
    890890[ i, j, ch ] = f( 3, 'a', ch );
    891 \end{cfa}
     891\end{lstlisting}
    892892The list of return values from f and the grouping on the left-hand side of the assignment is called a \newterm{return list} and discussed in Section 12.
    893893
    894894\CFA style declarations cannot be used to declare parameters for K\&R style routine definitions because of the following ambiguity:
    895 \begin{cfa}
     895\begin{lstlisting}
    896896int (*f(x))[ 5 ] int x; {}
    897 \end{cfa}
     897\end{lstlisting}
    898898The string ``©int (*f(x))[ 5 ]©'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``©[ 5 ] int x©'' declares a \CFA style parameter x of type array of 5 integers.
    899899Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string.
    900900As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
    901 \begin{cfa}
     901\begin{lstlisting}
    902902typedef int foo;
    903903int f( int (* foo) );                   §\C{// foo is redefined as a parameter name}§
    904 \end{cfa}
     904\end{lstlisting}
    905905The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
    906906The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type qualifier characters appearing to the right of the type name.
    … …  
    908908
    909909C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
    910 \begin{cfa}
     910\begin{lstlisting}
    911911[ int ] f( * int, int * );              §\C{// returns an integer, accepts 2 pointers to integers}§
    912912[ * int, int * ] f( int );              §\C{// returns 2 pointers to integers, accepts an integer}§
    913 \end{cfa}
     913\end{lstlisting}
    914914The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
    915 \begin{cfa}
     915\begin{lstlisting}
    916916#define ptoa( n, d ) int (*n)[ d ]
    917917int f( ptoa( p, 5 ) ) ...               §\C{// expands to int f( int (*p)[ 5 ] )}§
    918918[ int ] f( ptoa( p, 5 ) ) ...   §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
    919 \end{cfa}
     919\end{lstlisting}
    920920Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
    921921
    … …  
    924924
    925925\Index{Named return values} handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in:
    926 \begin{cfa}
     926\begin{lstlisting}
    927927int f() {
    928928        int x;
    … …  
    930930        return x;
    931931}
    932 \end{cfa}
     932\end{lstlisting}
    933933Because the value in the return variable is automatically returned when a \CFA routine terminates, the ©return© statement \emph{does not} contain an expression, as in:
    934934\newline
    935935\begin{minipage}{\linewidth}
    936 \begin{cfa}
     936\begin{lstlisting}
    937937®[ int x, int y ]® f() {
    938938        int z;
    … …  
    940940        ®return;® §\C{// implicitly return x, y}§
    941941}
    942 \end{cfa}
     942\end{lstlisting}
    943943\end{minipage}
    944944\newline
    945945When the return is encountered, the current values of ©x© and ©y© are returned to the calling routine.
    946946As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in:
    947 \begin{cfa}
     947\begin{lstlisting}
    948948[ int x, int y ] f() {
    949949        ...
    950950} §\C{// implicitly return x, y}§
    951 \end{cfa}
     951\end{lstlisting}
    952952In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
    953953
    … …  
    957957The syntax of the new routine prototype declaration follows directly from the new routine definition syntax;
    958958as well, parameter names are optional, \eg:
    959 \begin{cfa}
     959\begin{lstlisting}
    960960[ int x ] f ();                                 §\C{// returning int with no parameters}§
    961961[ * int ] g (int y);                    §\C{// returning pointer to int with int parameter}§
    962962[ ] h (int,char);                               §\C{// returning no result with int and char parameters}§
    963963[ * int,int ] j (int);                  §\C{// returning pointer to int and int, with int parameter}§
    964 \end{cfa}
     964\end{lstlisting}
    965965This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
    966966It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg:
    … …  
    968968\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    969969\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    970 \begin{cfa}
     970\begin{lstlisting}
    971971[ int ] f(int), g;
    972 \end{cfa}
     972\end{lstlisting}
    973973&
    974 \begin{cfa}
     974\begin{lstlisting}
    975975int f(int), g(int);
    976 \end{cfa}
     976\end{lstlisting}
    977977\end{tabular}
    978978\end{quote2}
    979979Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
    980 \begin{cfa}
     980\begin{lstlisting}
    981981extern [ int ] f (int);
    982982static [ int ] g (int);
    983 \end{cfa}
     983\end{lstlisting}
    984984
    985985
    … …  
    987987
    988988The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
    989 \begin{cfa}
     989\begin{lstlisting}
    990990* [ int x ] () fp;                      §\C{// pointer to routine returning int with no parameters}§
    991991* [ * int ] (int y) gp;         §\C{// pointer to routine returning pointer to int with int parameter}§
    992992* [ ] (int,char) hp;            §\C{// pointer to routine returning no result with int and char parameters}§
    993993* [ * int,int ] (int) jp;       §\C{// pointer to routine returning pointer to int and int, with int parameter}§
    994 \end{cfa}
     994\end{lstlisting}
    995995While parameter names are optional, \emph{a routine name cannot be specified};
    996996for example, the following is incorrect:
    997 \begin{cfa}
     997\begin{lstlisting}
    998998* [ int x ] f () fp;            §\C{// routine name "f" is not allowed}§
    999 \end{cfa}
     999\end{lstlisting}
    10001000
    10011001
    … …  
    10101010provide the ability to specify an argument to a routine call using the parameter name rather than the position of the parameter.
    10111011For example, given the routine:
    1012 \begin{cfa}
     1012\begin{lstlisting}
    10131013void p( int x, int y, int z ) {...}
    1014 \end{cfa}
     1014\end{lstlisting}
    10151015a positional call is:
    1016 \begin{cfa}
     1016\begin{lstlisting}
    10171017p( 4, 7, 3 );
    1018 \end{cfa}
     1018\end{lstlisting}
    10191019whereas a named (keyword) call may be:
    1020 \begin{cfa}
     1020\begin{lstlisting}
    10211021p( z : 3, x : 4, y : 7 );       §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
    1022 \end{cfa}
     1022\end{lstlisting}
    10231023Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
    10241024The compiler rewrites a named call into a positional call.
    … …  
    10351035Unfortunately, named arguments do not work in C-style programming-languages because a routine prototype is not required to specify parameter names, nor do the names in the prototype have to match with the actual definition.
    10361036For example, the following routine prototypes and definition are all valid.
    1037 \begin{cfa}
     1037\begin{lstlisting}
    10381038void p( int, int, int );                        §\C{// equivalent prototypes}§
    10391039void p( int x, int y, int z );
    … …  
    10411041void p( int z, int y, int x );
    10421042void p( int q, int r, int s ) {}        §\C{// match with this definition}§
    1043 \end{cfa}
     1043\end{lstlisting}
    10441044Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
    10451045Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports.
    … …  
    10481048Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching.
    10491049For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site:
    1050 \begin{cfa}
     1050\begin{lstlisting}
    10511051int f( int i, int j );
    10521052int f( int x, double y );
    … …  
    10551055f( x : 7, y : 8.1 );                    §\C{// 2nd f}§
    10561056f( 4, 5 );                                              §\C{// ambiguous call}§
    1057 \end{cfa}
     1057\end{lstlisting}
    10581058However, named arguments compound routine resolution in conjunction with conversions:
    1059 \begin{cfa}
     1059\begin{lstlisting}
    10601060f( i : 3, 5.7 );                                §\C{// ambiguous call ?}§
    1061 \end{cfa}
     1061\end{lstlisting}
    10621062Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
    10631063Adding named argument into the routine resolution algorithm does not seem worth the complexity.
    … …  
    10671067provide the ability to associate a default value with a parameter so it can be optionally specified in the argument list.
    10681068For example, given the routine:
    1069 \begin{cfa}
     1069\begin{lstlisting}
    10701070void p( int x = 1, int y = 2, int z = 3 ) {...}
    1071 \end{cfa}
     1071\end{lstlisting}
    10721072the allowable positional calls are:
    1073 \begin{cfa}
     1073\begin{lstlisting}
    10741074p();                                                    §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
    10751075p( 4 );                                                 §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
    … …  
    10841084p(  ,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
    10851085p(  ,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
    1086 \end{cfa}
     1086\end{lstlisting}
    10871087Here the missing arguments are inserted from the default values in the parameter list.
    10881088The compiler rewrites missing default values into explicit positional arguments.
    … …  
    11061106
    11071107Default values may only appear in a prototype versus definition context:
    1108 \begin{cfa}
     1108\begin{lstlisting}
    11091109void p( int x, int y = 2, int z = 3 );          §\C{// prototype: allowed}§
    11101110void p( int, int = 2, int = 3 );                        §\C{// prototype: allowed}§
    11111111void p( int x, int y = 2, int z = 3 ) {}        §\C{// definition: not allowed}§
    1112 \end{cfa}
     1112\end{lstlisting}
    11131113The reason for this restriction is to allow separate compilation.
    11141114Multiple prototypes with different default values is an error.
    … …  
    11171117Ellipse (``...'') arguments present problems when used with default arguments.
    11181118The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities:
    1119 \begin{cfa}
     1119\begin{lstlisting}
    11201120p( /* positional */, ... , /* named */ );
    11211121p( /* positional */, /* named */, ... );
    1122 \end{cfa}
     1122\end{lstlisting}
    11231123While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:
    1124 \begin{cfa}
     1124\begin{lstlisting}
    11251125p( int x, int y, int z, ... );
    11261126p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
    11271127p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
    1128 \end{cfa}
     1128\end{lstlisting}
    11291129In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin.
    11301130Hence, this approach seems significantly more difficult, and hence, confusing and error prone.
    … …  
    11321132
    11331133The problem is exacerbated with default arguments, \eg:
    1134 \begin{cfa}
     1134\begin{lstlisting}
    11351135void p( int x, int y = 2, int z = 3... );
    11361136p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, ... , /* named */ );}§
    11371137p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, ... );}§
    1138 \end{cfa}
     1138\end{lstlisting}
    11391139The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
    11401140therefore, argument 5 subsequently conflicts with the named argument z : 3.
    … …  
    11481148\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    11491149\multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}}   & \multicolumn{1}{c}{\textbf{overloading}}      \\
    1150 \begin{cfa}
     1150\begin{lstlisting}
    11511151void p( int x, int y = 2, int z = 3 ) {...}
    11521152
    11531153
    1154 \end{cfa}
     1154\end{lstlisting}
    11551155&
    1156 \begin{cfa}
     1156\begin{lstlisting}
    11571157void p( int x, int y, int z ) {...}
    11581158void p( int x ) { p( x, 2, 3 ); }
    11591159void p( int x, int y ) { p( x, y, 3 ); }
    1160 \end{cfa}
     1160\end{lstlisting}
    11611161\end{tabular}
    11621162\end{quote2}
    … …  
    11641164In general, overloading should only be used over default arguments if the body of the routine is significantly different.
    11651165Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
    1166 \begin{cfa}
     1166\begin{lstlisting}
    11671167p( 1, /* default */, 5 );               §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
    1168 \end{cfa}
     1168\end{lstlisting}
    11691169
    11701170Given the \CFA restrictions above, both named and default arguments are backwards compatible.
    … …  
    11861186\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
    11871187\hline
    1188 \begin{cfa}
     1188\begin{lstlisting}
    11891189struct S {
    11901190        enum C { R, G, B };
    … …  
    12031203        union U u;
    12041204}
    1205 \end{cfa}
     1205\end{lstlisting}
    12061206&
    1207 \begin{cfa}
     1207\begin{lstlisting}
    12081208enum C { R, G, B };
    12091209union U { int i, j; };
    … …  
    12221222
    12231223
    1224 \end{cfa}
     1224\end{lstlisting}
    12251225&
    1226 \begin{cfa}
     1226\begin{lstlisting}
    12271227struct S {
    12281228        enum C { R, G, B };
    … …  
    12411241        union ®S.T.®U u;
    12421242}
    1243 \end{cfa}
     1243\end{lstlisting}
    12441244\end{tabular}
    12451245\caption{Type Nesting / Qualification}
    … …  
    12541254While \CFA does not provide object programming by putting routines into structures, it does rely heavily on locally nested routines to redefine operations at or close to a call site.
    12551255For example, the C quick-sort is wrapped into the following polymorphic \CFA routine:
    1256 \begin{cfa}
     1256\begin{lstlisting}
    12571257forall( otype T | { int ?<?( T, T ); } )
    12581258void qsort( const T * arr, size_t dimension );
    1259 \end{cfa}
     1259\end{lstlisting}
    12601260which can be used to sort in ascending and descending order by locally redefining the less-than operator into greater-than.
    1261 \begin{cfa}
     1261\begin{lstlisting}
    12621262const unsigned int size = 5;
    12631263int ia[size];
    … …  
    12681268        qsort( ia, size );      §\C{// sort descending order by local redefinition}§
    12691269}
    1270 \end{cfa}
     1270\end{lstlisting}
    12711271
    12721272Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks;
    12731273the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program.
    12741274The following program in undefined in \CFA (and Indexc{gcc})
    1275 \begin{cfa}
     1275\begin{lstlisting}
    12761276[* [int]( int )] foo() {                §\C{// int (*foo())( int )}§
    12771277        int ®i® = 7;
    … …  
    12861286    sout | fp( 3 ) | endl;
    12871287}
    1288 \end{cfa}
     1288\end{lstlisting}
    12891289because
    12901290
    … …  
    12981298A list of such elements is called a \newterm{lexical list}.
    12991299The general syntax of a lexical list is:
    1300 \begin{cfa}
     1300\begin{lstlisting}
    13011301[ §\emph{exprlist}§ ]
    1302 \end{cfa}
     1302\end{lstlisting}
    13031303where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
    13041304The brackets, ©[]©, allow differentiating between lexical lists and expressions containing the C comma operator.
    13051305The following are examples of lexical lists:
    1306 \begin{cfa}
     1306\begin{lstlisting}
    13071307[ x, y, z ]
    13081308[ 2 ]
    13091309[ v+w, x*y, 3.14159, f() ]
    1310 \end{cfa}
     1310\end{lstlisting}
    13111311Tuples are permitted to contain sub-tuples (i.e., nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
    13121312Note, a tuple is not a record (structure);
    … …  
    13181318Tuple variables and types can be used anywhere lists of conventional variables and types can be used.
    13191319The general syntax of a tuple type is:
    1320 \begin{cfa}
     1320\begin{lstlisting}
    13211321[ §\emph{typelist}§ ]
    1322 \end{cfa}
     1322\end{lstlisting}
    13231323where ©$\emph{typelist}$© is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
    13241324Examples of tuple types include:
    1325 \begin{cfa}
     1325\begin{lstlisting}
    13261326[ unsigned int, char ]
    13271327[ double, double, double ]
    13281328[ * int, int * ]                §\C{// mix of CFA and ANSI}§
    13291329[ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
    1330 \end{cfa}
     1330\end{lstlisting}
    13311331Like tuples, tuple types may be nested, such as ©[ [ int, int ], int ]©, which is a 2-element tuple type whose first element is itself a tuple type.
    13321332
    13331333Examples of declarations using tuple types are:
    1334 \begin{cfa}
     1334\begin{lstlisting}
    13351335[ int, int ] x;                 §\C{// 2 element tuple, each element of type int}§
    13361336* [ char, char ] y;             §\C{// pointer to a 2 element tuple}§
    13371337[ [ int, int ] ] z ([ int, int ]);
    1338 \end{cfa}
     1338\end{lstlisting}
    13391339The last example declares an external routine that expects a 2 element tuple as an input parameter and returns a 2 element tuple as its result.
    13401340
    … …  
    13421342In unambiguous situations, the tuple brackets may be omitted, \eg a tuple that appears as an argument may have its
    13431343square brackets omitted for convenience; therefore, the following routine invocations are equivalent:
    1344 \begin{cfa}
     1344\begin{lstlisting}
    13451345f( [ 1, x+2, fred() ] );
    13461346f( 1, x+2, fred() );
    1347 \end{cfa}
     1347\end{lstlisting}
    13481348Also, a tuple or a tuple variable may be used to supply all or part of an argument list for a routine expecting multiple input parameters or for a routine expecting a tuple as an input parameter.
    13491349For example, the following are all legal:
    1350 \begin{cfa}
     1350\begin{lstlisting}
    13511351[ int, int ] w1;
    13521352[ int, int, int ] w2;
    … …  
    13611361g( 1, w1 );
    13621362g( w2 );
    1363 \end{cfa}
     1363\end{lstlisting}
    13641364Note, in all cases 3 arguments are supplied even though the syntax may appear to supply less than 3. As mentioned, a
    13651365tuple does not have structure like a record; a tuple is simply converted into a list of components.
    … …  
    13711371A tuple can contain a C comma expression, provided the expression containing the comma operator is enclosed in parentheses.
    13721372For instance, the following tuples are equivalent:
    1373 \begin{cfa}
     1373\begin{lstlisting}
    13741374[ 1, 3, 5 ]
    13751375[ 1, (2, 3), 5 ]
    1376 \end{cfa}
     1376\end{lstlisting}
    13771377The second element of the second tuple is the expression (2, 3), which yields the result 3.
    13781378This requirement is the same as for comma expressions in argument lists.
    … …  
    13801380Type qualifiers, i.e., const and volatile, may modify a tuple type.
    13811381The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, \eg:
    1382 \begin{cfa}
     1382\begin{lstlisting}
    13831383const volatile [ int, float, const int ] x;
    1384 \end{cfa}
     1384\end{lstlisting}
    13851385is equivalent to:
    1386 \begin{cfa}
     1386\begin{lstlisting}
    13871387[ const volatile int, const volatile float, const volatile int ] x;
    1388 \end{cfa}
     1388\end{lstlisting}
    13891389Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg:
    1390 \begin{cfa}
     1390\begin{lstlisting}
    13911391extern [ int, int ] w1;
    13921392static [ int, int, int ] w2;
    1393 \end{cfa}
     1393\end{lstlisting}
    13941394\begin{rationale}
    13951395Unfortunately, C's syntax for subscripts precluded treating them as tuples.
    … …  
    14051405In addition, the coercion of dereferencing can be performed on a tuple variable to yield its value(s), as for other variables.
    14061406A \newterm{closing coercion} takes a set of values and converts it into a tuple value, which is a contiguous set of values, as in:
    1407 \begin{cfa}
     1407\begin{lstlisting}
    14081408[ int, int, int, int ] w;
    14091409w = [ 1, 2, 3, 4 ];
    1410 \end{cfa}
     1410\end{lstlisting}
    14111411First the right-hand tuple is closed into a tuple value and then the tuple value is assigned.
    14121412
    14131413An \newterm{opening coercion} is the opposite of closing; a tuple value is converted into a tuple of values, as in:
    1414 \begin{cfa}
     1414\begin{lstlisting}
    14151415[ a, b, c, d ] = w
    1416 \end{cfa}
     1416\end{lstlisting}
    14171417©w© is implicitly opened to yield a tuple of four values, which are then assigned individually.
    14181418
    14191419A \newterm{flattening coercion} coerces a nested tuple, i.e., a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in:
    1420 \begin{cfa}
     1420\begin{lstlisting}
    14211421[ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ];
    1422 \end{cfa}
     1422\end{lstlisting}
    14231423First the right-hand tuple is flattened and then the values are assigned individually.
    14241424Flattening is also performed on tuple types.
    … …  
    14291429For example, structuring the tuple ©[ 1, 2, 3, 4 ]© into the tuple ©[ 1, [ 2, 3 ], 4 ]© or the tuple type ©[ int, int, int, int ]© into the tuple type ©[ int, [ int, int ], int ]©.
    14301430In the following example, the last assignment illustrates all the tuple coercions:
    1431 \begin{cfa}
     1431\begin{lstlisting}
    14321432[ int, int, int, int ] w = [ 1, 2, 3, 4 ];
    14331433int x = 5;
    14341434[ x, w ] = [ w, x ];            §\C{// all four tuple coercions}§
    1435 \end{cfa}
     1435\end{lstlisting}
    14361436Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
    14371437therefore, the right-hand tuple is now the tuple ©[ [ 1, 2, 3, 4 ], 5 ]©.
    … …  
    14481448\CFA permits assignment to several variables at once using mass assignment~\cite{CLU}.
    14491449Mass assignment has the following form:
    1450 \begin{cfa}
     1450\begin{lstlisting}
    14511451[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
    1452 \end{cfa}
     1452\end{lstlisting}
    14531453\index{lvalue}
    14541454The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
    … …  
    14571457
    14581458Mass assignment has parallel semantics, \eg the statement:
    1459 \begin{cfa}
     1459\begin{lstlisting}
    14601460[ x, y, z ] = 1.5;
    1461 \end{cfa}
     1461\end{lstlisting}
    14621462is equivalent to:
    1463 \begin{cfa}
     1463\begin{lstlisting}
    14641464x = 1.5; y = 1.5; z = 1.5;
    1465 \end{cfa}
     1465\end{lstlisting}
    14661466This semantics is not the same as the following in C:
    1467 \begin{cfa}
     1467\begin{lstlisting}
    14681468x = y = z = 1.5;
    1469 \end{cfa}
     1469\end{lstlisting}
    14701470as conversions between intermediate assignments may lose information.
    14711471A more complex example is:
    1472 \begin{cfa}
     1472\begin{lstlisting}
    14731473[ i, y[i], z ] = a + b;
    1474 \end{cfa}
     1474\end{lstlisting}
    14751475which is equivalent to:
    1476 \begin{cfa}
     1476\begin{lstlisting}
    14771477t = a + b;
    14781478a1 = &i; a2 = &y[i]; a3 = &z;
    14791479*a1 = t; *a2 = t; *a3 = t;
    1480 \end{cfa}
     1480\end{lstlisting}
    14811481The temporary ©t© is necessary to store the value of the expression to eliminate conversion issues.
    14821482The temporaries for the addresses are needed so that locations on the left-hand side do not change as the values are assigned.
    … …  
    14881488\CFA also supports the assignment of several values at once, known as multiple assignment~\cite{CLU,Galletly96}.
    14891489Multiple assignment has the following form:
    1490 \begin{cfa}
     1490\begin{lstlisting}
    14911491[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
    1492 \end{cfa}
     1492\end{lstlisting}
    14931493\index{lvalue}
    14941494The left-hand side is a tuple of \emph{lvalues}, and the right-hand side is a tuple of \emph{expr}s.
    14951495Each \emph{expr} appearing on the righthand side of a multiple assignment statement is assigned to the corresponding \emph{lvalues} on the left-hand side of the statement using parallel semantics for each assignment.
    14961496An example of multiple assignment is:
    1497 \begin{cfa}
     1497\begin{lstlisting}
    14981498[ x, y, z ] = [ 1, 2, 3 ];
    1499 \end{cfa}
     1499\end{lstlisting}
    15001500Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©.
    15011501 A more complex example is:
    1502 \begin{cfa}
     1502\begin{lstlisting}
    15031503[ i, y[ i ], z ] = [ 1, i, a + b ];
    1504 \end{cfa}
     1504\end{lstlisting}
    15051505Here, the values ©1©, ©i© and ©a + b© are assigned to the variables ©i©, ©y[i]© and ©z©, respectively.
    15061506 Note, the parallel semantics of
    15071507multiple assignment ensures:
    1508 \begin{cfa}
     1508\begin{lstlisting}
    15091509[ x, y ] = [ y, x ];
    1510 \end{cfa}
     1510\end{lstlisting}
    15111511correctly interchanges (swaps) the values stored in ©x© and ©y©.
    15121512The following cases are errors:
    1513 \begin{cfa}
     1513\begin{lstlisting}
    15141514[ a, b, c ] = [ 1, 2, 3, 4 ];
    15151515[ a, b, c ] = [ 1, 2 ];
    1516 \end{cfa}
     1516\end{lstlisting}
    15171517because the number of entities in the left-hand tuple is unequal with the right-hand tuple.
    15181518
    15191519As for all tuple contexts in C, side effects should not be used because C does not define an ordering for the evaluation of the elements of a tuple;
    15201520both these examples produce indeterminate results:
    1521 \begin{cfa}
     1521\begin{lstlisting}
    15221522f( x++, x++ );                          §\C{// C routine call with side effects in arguments}§
    15231523[ v1, v2 ] = [ x++, x++ ];      §\C{// side effects in righthand side of multiple assignment}§
    1524 \end{cfa}
     1524\end{lstlisting}
    15251525
    15261526
    … …  
    15291529As in C, \CFA mass and multiple assignments can be cascaded, producing cascade assignment.
    15301530Cascade assignment has the following form:
    1531 \begin{cfa}
     1531\begin{lstlisting}
    15321532§\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
    1533 \end{cfa}
     1533\end{lstlisting}
    15341534and it has the same parallel semantics as for mass and multiple assignment.
    15351535Some examples of cascade assignment are:
    1536 \begin{cfa}
     1536\begin{lstlisting}
    15371537x1 = y1 = x2 = y2 = 0;
    15381538[ x1, y1 ] = [ x2, y2 ] = [ x3, y3 ];
    15391539[ x1, y1 ] = [ x2, y2 ] = 0;
    15401540[ x1, y1 ] = z = 0;
    1541 \end{cfa}
     1541\end{lstlisting}
    15421542As in C, the rightmost assignment is performed first, i.e., assignment parses right to left.
    15431543
    … …  
    15461546
    15471547C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg:
    1548 \begin{cfa}
     1548\begin{lstlisting}
    15491549struct {
    15501550        int f1;                                 §\C{// named field}§
    … …  
    15551555        int (*)(int);                   §\C{// disallowed, unnamed field}§
    15561556};
    1557 \end{cfa}
     1557\end{lstlisting}
    15581558This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
    15591559As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
    15601560A list of unnamed fields is also supported, \eg:
    1561 \begin{cfa}
     1561\begin{lstlisting}
    15621562struct {
    15631563        int , , ;                               §\C{// 3 unnamed fields}§
    15641564}
    1565 \end{cfa}
     1565\end{lstlisting}
    15661566
    15671567
    … …  
    15701570Tuples may be used to select multiple fields of a record by field name.
    15711571Its general form is:
    1572 \begin{cfa}
     1572\begin{lstlisting}
    15731573§\emph{expr}§ . [ §\emph{fieldlist}§ ]
    15741574§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
    1575 \end{cfa}
     1575\end{lstlisting}
    15761576\emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©.
    15771577Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
    15781578A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
    15791579the following:
    1580 \begin{cfa}
     1580\begin{lstlisting}
    15811581struct s {
    15821582        int f1, f2;
    … …  
    15861586v.[ f3, f1, f2 ] = ['x', 11, 17 ];      §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§
    15871587f( v.[ f3, f1, f2 ] );                          §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§
    1588 \end{cfa}
     1588\end{lstlisting}
    15891589Note, the fields appearing in a record-field tuple may be specified in any order;
    15901590also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple.
    15911591
    15921592If a field of a ©struct© is itself another ©struct©, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
    1593 \begin{cfa}
     1593\begin{lstlisting}
    15941594struct inner {
    15951595        int f2, f3;
    … …  
    16021602
    16031603o.[ f1, i.[ f2, f3 ], f4 ] = [ 11, 12, 13, 3.14159 ];
    1604 \end{cfa}
     1604\end{lstlisting}
    16051605
    16061606
    … …  
    16171617\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    16181618\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    1619 \begin{cfa}
     1619\begin{lstlisting}
    16201620®L1:® do {
    16211621        ®L2:® while ( ... ) {
    … …  
    16271627        } // while
    16281628} while ( ... );
    1629 \end{cfa}
     1629\end{lstlisting}
    16301630&
    1631 \begin{cfa}
     1631\begin{lstlisting}
    16321632do {
    16331633        while ( ... ) {
    … …  
    16391639        L2: ; }
    16401640L1: ; } while ( ... );
    1641 \end{cfa}
     1641\end{lstlisting}
    16421642\end{tabular}
    16431643\end{quote2}
    … …  
    16481648\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    16491649\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    1650 \begin{cfa}
     1650\begin{lstlisting}
    16511651®L1:® {
    16521652        ... §declarations§ ...
    … …  
    16651665        } // switch
    16661666} // compound
    1667 \end{cfa}
     1667\end{lstlisting}
    16681668&
    1669 \begin{cfa}
     1669\begin{lstlisting}
    16701670{
    16711671        ... §declarations§ ...
    … …  
    16841684        } L2: ;
    16851685} L1: ;
    1686 \end{cfa}
     1686\end{lstlisting}
    16871687\end{tabular}
    16881688\end{quote2}
    … …  
    17141714\emph{falls through} to the next ©case© clause in the ©switch© statement;
    17151715to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
    1716 \begin{cfa}
     1716\begin{lstlisting}
    17171717switch ( i ) {
    17181718  case 1:
    … …  
    17231723        break;  // exit switch statement
    17241724}
    1725 \end{cfa}
     1725\end{lstlisting}
    17261726The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
    17271727\begin{quote2}
    17281728\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    1729 \begin{cfa}
     1729\begin{lstlisting}
    17301730switch ( argc ) {
    17311731  case 3:
    … …  
    17381738        // usage message
    17391739}
    1740 \end{cfa}
     1740\end{lstlisting}
    17411741&
    1742 \begin{cfa}
     1742\begin{lstlisting}
    17431743
    17441744if ( argc == 3 ) {
    … …  
    17511751        // usage message
    17521752}
    1753 \end{cfa}
     1753\end{lstlisting}
    17541754\end{tabular}
    17551755\end{quote2}
    … …  
    17571757This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
    17581758C also uses fall-through to handle multiple case-values resulting in the same action:
    1759 \begin{cfa}
     1759\begin{lstlisting}
    17601760switch ( i ) {
    17611761  case 1: case 3: case 5:       // odd values
    … …  
    17661766        break;
    17671767}
    1768 \end{cfa}
     1768\end{lstlisting}
    17691769However, this situation is handled in other languages without fall-through by allowing a list of case values.
    17701770While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
    … …  
    17731773\item
    17741774It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
    1775 \begin{cfa}
     1775\begin{lstlisting}
    17761776switch ( i ) {
    17771777  case 0:
    … …  
    17881788        } // while
    17891789} // switch
    1790 \end{cfa}
     1790\end{lstlisting}
    17911791The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
    17921792The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
    … …  
    17951795There are virtually no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
    17961796Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
    1797 \begin{cfa}
     1797\begin{lstlisting}
    17981798register int n = (count + 7) / 8;
    17991799switch ( count % 8 ) {
    … …  
    18081808                } while ( --n > 0 );
    18091809}
    1810 \end{cfa}
     1810\end{lstlisting}
    18111811which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
    18121812While efficient, this sort of special purpose usage is questionable:
    … …  
    18241824\item
    18251825It is possible to place unreachable code at the start of a ©switch© statement, as in:
    1826 \begin{cfa}
     1826\begin{lstlisting}
    18271827switch ( x ) {
    18281828        ®int y = 1;®                            §\C{// unreachable initialization}§
    … …  
    18351835        ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
    18361836}
    1837 \end{cfa}
     1837\end{lstlisting}
    18381838While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
    18391839Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
    … …  
    18581858Eliminating default fall-through has the greatest potential for affecting existing code.
    18591859However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, \eg:
    1860 \begin{cfa}
     1860 \begin{lstlisting}
    18611861case 1:  case 2:  case 3: ...
    1862 \end{cfa}
     1862\end{lstlisting}
    18631863still works.
    18641864Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
    18651865Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, e.g.:
    1866 \begin{cfa}
     1866\begin{lstlisting}
    18671867®choose® ( i ) {
    18681868  case 1:  case 2:  case 3:
    … …  
    18781878        j = 3;
    18791879}
    1880 \end{cfa}
     1880\end{lstlisting}
    18811881Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
    18821882the implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
    … …  
    18931893Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
    18941894Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
    1895 \begin{cfa}
     1895\begin{lstlisting}
    18961896switch ( x ) {
    18971897        ®int i = 0;®                            §\C{// allowed only at start}§
    … …  
    19061906  ...
    19071907}
    1908 \end{cfa}
     1908\end{lstlisting}
    19091909\end{enumerate}
    19101910
    … …  
    19191919\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    19201920\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    1921 \begin{cfa}
     1921\begin{lstlisting}
    19221922switch ( i ) {
    19231923  case ®1, 3, 5®:
    … …  
    19261926        ...
    19271927}
    1928 \end{cfa}
     1928\end{lstlisting}
    19291929&
    1930 \begin{cfa}
     1930\begin{lstlisting}
    19311931switch ( i ) {
    19321932  case 1: case 3 : case 5:
    … …  
    19351935        ...
    19361936}
    1937 \end{cfa}
     1937\end{lstlisting}
    19381938&
    1939 \begin{cfa}
     1939\begin{lstlisting}
    19401940
    19411941// odd values
    … …  
    19441944
    19451945
    1946 \end{cfa}
     1946\end{lstlisting}
    19471947\end{tabular}
    19481948\end{quote2}
    … …  
    19521952\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    19531953\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}}     \\
    1954 \begin{cfa}
     1954\begin{lstlisting}
    19551955switch ( i ) {
    19561956  case ®1~5:®
    … …  
    19591959        ...
    19601960}
    1961 \end{cfa}
     1961\end{lstlisting}
    19621962&
    1963 \begin{cfa}
     1963\begin{lstlisting}
    19641964switch ( i )
    19651965  case ®1 ... 5®:
    … …  
    19681968        ...
    19691969}
    1970 \end{cfa}
     1970\end{lstlisting}
    19711971&
    1972 \begin{cfa}
     1972\begin{lstlisting}
    19731973
    19741974// 1, 2, 3, 4, 5
    … …  
    19771977
    19781978
    1979 \end{cfa}
     1979\end{lstlisting}
    19801980\end{tabular}
    19811981\end{quote2}
    19821982Lists of subranges are also allowed.
    1983 \begin{cfa}
     1983\begin{lstlisting}
    19841984case ®1~5, 12~21, 35~42®:
    1985 \end{cfa}
     1985\end{lstlisting}
    19861986
    19871987
    … …  
    19891989
    19901990Exception handling provides two mechanism: change of control flow from a raise to a handler, and communication from the raise to the handler.
    1991 \begin{cfa}
     1991\begin{lstlisting}
    19921992exception void h( int i );
    19931993exception int h( int i, double d );
    … …  
    20062006} finally {
    20072007}
    2008 \end{cfa}
     2008\end{lstlisting}
    20092009So the type raised would be the mangled name of the exception prototype and that name would be matched at the handler clauses by comparing the strings.
    20102010The arguments for the call would have to be packed in a message and unpacked at handler clause and then a call made to the handler.
    … …  
    20172017\CFA allows users to define new types using the keyword type.
    20182018
    2019 \begin{cfa}
     2019\begin{lstlisting}
    20202020// SensorValue is a distinct type and represented as an int
    20212021type SensorValue = int;
    2022 \end{cfa}
     2022\end{lstlisting}
    20232023
    20242024A type definition is different from a typedef in C because a typedef just creates an alias for a type,  while Do.s type definition creates a distinct type.
    … …  
    20262026For example:
    20272027
    2028 \begin{cfa}
     2028\begin{lstlisting}
    20292029type SensorValue = int;
    20302030void printValue(int v) {...}
    … …  
    20392039
    20402040process(s); // implicit conversion to int
    2041 \end{cfa}
     2041\end{lstlisting}
    20422042
    20432043If SensorValue was defined with a typedef, then these two print functions would not have unique signatures.
    … …  
    20472047Users may override this and define a function that must be called to convert from one type to another.
    20482048
    2049 \begin{cfa}
     2049\begin{lstlisting}
    20502050type SensorValue = int;
    20512051// ()? is the overloaded conversion operator identifier
    … …  
    20582058SensorValue s = ...;
    20592059process(s); // implicit call to conversion operator
    2060 \end{cfa}
     2060\end{lstlisting}
    20612061
    20622062In many cases, it is not desired for the compiler to do this implicit conversion.
    … …  
    20642064Any places where the conversion is needed but not explicit (with a cast), will result in a compile-time error.
    20652065
    2066 \begin{cfa}
     2066\begin{lstlisting}
    20672067type SensorValue = int;
    20682068
    … …  
    20772077process(s); // implicit cast to int: compile-time error
    20782078process((int) s); // explicit cast to int: calls conversion func
    2079 \end{cfa}
     2079\end{lstlisting}
    20802080
    20812081The conversion may not require any code, but still need to be explicit; in that case, the syntax can be simplified to:
    2082 \begin{cfa}
     2082\begin{lstlisting}
    20832083type SensorValue = int;
    20842084explicit SensorValue ()?(int);
    … …  
    20882088process(s); // compile-time error
    20892089process((int) s); // type is converted, no function is called
    2090 \end{cfa}
     2090\end{lstlisting}
    20912091
    20922092
    … …  
    20962096A structure is defined with the same syntax as in C.
    20972097When referring to a structure in \CFA, users may omit the struct keyword.
    2098 \begin{cfa}
     2098\begin{lstlisting}
    20992099struct Point {
    21002100        double x;
    … …  
    21032103
    21042104Point p = {0.0, 0.0};
    2105 \end{cfa}
     2105\end{lstlisting}
    21062106
    21072107\CFA does not support inheritance among types, but instead uses composition to enable reuse of structure fields.
    … …  
    21102110Embedding types is achieved using anonymous members.
    21112111For example, using Point from above:
    2112 \begin{cfa}
     2112\begin{lstlisting}
    21132113void foo(Point p);
    21142114
    … …  
    21222122        cp.color = 0x33aaff; // color is accessed normally
    21232123        foo(cp); // cp can be used directly as a Point
    2124 \end{cfa}
     2124\end{lstlisting}
    21252125
    21262126
    … …  
    21322132
    21332133\begin{figure}
    2134 \begin{cfa}
     2134\begin{lstlisting}
    21352135struct Widget {
    21362136        int id;
    … …  
    21742174^bar; // explicit call to destructor
    21752175^?(bar); // explicit call to destructor
    2176 \end{cfa}
     2176\end{lstlisting}
    21772177\caption{Constructors and Destructors}
    21782178\end{figure}
    … …  
    22112211If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous.
    22122212For details about type inference and overload resolution, please see the \CFA Language Specification.
    2213 \begin{cfa}
     2213\begin{lstlisting}
    22142214int foo(int a, int b) {
    22152215        float sum = 0.0;
    … …  
    22242224        ...
    22252225}
    2226 \end{cfa}
     2226\end{lstlisting}
    22272227
    22282228
    … …  
    22452245For example, to define the constants for a complex type, the programmer would define the following:
    22462246
    2247 \begin{cfa}
     2247\begin{lstlisting}
    22482248struct Complex {
    22492249        double real;
    … …  
    22632263...
    22642264}
    2265 \end{cfa}
     2265\end{lstlisting}
    22662266
    22672267
    … …  
    22712271Allowing overloading of variable names enables programmers to use the same name across multiple types, simplifying naming conventions and is compatible with the other overloading that is allowed.
    22722272For example, a developer may want to do the following:
    2273 \begin{cfa}
     2273\begin{lstlisting}
    22742274int pi = 3;
    22752275float pi = 3.14;
    22762276char pi = .p.;
    2277 \end{cfa}
     2277\end{lstlisting}
    22782278
    22792279
    … …  
    22832283
    22842284The examples below give some basic intuition about how the resolution works.
    2285 \begin{cfa}
     2285\begin{lstlisting}
    22862286// Choose the one with less conversions
    22872287int doSomething(int value) {...} // option 1
    … …  
    23062306
    23072307f = bar(d, e); // chooses option 5
    2308 \end{cfa}
     2308\end{lstlisting}
    23092309
    23102310
    … …  
    23762376These operators are called using the normal C syntax.
    23772377
    2378 \begin{cfa}
     2378\begin{lstlisting}
    23792379type Complex = struct { // define a Complex type
    23802380        double real;
    … …  
    24062406c = a + b;
    24072407print(.sum = . + c);
    2408 \end{cfa}
     2408\end{lstlisting}
    24092409
    24102410
    … …  
    24152415\begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
    24162416\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{Indexc{gcc}} \\
    2417 \begin{cfa}
     2417\begin{lstlisting}
    24182418
    24192419auto j = 3.0 * 4;
    24202420int i;
    24212421auto k = i;
    2422 \end{cfa}
     2422\end{lstlisting}
    24232423&
    2424 \begin{cfa}
     2424\begin{lstlisting}
    24252425#define expr 3.0 * i
    24262426typeof(expr) j = expr;
    24272427int i;
    24282428typeof(i) k = i;
    2429 \end{cfa}
     2429\end{lstlisting}
    24302430&
    2431 \begin{cfa}
     2431\begin{lstlisting}
    24322432
    24332433// use type of initialization expression
    24342434
    24352435// use type of primary variable
    2436 \end{cfa}
     2436\end{lstlisting}
    24372437\end{tabular}
    24382438\end{quote2}
    … …  
    24512451Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed.
    24522452For example, given
    2453 \begin{cfa}
     2453\begin{lstlisting}
    24542454auto j = ®...®
    2455 \end{cfa}
     2455\end{lstlisting}
    24562456and the need to write a routine to compute using ©j©
    2457 \begin{cfa}
     2457\begin{lstlisting}
    24582458void rtn( ®...® parm );
    24592459rtn( j );
    2460 \end{cfa}
     2460\end{lstlisting}
    24612461A programmer must work backwards to determine the type of ©j©'s initialization expression, reconstructing the possibly long generic type-name.
    24622462In this situation, having the type name or a short alias is very useful.
    … …  
    24882488A simple example of using Do.s parametric polymorphism to create a generic swap function would look like this:
    24892489
    2490 \begin{cfa}
     2490\begin{lstlisting}
    24912491generic(type T)
    24922492void swap(T &a, T &b) {
    … …  
    25012501Point p1, p2;
    25022502swap(p1, p2);
    2503 \end{cfa}
     2503\end{lstlisting}
    25042504
    25052505Here, instead of specifying types for the parameters a and b, the function has a generic type parameter, type T.
    … …  
    25112511Some generic functions only work (or make sense) for any type that satisfies a given property.
    25122512For example, here is a function to pick the minimum of two values of some type.
    2513 \begin{cfa}
     2513\begin{lstlisting}
    25142514generic (type T | bool ?<?(T, T) )
    25152515
    … …  
    25172517        return a < b ? a : b;
    25182518}
    2519 \end{cfa}
     2519\end{lstlisting}
    25202520
    25212521It only makes sense to call min with values of a type that has an ordering: a way to decide whether one value is less than another.
    … …  
    25262526
    25272527Bounds can also involve multiple types, and multiple requirements, as shown below:
    2528 \begin{cfa}
     2528\begin{lstlisting}
    25292529generic (type T, type U | { T foo(T, U); U bar(U); })
    25302530
    … …  
    25322532        return foo(t, bar(u));
    25332533}
    2534 \end{cfa}
     2534\end{lstlisting}
    25352535
    25362536
    … …  
    25462546This avoids repetition when a bound is used in many functions.
    25472547Second, interfaces explicitly document the existence of a commonly used set of functionality, making programs easier to understand.
    2548 \begin{cfa}
     2548\begin{lstlisting}
    25492549generic (type T)
    25502550interface Orderable {
    … …  
    25562556        return a < b ? a : b;
    25572557}
    2558 \end{cfa}
     2558\end{lstlisting}
    25592559
    25602560This definition of the interface Orderable makes the generic function min easier to read and understand.
    … …  
    25622562Interfaces can also build on top of other interfaces.
    25632563For example:
    2564 \begin{cfa}
     2564\begin{lstlisting}
    25652565generic (type T | Orderable(T)
    25662566interface FooBarable {
    … …  
    25682568        int Bar(T, T);
    25692569};
    2570 \end{cfa}
     2570\end{lstlisting}
    25712571
    25722572The FooBarable interface specifies all of the bounds of the Orderable interface, plus the additional bounds specified in its definition.
    … …  
    25792579Type synonyms can be defined generically using the typedef keyword together with a generic type annotation.
    25802580These can be used to abbreviate complicated type expressions, especially in generic code.
    2581 \begin{cfa}
     2581\begin{lstlisting}
    25822582// typedef the generic function pointers for later use
    25832583
    … …  
    25942594        if (p(array[i])) f(NULL, array[i]);
    25952595}
    2596 \end{cfa}
     2596\end{lstlisting}
    25972597
    25982598
    … …  
    26082608The syntax for defining a generic type looks very similar to that of a generic function.
    26092609Generic types support bounds and interfaces, using the same syntax as generic functions.
    2610 \begin{cfa}
     2610\begin{lstlisting}
    26112611generic (type T)
    26122612struct LinkedListElem {
    … …  
    26322632        return false;
    26332633}
    2634 \end{cfa}
     2634\end{lstlisting}
    26352635
    26362636
    … …  
    26552655An exception is thrown using a throw statement, which accepts one argument.
    26562656
    2657 \begin{cfa}
     2657\begin{lstlisting}
    26582658        ...
    26592659
    … …  
    26612661
    26622662        ...
    2663 \end{cfa}
     2663\end{lstlisting}
    26642664
    26652665An exception can be caught using a catch statement, which specifies the type of the exception it can catch.
    … …  
    26672667A guarded block is specified using the try keyword, followed by a block of code inside of curly braces.
    26682668
    2669 \begin{cfa}
     2669\begin{lstlisting}
    26702670        ...
    26712671
    … …  
    26762676                printf(.caught an exception: %d\n., e);
    26772677        }
    2678 \end{cfa}
     2678\end{lstlisting}
    26792679
    26802680
    … …  
    26912691Instead, it infers the type based on the return value, and then allocates space for the inferred type.
    26922692
    2693 \begin{cfa}
     2693\begin{lstlisting}
    26942694float *f = malloc(); // allocates the size of a float
    26952695
    … …  
    26992699
    27002700struct S *s = malloc(); // allocates the size of a struct S
    2701 \end{cfa}
     2701\end{lstlisting}
    27022702
    27032703In addition to the improved malloc, \CFA also provides a technique for combining allocation and initialization into one step, using the new function.
    27042704For all constructors defined for a given type (see Operator Overloading), a corresponding call to new can be used to allocate and construct that type.
    27052705
    2706 \begin{cfa}
     2706\begin{lstlisting}
    27072707type Complex = struct {
    27082708        float real;
    … …  
    27372737}
    27382738
    2739 \end{cfa}
     2739\end{lstlisting}
    27402740
    27412741
    … …  
    27642764The number 0 and 1 are treated specially in \CFA, and can be redefined as variables.
    27652765One syntactic anomaly is when a field in an structure is names 0 or 1:
    2766 \begin{cfa}
     2766\begin{lstlisting}
    27672767struct S {
    27682768        int 0, 1;
    27692769} s;
    2770 \end{cfa}
     2770\end{lstlisting}
    27712771The problem occurs in accessing these fields using the selection operation ``©.©'':
    2772 \begin{cfa}
     2772\begin{lstlisting}
    27732773s.0 = 0;        // ambiguity with floating constant .0
    27742774s.1 = 1;        // ambiguity with floating constant .1
    2775 \end{cfa}
     2775\end{lstlisting}
    27762776To make this work, a space is required after the field selection:
    2777 \begin{cfa}
     2777\begin{lstlisting}
    27782778®s.§\textvisiblespace§0® = 0;
    27792779®s.§\textvisiblespace§1® = 1;
    2780 \end{cfa}
     2780\end{lstlisting}
    27812781While this syntax is awkward, it is unlikely many programmers will name fields of a structure 0 or 1.
    27822782Like the \Index*[C++]{\CC} lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
    … …  
    27862786Even with this special hack, there are 5 general cases that cannot be handled.
    27872787The first case is for the function-call identifier ©?()©:
    2788 \begin{cfa}
     2788\begin{lstlisting}
    27892789int *§\textvisiblespace§?()();  // declaration: space required after '*'
    27902790*§\textvisiblespace§?()();              // expression: space required after '*'
    2791 \end{cfa}
     2791\end{lstlisting}
    27922792Without the space, the string ©*?()© is ambiguous without N character look ahead;
    27932793it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
    27942794
    27952795The 4 remaining cases occur in expressions:
    2796 \begin{cfa}
     2796\begin{lstlisting}
    27972797i++§\textvisiblespace§?i:0;             // space required before '?'
    27982798i--§\textvisiblespace§?i:0;             // space required before '?'
    27992799i§\textvisiblespace§?++i:0;             // space required after '?'
    28002800i§\textvisiblespace§?--i:0;             // space required after '?'
    2801 \end{cfa}
     2801\end{lstlisting}
    28022802In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
    28032803it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
    … …  
    28352835Users of a monitor interact with it just like any structure, but the compiler handles code as needed to ensure mutual exclusion.
    28362836An example of the definition of a monitor is shown here:
    2837 \begin{cfa}
     2837\begin{lstlisting}
    28382838type Account = monitor {
    28392839        const unsigned long number; // account number
    28402840        float balance; // account balance
    28412841};
    2842 \end{cfa}
     2842\end{lstlisting}
    28432843
    28442844Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor;
    … …  
    28502850If multiple mutex parameters are specified, they will be locked in parameter order (\ie first parameter is locked first) and unlocked in the
    28512851reverse order.
    2852 \begin{cfa}
     2852\begin{lstlisting}
    28532853// This function accesses a constant field, it does not require
    28542854// mutual exclusion
    … …  
    28652865        return a.balance;
    28662866}
    2867 \end{cfa}
     2867\end{lstlisting}
    28682868
    28692869Often, one function using a monitor will call another function using that same monitor.
    … …  
    28732873An example of this situation is shown below:
    28742874
    2875 \begin{cfa}
     2875\begin{lstlisting}
    28762876// deleting a job from a worker requires mutual exclusion
    28772877
    … …  
    28872887        ...
    28882888}
    2889 \end{cfa}
     2889\end{lstlisting}
    28902890
    28912891
    … …  
    28952895A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
    28962896Similar to a monitor, a task is defined like a structure:
    2897 \begin{cfa}
     2897\begin{lstlisting}
    28982898type Adder = task {
    28992899        int *row;
    … …  
    29012901        int &subtotal;
    29022902}
    2903 \end{cfa}
     2903\end{lstlisting}
    29042904
    29052905A task may define a constructor, which will be called upon allocation and run on the caller.s thread.
    … …  
    29092909Below are example functions for the above Adder task, and its usage to sum up a matrix on multiple threads.
    29102910(Note that this example is designed to display the syntax and functionality, not the best method to solve this problem)
    2911 \begin{cfa}
     2911\begin{lstlisting}
    29122912void ?{}(Adder &a, int r[], int s, int &st) { // constructor
    29132913        a.row = r;
    … …  
    29462946        printf(.total is %d\n., total);
    29472947}
    2948 \end{cfa}
     2948\end{lstlisting}
    29492949
    29502950
    … …  
    29592959Similarly, when a task tries to push something onto the list, but it is full, it will yield until another task frees some space with the pop function.
    29602960
    2961 \begin{cfa}
     2961\begin{lstlisting}
    29622962// type T is used as a generic type for all definitions inside
    29632963// the curly brackets
    … …  
    29842984        }
    29852985}
    2986 \end{cfa}
     2986\end{lstlisting}
    29872987
    29882988A task can also yield indefinitely by calling yield with no arguments.
    … …  
    29912991The code below shows a simple ping-pong example, where two tasks yield back and forth to each other using these methods.
    29922992
    2993 \begin{cfa}
     2993\begin{lstlisting}
    29942994type Ping = task {
    29952995        Pong *partner;
    … …  
    30293029        Ping{pong}; // initialize and start ping
    30303030}
    3031 \end{cfa}
     3031\end{lstlisting}
    30323032
    30333033The same functionality can be accomplished by providing functions to be called by the partner task.
    3034 \begin{cfa}
     3034\begin{lstlisting}
    30353035type Pingpong = task {
    30363036        String msg;
    … …  
    30603060        go(ping);
    30613061}
    3062 \end{cfa}
     3062\end{lstlisting}
    30633063
    30643064
    … …  
    30923092Within a module, all of the module's global definitions are visible throughout the module.
    30933093For example, the following code compiles, even though ©isOdd© was not declared before being called:
    3094 \begin{cfa}
     3094\begin{lstlisting}
    30953095bool isEven(unsigned int x) {
    30963096        if (x == 0) return true;
    … …  
    31023102        else return !isEven(x - 2);
    31033103}
    3104 \end{cfa}
     3104\end{lstlisting}
    31053105
    31063106Header files in C are used to expose the declarations from a library, so that they can be used externally.
    … …  
    31373137
    31383138The following code is a simple module declaration example.
    3139 \begin{cfa}
     3139\begin{lstlisting}
    31403140module M;
    31413141
    … …  
    31503150
    31513151double bCounter;
    3152 \end{cfa}
     3152\end{lstlisting}
    31533153
    31543154export module moduleName; can be use to re-export all the visible (exported) names in moduleName from the current module.
    … …  
    31713171The following code snippets show the two situations.
    31723172
    3173 \begin{cfa}
     3173\begin{lstlisting}
    31743174module util/counter;
    31753175export int f(int i) { return i+1; }
    … …  
    31853185        return ct.f(200); // f() from the package counter
    31863186}
    3187 \end{cfa}
     3187\end{lstlisting}
    31883188
    31893189
    31903190Additionally, using the .as. syntax, a user can force the compiler to add the imported names into the current namespace using .as ..With these module rules, the following module definitions and imports can be achieved without any problem.
    31913191
    3192 \begin{cfa}
     3192\begin{lstlisting}
    31933193module M1;
    31943194export int f(int i) { return i+1;} // visible outside
    … …  
    32083208        return f(3) + g(4); //f() from M1 and g() from M2;
    32093209}
    3210 \end{cfa}
     3210\end{lstlisting}
    32113211
    32123212
    … …  
    32253225If an aggregated module is imported, all the included modules in the aggregation are imported.
    32263226
    3227 \begin{cfa}
     3227\begin{lstlisting}
    32283228module std/sequence;
    32293229
    … …  
    32373237        module std/stack;
    32383238};
    3239 \end{cfa}
     3239\end{lstlisting}
    32403240
    32413241After importing the aggregated module, each individual name is still contained in the original name space.
    … …  
    33413341
    33423342Here is an example of a package, util.
    3343 \begin{cfa}
     3343\begin{lstlisting}
    33443344+ util
    33453345Do.prj #package description file
    … …  
    33573357        sequence.do #Case 4, module std/sequence;
    33583358        test.do #Case 5
    3359 \end{cfa}
     3359\end{lstlisting}
    33603360
    33613361\begin{itemize}
    … …  
    34353435Here is a simple example of the directory structure of a package, core.
    34363436It contains a module std and several sub-modules under std.
    3437 \begin{cfa}
     3437\begin{lstlisting}
    34383438+ core
    34393439        Do.prj
    … …  
    34453445        vector.do #module std/container/vector;
    34463446        list.do #module std/container/list;
    3447 \end{cfa}
     3447\end{lstlisting}
    34483448
    34493449
    … …  
    35343534
    35353535Here is an example of a package, util.
    3536 \begin{cfa}
     3536\begin{lstlisting}
    35373537+ util
    35383538        Do.prj #package description file
    … …  
    35503550        sequence.do #Case 4, module std/sequence;
    35513551        test.do #Case 5
    3552 \end{cfa}
     3552\end{lstlisting}
    35533553
    35543554
    … …  
    36413641\subsubsection{Package and Module Locating Example}
    36423642
    3643 \begin{cfa}
     3643\begin{lstlisting}
    36443644# A project's source code tree
    36453645
    … …  
    36763676
    36773677----------------------------------------
    3678 \end{cfa}
    3679 
    3680 
    3681 \begin{cfa}
     3678\end{lstlisting}
     3679
     3680
     3681\begin{lstlisting}
    36823682# pkg directory's source code tree
    36833683
    … …  
    37003700        security.do #module security;
    37013701------------------------------------------
    3702 \end{cfa}
     3702\end{lstlisting}
    37033703
    37043704
    … …  
    37443744\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
    37453745\hline
    3746 \begin{cfa}
     3746\begin{lstlisting}
    37473747struct Line {
    37483748        float lnth;
    … …  
    37713771Line line1;
    37723772Line line2 = { 3.4 };
    3773 \end{cfa}
     3773\end{lstlisting}
    37743774&
    37753775\begin{lstlisting}[language=C++]
    … …  
    38313831\end{lstlisting}
    38323832&
    3833 \begin{cfa}
     3833\begin{lstlisting}
    38343834struct Line {
    38353835        length: f32
    … …  
    38583858let line1:Line = Default::default();
    38593859Line line2( 3.4 );
    3860 \end{cfa}
     3860\end{lstlisting}
    38613861\end{tabular}
    38623862\end{flushleft}
    … …  
    38693869\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
    38703870\hline
    3871 \begin{cfa}
     3871\begin{lstlisting}
    38723872struct Cpx {
    38733873        double re, im;
    … …  
    38793879Cpx a, b, c;
    38803880c = a + b;
    3881 \end{cfa}
     3881\end{lstlisting}
    38823882&
    3883 \begin{cfa}
     3883\begin{lstlisting}
    38843884struct Cpx {
    38853885        double re, im;
    … …  
    38913891Cpx a, b, c;
    38923892c = a + b;
    3893 \end{cfa}
     3893\end{lstlisting}
    38943894&
    3895 \begin{cfa}
     3895\begin{lstlisting}
    38963896// no operator overloading
    38973897
    … …  
    39023902
    39033903
    3904 \end{cfa}
     3904\end{lstlisting}
    39053905&
    3906 \begin{cfa}
     3906\begin{lstlisting}
    39073907struct Cpx {
    39083908        re: f32,
    … …  
    39213921let (a, b, mut c) = ...;
    39223922c = a + b
    3923 \end{cfa}
     3923\end{lstlisting}
    39243924\end{tabular}
    39253925\end{flushleft}
    … …  
    39323932\multicolumn{1}{c|}{\textbf{\CFA/\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}   \\
    39333933\hline
    3934 \begin{cfa}[boxpos=t]
     3934\begin{lstlisting}[boxpos=t]
    39353935extern "C" {
    39363936#include <sys/types.h>
    … …  
    39433943        return s.st_size;
    39443944}
    3945 \end{cfa}
     3945\end{lstlisting}
    39463946&
    3947 \begin{cfa}[boxpos=t]
     3947\begin{lstlisting}[boxpos=t]
    39483948/*
    39493949#cgo
    … …  
    39623962        return buf._st_size
    39633963}
    3964 \end{cfa}
     3964\end{lstlisting}
    39653965&
    3966 \begin{cfa}[boxpos=t]
     3966\begin{lstlisting}[boxpos=t]
    39673967use libc::{c_int, size_t};
    39683968// translated from sys/stat.h
    … …  
    39863986        }
    39873987}
    3988 \end{cfa}
     3988\end{lstlisting}
    39893989\end{tabular}
    39903990\end{flushleft}
    … …  
    39973997\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
    39983998\hline
    3999 \begin{cfa}
     3999\begin{lstlisting}
    40004000generic(type T, type N |
    40014001        { int ?<?(N, N); })
    … …  
    40184018        return maximize(length, n, p);
    40194019}
    4020 \end{cfa}
     4020\end{lstlisting}
    40214021&
    4022 \begin{cfa}
     4022\begin{lstlisting}
    40234023template<typename T, typename F>
    40244024T *maximize(const F &f,
    … …  
    40434043        }, n, p);
    40444044}
    4045 \end{cfa}
     4045\end{lstlisting}
    40464046&
    4047 \begin{cfa}
     4047\begin{lstlisting}
    40484048// Go does not support generics!
    40494049func maximize(
    … …  
    40734073        a).(string)
    40744074}
    4075 \end{cfa}
     4075\end{lstlisting}
    40764076&
    4077 \begin{cfa}
     4077\begin{lstlisting}
    40784078use std::cmp::Ordering;
    40794079
    … …  
    41014101        maximize(|x: &String| x.len(), a)
    41024102}
    4103 \end{cfa}
     4103\end{lstlisting}
    41044104\end{tabular}
    41054105\end{flushleft}
    … …  
    41094109\subsubsection{Modules / Packages}
    41104110
    4111 \begin{cfa}
     4111\begin{lstlisting}
    41124112\CFA
    41134113\CC
    … …  
    41854185        println!(.{}., M::inc(100));
    41864186}
    4187 \end{cfa}
     4187\end{lstlisting}
    41884188\end{comment}
    41894189
    … …  
    41954195\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
    41964196\hline
    4197 \begin{cfa}
     4197\begin{lstlisting}
    41984198task Nonzero {
    41994199        int *data;
    … …  
    42364236        return res;
    42374237}
    4238 \end{cfa}
     4238\end{lstlisting}
    42394239&
    4240 \begin{cfa}
     4240\begin{lstlisting}
    42414241#include <thread>
    42424242#include <mutex>
    … …  
    42794279        return res;
    42804280}
    4281 \end{cfa}
     4281\end{lstlisting}
    42824282&
    4283 \begin{cfa}
     4283\begin{lstlisting}
    42844284package main
    42854285
    … …  
    43044304        fmt.Println(res)
    43054305}
    4306 \end{cfa}
     4306\end{lstlisting}
    43074307&
    4308 \begin{cfa}
     4308\begin{lstlisting}
    43094309use std::thread;
    43104310use std::sync:mpsc::channel;
    … …  
    43394339        println!(.{}., res);
    43404340}
    4341 \end{cfa}
     4341\end{lstlisting}
    43424342\end{tabular}
    43434343\end{flushleft}
    … …  
    44364436\begin{description}
    44374437\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
    4438 \begin{cfa}
     4438\begin{lstlisting}
    44394439int rtn( int i );
    44404440int rtn( char c );
    44414441rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
    4442 \end{cfa}
     4442\end{lstlisting}
    44434443\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
    44444444In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
    4445 \begin{cfa}
     4445\begin{lstlisting}
    44464446sout | 'x' | " " | (int)'x' | endl;
    44474447x 120
    4448 \end{cfa}
     4448\end{lstlisting}
    44494449Having to cast ©'x'© to ©char© is non-intuitive.
    44504450\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
    4451 \begin{cfa}
     4451\begin{lstlisting}
    44524452sizeof( 'x' ) == sizeof( int )
    4453 \end{cfa}
     4453\end{lstlisting}
    44544454no long work the same in \CFA programs.
    44554455\item[Difficulty of converting:] simple
    … …  
    44604460\begin{description}
    44614461\item[Change:] make string literals ©const©:
    4462 \begin{cfa}
     4462\begin{lstlisting}
    44634463char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
    44644464char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
    4465 \end{cfa}
     4465\end{lstlisting}
    44664466The type of a string literal is changed from ©[] char© to ©const [] char©.
    44674467Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
    44684468\item[Rationale:] This change is a safety issue:
    4469 \begin{cfa}
     4469\begin{lstlisting}
    44704470char * p = "abc";
    44714471p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
    4472 \end{cfa}
     4472\end{lstlisting}
    44734473The same problem occurs when passing a string literal to a routine that changes its argument.
    44744474\item[Effect on original feature:] change to semantics of well-defined feature.
    … …  
    44804480\begin{description}
    44814481\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
    4482 \begin{cfa}
     4482\begin{lstlisting}
    44834483int i;                                                  §\C{// forward definition}§
    44844484int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
    44854485int i = 0;                                              §\C{// definition}§
    4486 \end{cfa}
     4486\end{lstlisting}
    44874487is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
    44884488This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
    4489 \begin{cfa}
     4489\begin{lstlisting}
    44904490struct X { int i; struct X *next; };
    44914491static struct X a;                              §\C{// forward definition}§
    44924492static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
    44934493static struct X a = { 1, &b };  §\C{// definition}§
    4494 \end{cfa}
     4494\end{lstlisting}
    44954495\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
    44964496\item[Effect on original feature:] change to semantics of well-defined feature.
    … …  
    45024502\begin{description}
    45034503\item[Change:] have ©struct© introduce a scope for nested types:
    4504 \begin{cfa}
     4504\begin{lstlisting}
    45054505enum ®Colour® { R, G, B, Y, C, M };
    45064506struct Person {
    … …  
    45164516Personß.ß®Colour® pc = Personß.ßR;      §\C{// type/enum defined inside}§
    45174517Personß.ßFace pretty;                   §\C{// type defined inside}§
    4518 \end{cfa}
     4518\end{lstlisting}
    45194519In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e., the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
    45204520\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
    … …  
    45314531\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
    45324532\item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
    4533 \begin{cfa}
     4533\begin{lstlisting}
    45344534struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
    45354535struct X {
    45364536struct Y { /* ... */ } y;
    45374537};
    4538 \end{cfa}
     4538\end{lstlisting}
    45394539All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.
    45404540Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
    … …  
    46024602\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    46034603\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
    4604 \begin{cfa}
     4604\begin{lstlisting}
    46054605int x = 0, y = 1, z = 2;
    46064606®sout® ®|® x ®|® y ®|® z ®| endl®;
    4607 \end{cfa}
     4607\end{lstlisting}
    46084608&
    4609 \begin{cfa}
     4609\begin{lstlisting}
    46104610
    46114611cout << x << " " << y << " " << z << endl;
    4612 \end{cfa}
     4612\end{lstlisting}
    46134613\end{tabular}
    46144614\end{quote2}
    … …  
    46214621\textbf{\CFA:}
    46224622&
    4623 \begin{cfa}
     4623\begin{lstlisting}
    46244624sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
    4625 \end{cfa}
     4625\end{lstlisting}
    46264626\\
    46274627\textbf{\CC:}
    46284628&
    4629 \begin{cfa}
     4629\begin{lstlisting}
    46304630cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
    4631 \end{cfa}
     4631\end{lstlisting}
    46324632\end{tabular}
    46334633\end{quote2}
    … …  
    46394639\item
    46404640A separator does not appear at the start or end of a line.
    4641 \begin{cfa}[belowskip=0pt]
     4641\begin{lstlisting}[belowskip=0pt]
    46424642sout | 1 | 2 | 3 | endl;
    4643 \end{cfa}
    4644 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4643\end{lstlisting}
     4644\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    464546451 2 3
    4646 \end{cfa}
     4646\end{lstlisting}
    46474647\item
    46484648A separator does not appear before or after a character literal or variable.
    4649 \begin{cfa}
     4649\begin{lstlisting}
    46504650sout | '1' | '2' | '3' | endl;
    46514651123
    4652 \end{cfa}
     4652\end{lstlisting}
    46534653\item
    46544654A separator does not appear before or after a null (empty) C string
    4655 \begin{cfa}
     4655\begin{lstlisting}
    46564656sout | 1 | "" | 2 | "" | 3 | endl;
    46574657123
    4658 \end{cfa}
     4658\end{lstlisting}
    46594659which is a local mechanism to disable insertion of the separator character.
    46604660\item
    46614661A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{=$£¥¡¿«@
    46624662%$
    4663 \begin{cfa}[mathescape=off]
     4663\begin{lstlisting}[mathescape=off]
    46644664sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥" | 7
    46654665         | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
    4666 \end{cfa}
     4666\end{lstlisting}
    46674667%$
    4668 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4668\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    46694669x (1 x [2 x {3 x =4 x $5 x £6 x ¥7 x ¡8 x ¿9 x «10
    4670 \end{cfa}
     4670\end{lstlisting}
    46714671%$
    46724672\item
    46734673{\lstset{deletedelim=**[is][]{¢}{¢}}
    46744674A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»©
    4675 \begin{cfa}[belowskip=0pt]
     4675\begin{lstlisting}[belowskip=0pt]
    46764676sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | "% x"
    46774677         | 8 | "¢ x" | 9 | "» x" | 10 | ") x" | 11 | "] x" | 12 | "} x" | endl;
    4678 \end{cfa}
    4679 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4678\end{lstlisting}
     4679\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    468046801, x 2. x 3: x 4; x 5! x 6? x 7% x 8¢ x 9» x 10) x 11] x 12} x
    4681 \end{cfa}}%
     4681\end{lstlisting}}%
    46824682\item
    46834683A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[showspaces=true]@`'" \t\v\f\r\n@
    4684 \begin{cfa}[belowskip=0pt]
     4684\begin{lstlisting}[belowskip=0pt]
    46854685sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl;
    4686 \end{cfa}
    4687 \begin{cfa}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
     4686\end{lstlisting}
     4687\begin{lstlisting}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
    46884688x`1`x'2'x"3"x x 4 x x   1       x
    4689 \end{cfa}
     4689\end{lstlisting}
    46904690\end{enumerate}
    46914691The following \CC-style \Index{manipulator}s allow further control over implicit seperation.
    4692 \begin{cfa}[mathescape=off,belowskip=0pt]
     4692\begin{lstlisting}[mathescape=off,belowskip=0pt]
    46934693sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start of line}§
    4694 \end{cfa}
    4695 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4694\end{lstlisting}
     4695\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    46964696 1 2 3
    4697 \end{cfa}
    4698 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4697\end{lstlisting}
     4698\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    46994699sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// turn off implicit separator locally}§
    4700 \end{cfa}
    4701 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4700\end{lstlisting}
     4701\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    4702470212 3
    4703 \end{cfa}
    4704 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4703\end{lstlisting}
     4704\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    47054705sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// turn off implicit separation globally}§
    4706 \end{cfa}
    4707 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4706\end{lstlisting}
     4707\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    47084708123
    4709 \end{cfa}
    4710 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4709\end{lstlisting}
     4710\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    47114711sout | 1 | sepOn | 2 | 3 | endl;                        §\C{// turn on implicit separator locally}§
    4712 \end{cfa}
    4713 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4712\end{lstlisting}
     4713\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    471447141 23
    4715 \end{cfa}
    4716 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4715\end{lstlisting}
     4716\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    47174717sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// turn on implicit separation globally}§
    4718 \end{cfa}
    4719 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4718\end{lstlisting}
     4719\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    47204720 1 2 3
    4721 \end{cfa}
    4722 \begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
     4721\end{lstlisting}
     4722\begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
    47234723sepSet( sout, ", $" );                                          §\C{// change separator from " " to ", \$"}§
    47244724sout | 1 | 2 | 3 | endl;
    4725 \end{cfa}
     4725\end{lstlisting}
    47264726%$
    4727 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
     4727\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt]
    472847281, $2, $3
    4729 \end{cfa}
     4729\end{lstlisting}
    47304730%$
    47314731\begin{comment}
    … …  
    47694769
    47704770\leavevmode
    4771 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     4771\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47724772forall( otype T ) T * malloc( void );§\indexc{malloc}§
    47734773forall( otype T ) T * malloc( char fill );
    … …  
    47844784forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
    47854785forall( otype T ) T * memset( T * ptr );                                // remove when default value available
    4786 \end{cfa}
     4786\end{lstlisting}
    47874787
    47884788
    … …  
    47904790
    47914791\leavevmode
    4792 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     4792\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47934793int ato( const char * ptr );§\indexc{ato}§
    47944794unsigned int ato( const char * ptr );
    … …  
    48164816double _Complex strto( const char * sptr, char ** eptr );
    48174817long double _Complex strto( const char * sptr, char ** eptr );
    4818 \end{cfa}
     4818\end{lstlisting}
    48194819
    48204820
    … …  
    48224822
    48234823\leavevmode
    4824 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     4824\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48254825forall( otype T | { int ?<?( T, T ); } )
    48264826T * bsearch( const T key, const T * arr, size_t dimension );§\indexc{bsearch}§
    … …  
    48284828forall( otype T | { int ?<?( T, T ); } )
    48294829void qsort( const T * arr, size_t dimension );§\indexc{qsort}§
    4830 \end{cfa}
     4830\end{lstlisting}
    48314831
    48324832
    … …  
    48344834
    48354835\leavevmode
    4836 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     4836\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48374837char abs( char );§\indexc{abs}§
    48384838int abs( int );
    … …  
    48454845double abs( double _Complex );
    48464846long double abs( long double _Complex );
    4847 \end{cfa}
     4847\end{lstlisting}
    48484848
    48494849
    … …  
    48514851
    48524852\leavevmode
    4853 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     4853\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48544854void rand48seed( long int s );§\indexc{rand48seed}§
    48554855char rand48();§\indexc{rand48}§
    … …  
    48634863double _Complex rand48();
    48644864long double _Complex rand48();
    4865 \end{cfa}
     4865\end{lstlisting}
    48664866
    48674867
    … …  
    48694869
    48704870\leavevmode
    4871 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     4871\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48724872forall( otype T | { int ?<?( T, T ); } )
    48734873T min( const T t1, const T t2 );§\indexc{min}§
    … …  
    48814881forall( otype T )
    48824882void swap( T * t1, T * t2 );§\indexc{swap}§
    4883 \end{cfa}
     4883\end{lstlisting}
    48844884
    48854885
    … …  
    48934893
    48944894\leavevmode
    4895 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     4895\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48964896float fabs( float );§\indexc{fabs}§
    48974897double fabs( double );
    … …  
    49374937double nan( const char * );
    49384938long double nan( const char * );
    4939 \end{cfa}
     4939\end{lstlisting}
    49404940
    49414941
    … …  
    49434943
    49444944\leavevmode
    4945 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     4945\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    49464946float exp( float );§\indexc{exp}§
    49474947double exp( double );
    … …  
    49944994double logb( double );
    49954995long double logb( long double );
    4996 \end{cfa}
     4996\end{lstlisting}
    49974997
    49984998
    … …  
    50005000
    50015001\leavevmode
    5002 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     5002\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    50035003float sqrt( float );§\indexc{sqrt}§
    50045004double sqrt( double );
    … …  
    50225022double _Complex pow( double _Complex, double _Complex );
    50235023long double _Complex pow( long double _Complex, long double _Complex );
    5024 \end{cfa}
     5024\end{lstlisting}
    50255025
    50265026
    … …  
    50285028
    50295029\leavevmode
    5030 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     5030\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    50315031float sin( float );§\indexc{sin}§
    50325032double sin( double );
    … …  
    50785078double atan( double, double );§\indexc{atan}§
    50795079long double atan( long double, long double );
    5080 \end{cfa}
     5080\end{lstlisting}
    50815081
    50825082
    … …  
    50845084
    50855085\leavevmode
    5086 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     5086\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    50875087float sinh( float );§\indexc{sinh}§
    50885088double sinh( double );
    … …  
    51265126double _Complex atanh( double _Complex );
    51275127long double _Complex atanh( long double _Complex );
    5128 \end{cfa}
     5128\end{lstlisting}
    51295129
    51305130
    … …  
    51325132
    51335133\leavevmode
    5134 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     5134\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    51355135float erf( float );§\indexc{erf}§
    51365136double erf( double );
    … …  
    51575157double tgamma( double );
    51585158long double tgamma( long double );
    5159 \end{cfa}
     5159\end{lstlisting}
    51605160
    51615161
    … …  
    51635163
    51645164\leavevmode
    5165 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     5165\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    51665166float floor( float );§\indexc{floor}§
    51675167double floor( double );
    … …  
    52115211long long int llround( double );
    52125212long long int llround( long double );
    5213 \end{cfa}
     5213\end{lstlisting}
    52145214
    52155215
    … …  
    52175217
    52185218\leavevmode
    5219 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
     5219\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    52205220float copysign( float, float );§\indexc{copysign}§
    52215221double copysign( double, double );
    … …  
    52525252double scalbln( double, long int );
    52535253long double scalbln( long double, long int );
    5254 \end{cfa}
     5254\end{lstlisting}
    52555255
    52565256
    … …  
    52615261When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
    52625262
    5263 \begin{cfa}[belowskip=0pt]
     5263\begin{lstlisting}[belowskip=0pt]
    52645264// implementation
    52655265struct Rational {§\indexc{Rational}§
    … …  
    53045304forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * );
    53055305forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational );
    5306 \end{cfa}
     5306\end{lstlisting}
    53075307
    53085308

  • src/GenPoly/Box.cc

    rc51b5a3 raf68f0a  
    3434#include "Parser/ParseNode.h"
    3535
    36 #include "SynTree/Attribute.h"
    3736#include "SynTree/Constant.h"
    3837#include "SynTree/Declaration.h"
    … …  
    166165                        using Parent::mutate;
    167166
    168                         PolyGenericCalculator();
    169 
    170167                        template< typename DeclClass >
    171168                        DeclClass *handleDecl( DeclClass *decl, Type *type );
    … …  
    201198                        ScopedSet< std::string > knownLayouts;          ///< Set of generic type layouts known in the current scope, indexed by sizeofName
    202199                        ScopedSet< std::string > knownOffsets;          ///< Set of non-generic types for which the offset array exists in the current scope, indexed by offsetofName
    203                         UniqueName bufNamer;                           ///< Namer for VLA buffers
    204200                };
    205201
    … …  
    14561452////////////////////////////////////////// PolyGenericCalculator ////////////////////////////////////////////////////
    14571453
    1458                 PolyGenericCalculator::PolyGenericCalculator()
    1459                         : Parent(), knownLayouts(), knownOffsets(), bufNamer( "_buf" ) {}
    1460 
    14611454                void PolyGenericCalculator::beginTypeScope( Type *ty ) {
    14621455                        scopeTyVars.beginScope();
    … …  
    15351528                        if ( ObjectDecl *objectDecl = dynamic_cast< ObjectDecl *>( declStmt->get_decl() ) ) {
    15361529                                if ( findGeneric( objectDecl->get_type() ) ) {
    1537                                         // change initialization of a polymorphic value object to allocate via a VLA
    1538                                         // (alloca was previously used, but can't be safely used in loops)
     1530                                        // change initialization of a polymorphic value object
     1531                                        // to allocate storage with alloca
    15391532                                        Type *declType = objectDecl->get_type();
    1540                                         std::string bufName = bufNamer.newName();
    1541                                         ObjectDecl *newBuf = new ObjectDecl( bufName, Type::StorageClasses(), LinkageSpec::C, 0,
    1542                                                 new ArrayType( Type::Qualifiers(), new BasicType( Type::Qualifiers(), BasicType::Kind::Char), new NameExpr( sizeofName( mangleType(declType) ) ),
    1543                                                 true, false, std::list<Attribute*>{ new Attribute( std::string{"aligned"}, std::list<Expression*>{ new ConstantExpr( Constant::from_int(8) ) } ) } ), 0 );
    1544                                         stmtsToAdd.push_back( new DeclStmt( noLabels, newBuf ) );
     1533                                        UntypedExpr *alloc = new UntypedExpr( new NameExpr( "__builtin_alloca" ) );
     1534                                        alloc->get_args().push_back( new NameExpr( sizeofName( mangleType( declType ) ) ) );
    15451535
    15461536                                        delete objectDecl->get_init();
    15471537
    1548                                         objectDecl->set_init( new SingleInit( new NameExpr( bufName ) ) );
     1538                                        std::list<Expression*> designators;
     1539                                        objectDecl->set_init( new SingleInit( alloc, designators, false ) ); // not constructed
    15491540                                }
    15501541                        }
Note: See TracChangeset for help on using the changeset viewer.