Changeset 3db60cb


Ignore:
Timestamp:
Apr 6, 2017, 3:39:39 PM (4 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
3a48e283, b0fedd4
Parents:
03bb816 (diff), 115a868 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

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

Location:
doc
Files:
11 added
6 edited

Legend:

Unmodified
Added
Removed
  • doc/LaTeXmacros/common.tex

    r03bb816 r3db60cb  
    1111%% Created On       : Sat Apr  9 10:06:17 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri Feb 10 11:32:36 2017
    14 %% Update Count     : 249
     13%% Last Modified On : Wed Apr  5 23:19:42 2017
     14%% Update Count     : 255
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    256256}%
    257257
    258 \newcommand{\CFADefaultStyle}{%
     258\newcommand{\CFADefaults}{%
    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,                                                                               %
     269keepspaces=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
    283286% inline code ©...© (copyright symbol) emacs: C-q M-)
    284287\lstMakeShortInline©                                                                    % single-character for \lstinline
    285 }%CFADefaultStyle
     288}% CFAStyle
     289
     290\lstnewenvironment{cfa}[1][]
     291{\CFADefaults\lstset{#1}}
     292{}
     293
    286294
    287295% Local Variables: %
  • doc/bibliography/cfa.bib

    r03bb816 r3db60cb  
    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
    30613071@article{Choi91,
    30623072    keywords    = {contra-variance, functions},
     
    36353645    contributer = {pabuhr@plg},
    36363646    author      = {James Gosling and Bill Joy and Guy Steele and Gilad Bracha and Alex Buckley},
    3637     title       = {The {Java} Language Specification},
     3647    title       = {{Java} Language Specification},
    36383648    publisher   = {Oracle},
    36393649    year        = 2015,
    3640     edition     = {Java SE 8},
     3650    edition     = {Java SE8},
    36413651}
    36423652
     
    45534563}
    45544564
     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
    45554585@book{Beta,
    45564586    keywords    = {Beta, object oriented, concurrency, exceptions},
     
    48394869    journal     = {Computer Languages},
    48404870    year        = 1987,
    4841     volume      = 12, number = {3/4}, pages = {163-172},
     4871    volume      = 12,
     4872    number      = {3/4},
     4873    pages       = {163-172},
    48424874    abstract    = {
    48434875        Packages in the Ada language provide a mechanism for extending the
     
    58515883    organization= {The Rust Project Developers},
    58525884    year        = 2015,
    5853     note        = {\href{https://doc.rust-lang.org/reference.html}{https://\-doc.rust-lang.org/\-reference.html}},
     5885    note        = {\href{https://doc.rust-lang.org/reference.html}{https://\-doc.rust-lang\-.org/\-reference.html}},
    58545886}
    58555887
     
    65496581}
    65506582
     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
    65516590@misc{Bumbulis90,
    65526591    keywords    = {parameter inference, ForceN},
     
    65556594    title       = {Towards Making Signatures First-Class},
    65566595    howpublished= {personal communication},
    6557     month       = sep, year = 1990,
     6596    month       = sep,
     6597    year        = 1990,
    65586598    note        = {}
    65596599}
     
    68616901}
    68626902
     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
    68636913@inproceedings{Amdahl67,
    68646914    author      = {Gene M. Amdahl},
  • doc/generic_types/acmart.cls

    r03bb816 r3db60cb  
    354354\let\@footnotemark@nolink\@footnotemark
    355355\let\@footnotetext@nolink\@footnotetext
    356 \RequirePackage[bookmarksnumbered]{hyperref}
     356\RequirePackage[bookmarksnumbered,breaklinks]{hyperref}
    357357\urlstyle{rm}
    358358\ifcase\ACM@format@nr
  • doc/generic_types/generic_types.tex

    r03bb816 r3db60cb  
    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 
    31 \newcommand{\TODO}[1]{\textbf{TODO}: #1} % TODO included
     30\newcommand{\CS}{C\raisebox{-0.7ex}{\Large$^\sharp$}\xspace}
     31\newcommand{\Textbf}[1]{{\color{red}\textbf{#1}}}
     32
     33\newcommand{\TODO}[1]{\textbf{TODO}: {\itshape #1}} % TODO included
    3234%\newcommand{\TODO}[1]{} % TODO elided
    3335\newcommand{\eg}{\textit{e}.\textit{g}.,\xspace}
     
    4951stringstyle=\tt,                                                                                % use typewriter font
    5052tabsize=4,                                                                                              % 4 space tabbing
    51 xleftmargin=\parindent,                                                                 % indent code to paragraph indentation
     53xleftmargin=\parindentlnth,                                                             % indent code to paragraph indentation
    5254%mathescape=true,                                                                               % LaTeX math escape in CFA code $...$
    5355escapechar=\$,                                                                                  % LaTeX escape in CFA code
     
    9092}
    9193
    92 \terms{generic, tuple, types}
    93 \keywords{generic types, tuple types, polymorphic functions, C, Cforall}
     94\terms{generic, tuple, variadic, types}
     95\keywords{generic types, tuple types, variadic types, polymorphic functions, C, Cforall}
    9496
    9597\begin{CCSXML}
     
    118120
    119121\begin{abstract}
    120 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. Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive. The goal of the \CFA project is to create an extension of C that provides modern safety and productivity features while still ensuring strong backwards compatibility with C and its programmers. Prior projects have attempted similar goals but failed to honour C programming-style; for instance, adding object-oriented or functional programming with garbage collection is a non-starter for many C developers. Specifically, \CFA is designed to have an orthogonal feature-set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code-bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and engineers. This paper describes only two \CFA extensions, generic and tuple types, and how they are implemented in accordance with these principles.
     122The 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. Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive. The goal of the \CFA project is to create an extension of C that provides modern safety and productivity features while still ensuring strong backwards compatibility with C and its programmers. Prior projects have attempted similar goals but failed to honour C programming-style; for instance, adding object-oriented or functional programming with garbage collection is a non-starter for many C developers. Specifically, \CFA is designed to have an orthogonal feature-set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code-bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and engineers. This paper describes two \CFA extensions, generic and tuple types, details how their design avoids shortcomings of similar features in C and other C-like languages, and presents experimental results validating the design.
    121123\end{abstract}
    122124
     
    124126\maketitle
    125127
    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}
    135 These 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 describes how generic and tuple types are designed and implemented in \CFA in accordance with both the backward compatibility goals and existing features described above.
     128
     129\section{Introduction and Background}
     130
     131The 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.
     132The \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
     139Java    & 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@
     147Love it or hate it, C is extremely popular, highly used, and one of the few system's languages.
     148In many cases, \CC is often used solely as a better C.
     149Nonetheless, 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.
     156These 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
     158This 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.
    138159
    139160
     
    141162\label{sec:poly-fns}
    142163
    143 \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):
     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):
    144165\begin{lstlisting}
    145166`forall( otype T )` T identity( T val ) { return val; }
    146167int forty_two = identity( 42 );                         $\C{// T is bound to int, forty\_two == 42}$
    147168\end{lstlisting}
    148 The @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''.
    149 
    150 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 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.
    151 
    152 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 instance, @twice@ can be defined using the \CFA syntax for operator overloading:
    153 \begin{lstlisting}
    154 forall( otype T | { T `?`+`?`(T, T); } )        $\C{// ? denotes operands}$
    155   T twice( T x ) { return x + x; }                      $\C{// (2)}$
     169The @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
     171Here, 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
     173Since 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}
     175forall( otype T `| { T ?+?(T, T); }` ) T twice( T x ) { return x + x; } $\C{// ? denotes operands}$
    156176int val = twice( twice( 3.7 ) );
    157177\end{lstlisting}
    158 which 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.
    159 
    160 Monomorphic specializations of polymorphic functions can satisfy polymorphic type-assertions.
    161 % \begin{lstlisting}
    162 % forall(otype T `| { T twice(T); }`)           $\C{// type assertion}$
    163 % T four_times(T x) { return twice( twice(x) ); }
    164 % double twice(double d) { return d * 2.0; }    $\C{// (1)}$
    165 % double magic = four_times(10.5);                      $\C{// T bound to double, uses (1) to satisfy type assertion}$
    166 % \end{lstlisting}
    167 \begin{lstlisting}
    168 forall( otype T `| { int ?<?( T, T ); }` )      $\C{// type assertion}$
    169   void qsort( const T * arr, size_t size );
    170 forall( otype T `| { int ?<?( T, T ); }` )      $\C{// type assertion}$
    171   T * bsearch( T key, const T * arr, size_t size );
    172 double vals[10] = { /* 10 floating-point values */ };
    173 qsort( vals, 10 );                                                      $\C{// sort array}$
    174 double * val = bsearch( 5.0, vals, 10 );        $\C{// binary search sorted array for key}$
    175 \end{lstlisting}
    176 @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.
    177 Here, the built-in monomorphic specialization of @<@ for type @double@ is passed as an additional implicit parameter to the calls of @qsort@ and @bsearch@.
    178 
    179 Crucial to the design of a new programming language are the libraries to access thousands of external features.
    180 \CFA inherits a massive compatible library-base, where other programming languages have to rewrite or provide fragile inter-language communication with C.
    181 A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@, shown here searching a floating-point array:
     178which 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
     180Crucial 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.
     182A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@ to binary search a sorted floating-point array:
    182183\begin{lstlisting}
    183184void * bsearch( const void * key, const void * base, size_t nmemb, size_t size,
     
    185186int comp( const void * t1, const void * t2 ) { return *(double *)t1 < *(double *)t2 ? -1 :
    186187                                *(double *)t2 < *(double *)t1 ? 1 : 0; }
     188double vals[10] = { /* 10 floating-point values */ };
    187189double key = 5.0;
    188 double * val = (double *)bsearch( &key, vals, size, sizeof(vals[0]), comp );
    189 \end{lstlisting}
    190 but providing a type-safe \CFA overloaded wrapper.
     190double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
     191\end{lstlisting}
     192which can be augmented simply with a generalized, type-safe, \CFA-overloaded wrappers:
    191193\begin{lstlisting}
    192194forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) {
    193195        int comp( const void * t1, const void * t2 ) { /* as above with double changed to T */ }
    194         return (T *)bsearch( &key, arr, size, sizeof(T), comp );
    195 }
     196        return (T *)bsearch( &key, arr, size, sizeof(T), comp ); }
    196197forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
    197198        T *result = bsearch( key, arr, size );  $\C{// call first version}$
    198         return result ? result - arr : size;            $\C{// pointer subtraction includes sizeof(T)}$
    199 }
     199        return result ? result - arr : size; }  $\C{// pointer subtraction includes sizeof(T)}$
    200200double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
    201201int posn = bsearch( 5.0, vals, 10 );
    202202\end{lstlisting}
    203203The 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.
     204As well, an alternate kind of return is made available: position versus pointer to found element.
    205205\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@.
    206206
    207 Call-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:
    208 \begin{lstlisting}
    209 {   int ?<?( double x, double y ) { return x `>` y; }   $\C{// override behaviour}$
     207\CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations.
     208For example, it is possible to write a type-safe \CFA wrapper @malloc@ based on the C @malloc@:
     209\begin{lstlisting}
     210forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)(void *)malloc( (size_t)sizeof(T) ); }
     211int * ip = malloc();                                            $\C{// select type and size from left-hand side}$
     212double * dp = malloc();
     213struct S {...} * sp = malloc();
     214\end{lstlisting}
     215where the return type supplies the type/size of the allocation, which is impossible in most type systems.
     216
     217Call-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}
     219forall( 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}$
    210221        qsort( vals, size );                                    $\C{// descending sort}$
    211222}
    212223\end{lstlisting}
    213224Within the block, the nested version of @<@ performs @>@ and this local version overrides the built-in @<@ so it is passed to @qsort@.
    214 Hence, programmers can easily form new local environments to maximize reuse of existing functions and types.
    215 
    216 Finally, variables may be overloaded:
     225Hence, programmers can easily form a local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
     226
     227Finally, \CFA allows variable overloading:
    217228\lstDeleteShortInline@
    218229\par\smallskip
     
    233244\smallskip\par\noindent
    234245Hence, the single name @MAX@ replaces all the C type-specific names: @SHRT_MAX@, @INT_MAX@, @DBL_MAX@.
     246As 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.
     247In addition, several operations are defined in terms values @0@ and @1@.
     248For example,
     249\begin{lstlisting}
     250int x;
     251if (x)        // if (x != 0)
     252        x++;    //   x += 1;
     253\end{lstlisting}
     254Every 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.
     255Due 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.
     256The 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
    235258
    236259\subsection{Traits}
    237260
    238 \CFA provides \emph{traits} to name a group of type assertions:
    239 % \begin{lstlisting}
    240 % trait has_magnitude(otype T) {
    241 %     _Bool ?<?(T, T);                                          $\C{// comparison operator for T}$
    242 %     T -?(T);                                                          $\C{// negation operator for T}$
    243 %     void ?{}(T*, zero_t);                                     $\C{// constructor from 0 literal}$
    244 % };
    245 % forall(otype M | has_magnitude(M))
    246 % M abs( M m ) {
    247 %     M zero = { 0 };                                                   $\C{// uses zero\_t constructor from trait}$
    248 %     return m < zero ? -m : m;
    249 % }
    250 % forall(otype M | has_magnitude(M))
    251 % M max_magnitude( M a, M b ) {
    252 %     return abs(a) < abs(b) ? b : a;
    253 % }
    254 % \end{lstlisting}
     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:
    255262\begin{lstlisting}
    256263trait summable( otype T ) {
    257         void ?{}(T*, zero_t);                                   $\C{// constructor from 0 literal}$
     264        void ?{}( T *, zero_t );                                $\C{// constructor from 0 literal}$
    258265        T ?+?( T, T );                                                  $\C{// assortment of additions}$
    259266        T ?+=?( T *, T );
    260267        T ++?( T * );
    261         T ?++( T * );
    262 };
    263 forall( otype T | summable( T ) )
    264   T sum( T a[$\,$], size_t size ) {
    265         T total = { 0 };                                                $\C{// instantiate T from 0}$
     268        T ?++( T * ); };
     269forall( 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}$
    266271        for ( unsigned int i = 0; i < size; i += 1 )
    267                 total += a[i];                                          $\C{// select appropriate +}$
    268         return total;
    269 }
    270 \end{lstlisting}
    271 The trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration.
     272                total `+=` a[i];                                        $\C{// select appropriate +}$
     273        return total; }
     274\end{lstlisting}
    272275
    273276In fact, the set of operators is incomplete, \eg no assignment, but @otype@ is syntactic sugar for the following implicit trait:
    274277\begin{lstlisting}
    275 trait otype( dtype T | sized(T) ) {
    276         // sized is a compiler-provided pseudo-trait for types with known size and alignment}
     278trait otype( dtype T | sized(T) ) {  // sized is a pseudo-trait for types with known size and alignment
    277279        void ?{}( T * );                                                $\C{// default constructor}$
    278280        void ?{}( T *, T );                                             $\C{// copy constructor}$
    279281        void ?=?( T *, T );                                             $\C{// assignment operator}$
    280         void ^?{}( T * );                                               $\C{// destructor}$
    281 };
    282 \end{lstlisting}
    283 Given 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}:
    284 \begin{lstlisting}
    285 void abs( size_t _sizeof_M, size_t _alignof_M,
    286                 void (*_ctor_M)(void*), void (*_copy_M)(void*, void*),
    287                 void (*_assign_M)(void*, void*), void (*_dtor_M)(void*),
    288                 _Bool (*_lt_M)(void*, void*), void (*_neg_M)(void*, void*),
    289         void (*_ctor_M_zero)(void*, int),
    290                 void* m, void* _rtn ) {                         $\C{// polymorphic parameter and return passed as void*}$
    291                                                                                         $\C{// M zero = { 0 };}$
    292         void* zero = alloca(_sizeof_M);                 $\C{// stack allocate zero temporary}$
    293         _ctor_M_zero(zero, 0);                                  $\C{// initialize using zero\_t constructor}$
    294                                                                                         $\C{// return m < zero ? -m : m;}$
    295         void *_tmp = alloca(_sizeof_M);
    296         _copy_M( _rtn,                                                  $\C{// copy-initialize return value}$
    297                 _lt_M( m, zero ) ?                                      $\C{// check condition}$
    298                  (_neg_M(m, _tmp), _tmp) :                      $\C{// negate m}$
    299                  m);
    300         _dtor_M(_tmp); _dtor_M(zero);                   $\C{// destroy temporaries}$
    301 }
    302 \end{lstlisting}
    303 
    304 Semantically, 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:
     282        void ^?{}( T * ); };                                    $\C{// destructor}$
     283\end{lstlisting}
     284Given 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
     306Traits 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
     308Nominal inheritance can be simulated with traits using marker variables or functions:
    305309\begin{lstlisting}
    306310trait nominal(otype T) {
    307311    T is_nominal;
    308312};
    309 
    310313int is_nominal;                                                         $\C{// int now satisfies the nominal trait}$
    311314\end{lstlisting}
    312315
    313 Traits, 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:
     316Traits, 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:
    314317\begin{lstlisting}
    315318trait pointer_like(otype Ptr, otype El) {
    316319    lvalue El *?(Ptr);                                          $\C{// Ptr can be dereferenced into a modifiable value of type El}$
    317320}
    318 
    319321struct list {
    320322    int value;
    321     list *next;                                                         $\C{// may omit "struct" on type names}$
     323    list *next;                                                         $\C{// may omit "struct" on type names as in \CC}$
    322324};
    323 
    324325typedef list *list_iterator;
    325326
     
    334335One 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.
    335336
    336 Other 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.
     337Other 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.
    337338
    338339A 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:
     
    359360\end{lstlisting}
    360361
    361 \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.
    362 
    363 \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:
     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:
    364365\begin{lstlisting}
    365366forall(otype Key | { _Bool ?==?(Key, Key); _Bool ?<?(Key, Key); })
    366 struct sorted_set;
     367  struct sorted_set;
    367368\end{lstlisting}
    368369
     
    384385};
    385386\end{lstlisting}
     387
    386388
    387389\subsection{Dynamic Generic Types}
     
    860862Cyclone 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.
    861863
    862 Go \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.
     864Apple'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
     866D \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.
    863867
    864868\section{Conclusion \& Future Work}
    865869
    866 In conclusion, the authors' design for generic types and tuples imposes minimal runtime overhead while still supporting a full range of C features, including separately-compiled modules. There is ongoing work on a wide range of \CFA feature extensions, including reference types, exceptions, and concurrent programming primitives. In addition to this work, there are some interesting future directions the polymorphism design could take. Notably, \CC template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions. \CFA polymorphic functions, by contrast, use an approach that is essentially dynamic virtual dispatch. The runtime overhead of this approach is low, but not as low as \CC template functions, and it may be beneficial to provide a mechanism for particularly performance-sensitive code to close this gap. Further research is needed, but two promising approaches are to allow an annotation on polymorphic function call sites that tells the translator to create a template-specialization of the function (provided the code is visible in the current translation unit) or placing an annotation on polymorphic function definitions that instantiates a version of the polymorphic function specialized to some set of types. These approaches are not mutually exclusive, and would allow these performance optimizations to be applied only where most useful to increase performance, without suffering the code bloat or loss of generality of a template expansion approach where it is unnecessary.
     870There is ongoing work on a wide range of \CFA feature extensions, including reference types, exceptions, and concurrent programming primitives. In addition to this work, there are some interesting future directions the polymorphism design could take. Notably, \CC template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions. \CFA polymorphic functions, by contrast, use an approach that is essentially dynamic virtual dispatch. The runtime overhead of this approach is low, but not as low as \CC template functions, and it may be beneficial to provide a mechanism for particularly performance-sensitive code to close this gap. Further research is needed, but two promising approaches are to allow an annotation on polymorphic function call sites that tells the translator to create a template-specialization of the function (provided the code is visible in the current translation unit) or placing an annotation on polymorphic function definitions that instantiates a version of the polymorphic function specialized to some set of types. These approaches are not mutually exclusive, and would allow these performance optimizations to be applied only where most useful to increase performance, without suffering the code bloat or loss of generality of a template expansion approach where it is unnecessary.
     871
     872In conclusion, the authors' design for generic types and tuples, unlike those available in existing work, is both reusable and type-checked, while still supporting a full range of C features, including separately-compiled modules. We have experimentally validated the performance of our design against both \CC and standard C, showing it is \TODO{shiny, cap'n}.
    867873
    868874\begin{acks}
  • doc/refrat/refrat.tex

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

    r03bb816 r3db60cb  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Thu Mar 23 09:53:57 2017
    14 %% Update Count     : 1399
     13%% Last Modified On : Wed Apr  5 23:19:40 2017
     14%% Update Count     : 1412
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    5050%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    5151
    52 \CFADefaultStyle                                                                                % use default CFA format-style
     52\CFAStyle                                                                                               % 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{lstlisting}
     156\begin{cfa}
    157157#include <fstream>
    158158int main( void ) {
     
    160160        ®sout | x | y | z | endl;®
    161161}
    162 \end{lstlisting}
     162\end{cfa}
    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{lstlisting}
     247\begin{cfa}
    248248char abs( char );
    249 extern "C" {
     249®extern "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{lstlisting}
     260\end{cfa}
    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{lstlisting}
     275\begin{cfa}
    276276cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
    277 \end{lstlisting}
     277\end{cfa}
    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{lstlisting}
     354\begin{cfa}
    355355#ifndef __CFORALL__
    356356#include <stdio.h>                              §\C{// C header file}§
     
    358358#include <fstream>                              §\C{// \CFA header file}§
    359359#endif
    360 \end{lstlisting}
     360\end{cfa}
    361361which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
    362362
    363363
    364 \section{Underscores in Constants}
     364\section{Constants Underscores}
    365365
    366366Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
    367 \begin{lstlisting}
     367\begin{cfa}
    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{lstlisting}
     378\end{cfa}
    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}
     403int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
     404double ®`®choose®`® = 3.5;
     405\end{cfa}
     406Programs 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.
     407Clashes 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
    398424\section{Declarations}
    399425\label{s:Declarations}
     
    403429\begin{quote2}
    404430\begin{tabular}{@{}ll@{}}
    405 \begin{lstlisting}
     431\begin{cfa}
    406432int *x[5]
    407 \end{lstlisting}
     433\end{cfa}
    408434&
    409435\raisebox{-0.75\totalheight}{\input{Cdecl}}
     
    414440Another 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.
    415441For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    416 \begin{lstlisting}
     442\begin{cfa}
    417443int (*f())[5] {...};                    §\C{}§
    418444... (*f())[3] += 1;
    419 \end{lstlisting}
     445\end{cfa}
    420446Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
    421447While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
     
    428454\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    429455\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    430 \begin{lstlisting}
     456\begin{cfa}
    431457ß[5] *ß ®int® x1;
    432458ß* [5]ß ®int® x2;
    433459ß[* [5] int]ß f®( int p )®;
    434 \end{lstlisting}
     460\end{cfa}
    435461&
    436 \begin{lstlisting}
     462\begin{cfa}
    437463®int® ß*ß x1 ß[5]ß;
    438464®int® ß(*ßx2ß)[5]ß;
    439465ßint (*ßf®( int p )®ß)[5]ß;
    440 \end{lstlisting}
     466\end{cfa}
    441467\end{tabular}
    442468\end{quote2}
     
    448474\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    449475\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    450 \begin{lstlisting}
     476\begin{cfa}
    451477®*® int x, y;
    452 \end{lstlisting}
     478\end{cfa}
    453479&
    454 \begin{lstlisting}
     480\begin{cfa}
    455481int ®*®x, ®*®y;
    456 \end{lstlisting}
     482\end{cfa}
    457483\end{tabular}
    458484\end{quote2}
     
    461487\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    462488\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    463 \begin{lstlisting}
     489\begin{cfa}
    464490®*® int x;
    465491int y;
    466 \end{lstlisting}
     492\end{cfa}
    467493&
    468 \begin{lstlisting}
     494\begin{cfa}
    469495int ®*®x, y;
    470496
    471 \end{lstlisting}
     497\end{cfa}
    472498\end{tabular}
    473499\end{quote2}
     
    477503\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    478504\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    479 \begin{lstlisting}
     505\begin{cfa}
    480506[ 5 ] int z;
    481507[ 5 ] * char w;
     
    486512        [ 5 ] * int f2;
    487513};
    488 \end{lstlisting}
     514\end{cfa}
    489515&
    490 \begin{lstlisting}
     516\begin{cfa}
    491517int z[ 5 ];
    492518char *w[ 5 ];
     
    497523        int *f2[ 5 ]
    498524};
    499 \end{lstlisting}
     525\end{cfa}
    500526&
    501 \begin{lstlisting}
     527\begin{cfa}
    502528// array of 5 integers
    503529// array of 5 pointers to char
     
    508534
    509535
    510 \end{lstlisting}
     536\end{cfa}
    511537\end{tabular}
    512538\end{quote2}
     
    516542\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
    517543\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\
    518 \begin{lstlisting}
     544\begin{cfa}
    519545const * const int x;
    520546const * [ 5 ] const int y;
    521 \end{lstlisting}
     547\end{cfa}
    522548&
    523 \begin{lstlisting}
     549\begin{cfa}
    524550int const * const x;
    525551const int (* const y)[ 5 ]
    526 \end{lstlisting}
     552\end{cfa}
    527553&
    528 \begin{lstlisting}
     554\begin{cfa}
    529555// const pointer to const integer
    530556// const pointer to array of 5 const integers
    531 \end{lstlisting}
     557\end{cfa}
    532558\end{tabular}
    533559\end{quote2}
     
    537563\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    538564\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    539 \begin{lstlisting}
     565\begin{cfa}
    540566extern [ 5 ] int x;
    541567static * const int y;
    542 \end{lstlisting}
     568\end{cfa}
    543569&
    544 \begin{lstlisting}
     570\begin{cfa}
    545571int extern x[ 5 ];
    546572const int static *y;
    547 \end{lstlisting}
     573\end{cfa}
    548574&
    549 \begin{lstlisting}
     575\begin{cfa}
    550576// externally visible array of 5 integers
    551577// internally visible pointer to constant int
    552 \end{lstlisting}
     578\end{cfa}
    553579\end{tabular}
    554580\end{quote2}
     
    557583At 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}}
    558584\eg:
    559 \begin{lstlisting}
     585\begin{cfa}
    560586x;                                                              §\C{// int x}§
    561587*y;                                                             §\C{// int *y}§
    562588f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
    563589f( p1, p2 ) {}                                  §\C{// int f( int p1, int p2 ) {}}§
    564 \end{lstlisting}
     590\end{cfa}
    565591
    566592Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
     
    583609\begin{quote2}
    584610\begin{tabular}{@{}lll@{}}
    585 \begin{lstlisting}
     611\begin{cfa}
    586612int x;
    587613x = 3;
    588614int y;
    589615y = x;
    590 \end{lstlisting}
     616\end{cfa}
    591617&
    592618\raisebox{-0.45\totalheight}{\input{pointer1}}
    593619&
    594 \begin{lstlisting}
     620\begin{cfa}
    595621int * ®const® x = (int *)100
    596622*x = 3;                 // implicit dereference
    597623int * ®const® y = (int *)104;
    598624*y = *x;                // implicit dereference
    599 \end{lstlisting}
     625\end{cfa}
    600626\end{tabular}
    601627\end{quote2}
     
    606632\begin{quote2}
    607633\begin{tabular}{@{}l|l@{}}
    608 \begin{lstlisting}
     634\begin{cfa}
    609635lda             r1,100                  // load address of x
    610636ld              r2,(r1)                   // load value of x
    611637lda             r3,104                  // load address of y
    612638st              r2,(r3)                   // store x into y
    613 \end{lstlisting}
     639\end{cfa}
    614640&
    615 \begin{lstlisting}
     641\begin{cfa}
    616642
    617643ld              r2,(100)                // load value of x
    618644
    619645st              r2,(104)                // store x into y
    620 \end{lstlisting}
     646\end{cfa}
    621647\end{tabular}
    622648\end{quote2}
     
    629655\begin{quote2}
    630656\begin{tabular}{@{}ll@{}}
    631 \begin{lstlisting}
     657\begin{cfa}
    632658int x, y, ®*® p1, ®*® p2, ®**® p3;
    633659p1 = ®&®x;               // p1 points to x
     
    635661p1 = ®&®y;               // p1 points to y
    636662p3 = &p2;               // p3 points to p2
    637 \end{lstlisting}
     663\end{cfa}
    638664&
    639665\raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}}
     
    643669Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location.
    644670In many cases, a compiler might be able to infer the meaning:
    645 \begin{lstlisting}
     671\begin{cfa}
    646672p2 = p1 + x;                                    §\C{// compiler infers *p2 = *p1 + x;}§
    647 \end{lstlisting}
     673\end{cfa}
    648674because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
    649675\Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
    650676However, in C, the following cases are ambiguous, especially with pointer arithmetic:
    651 \begin{lstlisting}
     677\begin{cfa}
    652678p1 = p2;                                                §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§
    653679p1 = p1 + 1;                                    §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§
    654 \end{lstlisting}
     680\end{cfa}
    655681
    656682Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}.
    657683In 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 ©*©.
    658 \begin{lstlisting}
     684\begin{cfa}
    659685p1 = p2;                                                §\C{// pointer address assignment}§
    660686*p1 = *p1 + 1;                                  §\C{// pointed-to value assignment / operation}§
    661 \end{lstlisting}
     687\end{cfa}
    662688which works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
    663689
    664690However, in most other situations, the pointed-to value is requested more often than the pointer address.
    665 \begin{lstlisting}
     691\begin{cfa}
    666692*p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
    667 \end{lstlisting}
     693\end{cfa}
    668694In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed.
    669695It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic:
    670 \begin{lstlisting}
     696\begin{cfa}
    671697p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15);
    672 \end{lstlisting}
     698\end{cfa}
    673699
    674700To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©.
    675 \begin{lstlisting}
     701\begin{cfa}
    676702int x, y, ®&® r1, ®&® r2, ®&&® r3;
    677703®&®r1 = &x;                                             §\C{// r1 points to x}§
     
    680706®&&®r3 = ®&®&r2;                                §\C{// r3 points to r2}§
    681707r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
    682 \end{lstlisting}
     708\end{cfa}
    683709Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
    684710Hence, a reference behaves like the variable name for the current variable it is pointing-to.
    685711The 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:
    686 \begin{lstlisting}
     712\begin{cfa}
    687713r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);
    688 \end{lstlisting}
     714\end{cfa}
    689715is rewritten as:
    690 \begin{lstlisting}
     716\begin{cfa}
    691717®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
    692 \end{lstlisting}
     718\end{cfa}
    693719When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{
    694720The unary ©&© operator yields the address of its operand.
     
    696722If 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}}
    697723Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}):
    698 \begin{lstlisting}
     724\begin{cfa}
    699725(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving variable r1 not variable pointed-to by r1}§
    700 \end{lstlisting}
     726\end{cfa}
    701727Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
    702 \begin{lstlisting}
     728\begin{cfa}
    703729(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3}§
    704 \end{lstlisting}
     730\end{cfa}
    705731Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses.
    706 \begin{lstlisting}
     732\begin{cfa}
    707733int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
    708734                 &r1 = x,    &&r2 = r1,   &&&r3 = r2;
     
    714740&&r3 = ...;                                             §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
    715741&&&r3 = p3;                                             §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
    716 \end{lstlisting}
     742\end{cfa}
    717743Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one.
    718744That 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.
     
    724750
    725751As for a pointer, a reference may have qualifiers:
    726 \begin{lstlisting}
     752\begin{cfa}
    727753const int cx = 5;                               §\C{// cannot change cx;}§
    728754const int & cr = cx;                    §\C{// cannot change what cr points to}§
     
    734760crc = 7;                                                §\C{// error, cannot change cx}§
    735761®&®crc = &cx;                                   §\C{// error, cannot change crc}§
    736 \end{lstlisting}
     762\end{cfa}
    737763Hence, 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:
    738 \begin{lstlisting}
     764\begin{cfa}
    739765int & const r = *0;                             §\C{// where 0 is the int * zero}§
    740 \end{lstlisting}
     766\end{cfa}
    741767Otherwise, 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.
    742768Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
     
    746772\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    747773\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    748 \begin{lstlisting}
     774\begin{cfa}
    749775®const® * ®const® * const int ccp;
    750776®const® & ®const® & const int ccr;
    751 \end{lstlisting}
     777\end{cfa}
    752778&
    753 \begin{lstlisting}
     779\begin{cfa}
    754780const int * ®const® * ®const® ccp;
    755781
    756 \end{lstlisting}
     782\end{cfa}
    757783\end{tabular}
    758784\end{quote2}
     
    762788There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding.
    763789For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
    764 \begin{lstlisting}
     790\begin{cfa}
    765791int * p = &x;                                   §\C{// both \&x and x are possible interpretations}§
    766792int & r = x;                                    §\C{// x unlikely interpretation, because of auto-dereferencing}§
    767 \end{lstlisting}
     793\end{cfa}
    768794Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression.
    769795Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator.
    770 \begin{lstlisting}
     796\begin{cfa}
    771797int & f( int & rp );                    §\C{// reference parameter and return}§
    772798z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
    773 \end{lstlisting}
     799\end{cfa}
    774800Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©.
    775801Since ©?+?© 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.
    776802
    777803When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
    778 \begin{lstlisting}
     804\begin{cfa}
    779805void f( ®const® int & crp );
    780806void g( ®const® int * cpp );
    781807f( 3 );                   g( &3 );
    782808f( x + y );             g( &(x + y) );
    783 \end{lstlisting}
     809\end{cfa}
    784810Here, 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.
    785811(The ©&© is necessary for the pointer parameter to make the types match, and is a common requirement for a C programmer.)
    786812\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.
    787 \begin{lstlisting}
     813\begin{cfa}
    788814void f( int & rp );
    789815void g( int * pp );
    790816f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
    791817f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
    792 \end{lstlisting}
     818\end{cfa}
    793819Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
    794820This 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.}
     
    796822
    797823While \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).
    798 \begin{lstlisting}
     824\begin{cfa}
    799825void f( int p ) {...}
    800826void (*fp)( int ) = &f;                 §\C{// pointer initialization}§
     
    802828(*fp)(3);                                               §\C{// pointer invocation}§
    803829fp(3);                                                  §\C{// reference invocation}§
    804 \end{lstlisting}
     830\end{cfa}
    805831A routine variable is best described by a ©const© reference:
    806 \begin{lstlisting}
     832\begin{cfa}
    807833const void (&fp)( int ) = f;
    808834fp( 3 );
    809835fp = ...                                                §\C{// error, cannot change code}§
    810836&fp = ...;                                              §\C{// changing routine reference}§
    811 \end{lstlisting}
     837\end{cfa}
    812838because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{
    813839Dynamic code rewriting is possible but only in special circumstances.}
    814840\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}
    822 int `otype` = 3;                                // make keyword an identifier
    823 double `choose` = 3.5;
    824 \end{lstlisting}
    825 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.
    826 Clashes 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{lstlisting}
     849\begin{cfa}
    850850y = (®* int®)x;
    851851i = sizeof(®[ 5 ] * int®);
    852 \end{lstlisting}
     852\end{cfa}
    853853&
    854 \begin{lstlisting}
     854\begin{cfa}
    855855y = (®int *®)x;
    856856i = sizeof(®int *[ 5 ]®);
    857 \end{lstlisting}
     857\end{cfa}
    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{lstlisting}
     866\begin{cfa}
    867867®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
    868868        §\emph{routine body}§
    869869}
    870 \end{lstlisting}
     870\end{cfa}
    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{lstlisting}
     878\begin{cfa}
    879879®extern® [ int x ] g( int y ) {§\,§}
    880 \end{lstlisting}
     880\end{cfa}
    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{lstlisting}
     883\begin{cfa}
    884884[§\,§] g();                                             §\C{// no input or output parameters}§
    885885[ void ] g( void );                             §\C{// no input or output parameters}§
    886 \end{lstlisting}
     886\end{cfa}
    887887
    888888Routine f is called as follows:
    889 \begin{lstlisting}
     889\begin{cfa}
    890890[ i, j, ch ] = f( 3, 'a', ch );
    891 \end{lstlisting}
     891\end{cfa}
    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{lstlisting}
     895\begin{cfa}
    896896int (*f(x))[ 5 ] int x; {}
    897 \end{lstlisting}
     897\end{cfa}
    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{lstlisting}
     901\begin{cfa}
    902902typedef int foo;
    903903int f( int (* foo) );                   §\C{// foo is redefined as a parameter name}§
    904 \end{lstlisting}
     904\end{cfa}
    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{lstlisting}
     910\begin{cfa}
    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{lstlisting}
     913\end{cfa}
    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{lstlisting}
     915\begin{cfa}
    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{lstlisting}
     919\end{cfa}
    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{lstlisting}
     926\begin{cfa}
    927927int f() {
    928928        int x;
     
    930930        return x;
    931931}
    932 \end{lstlisting}
     932\end{cfa}
    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{lstlisting}
     936\begin{cfa}
    937937®[ int x, int y ]® f() {
    938938        int z;
     
    940940        ®return;® §\C{// implicitly return x, y}§
    941941}
    942 \end{lstlisting}
     942\end{cfa}
    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{lstlisting}
     947\begin{cfa}
    948948[ int x, int y ] f() {
    949949        ...
    950950} §\C{// implicitly return x, y}§
    951 \end{lstlisting}
     951\end{cfa}
    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{lstlisting}
     959\begin{cfa}
    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{lstlisting}
     964\end{cfa}
    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{lstlisting}
     970\begin{cfa}
    971971[ int ] f(int), g;
    972 \end{lstlisting}
     972\end{cfa}
    973973&
    974 \begin{lstlisting}
     974\begin{cfa}
    975975int f(int), g(int);
    976 \end{lstlisting}
     976\end{cfa}
    977977\end{tabular}
    978978\end{quote2}
    979979Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
    980 \begin{lstlisting}
     980\begin{cfa}
    981981extern [ int ] f (int);
    982982static [ int ] g (int);
    983 \end{lstlisting}
     983\end{cfa}
    984984
    985985
     
    987987
    988988The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
    989 \begin{lstlisting}
     989\begin{cfa}
    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{lstlisting}
     994\end{cfa}
    995995While parameter names are optional, \emph{a routine name cannot be specified};
    996996for example, the following is incorrect:
    997 \begin{lstlisting}
     997\begin{cfa}
    998998* [ int x ] f () fp;            §\C{// routine name "f" is not allowed}§
    999 \end{lstlisting}
     999\end{cfa}
    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{lstlisting}
     1012\begin{cfa}
    10131013void p( int x, int y, int z ) {...}
    1014 \end{lstlisting}
     1014\end{cfa}
    10151015a positional call is:
    1016 \begin{lstlisting}
     1016\begin{cfa}
    10171017p( 4, 7, 3 );
    1018 \end{lstlisting}
     1018\end{cfa}
    10191019whereas a named (keyword) call may be:
    1020 \begin{lstlisting}
     1020\begin{cfa}
    10211021p( z : 3, x : 4, y : 7 );       §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
    1022 \end{lstlisting}
     1022\end{cfa}
    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{lstlisting}
     1037\begin{cfa}
    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{lstlisting}
     1043\end{cfa}
    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{lstlisting}
     1050\begin{cfa}
    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{lstlisting}
     1057\end{cfa}
    10581058However, named arguments compound routine resolution in conjunction with conversions:
    1059 \begin{lstlisting}
     1059\begin{cfa}
    10601060f( i : 3, 5.7 );                                §\C{// ambiguous call ?}§
    1061 \end{lstlisting}
     1061\end{cfa}
    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{lstlisting}
     1069\begin{cfa}
    10701070void p( int x = 1, int y = 2, int z = 3 ) {...}
    1071 \end{lstlisting}
     1071\end{cfa}
    10721072the allowable positional calls are:
    1073 \begin{lstlisting}
     1073\begin{cfa}
    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{lstlisting}
     1086\end{cfa}
    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{lstlisting}
     1108\begin{cfa}
    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{lstlisting}
     1112\end{cfa}
    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{lstlisting}
     1119\begin{cfa}
    11201120p( /* positional */, ... , /* named */ );
    11211121p( /* positional */, /* named */, ... );
    1122 \end{lstlisting}
     1122\end{cfa}
    11231123While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:
    1124 \begin{lstlisting}
     1124\begin{cfa}
    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{lstlisting}
     1128\end{cfa}
    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{lstlisting}
     1134\begin{cfa}
    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{lstlisting}
     1138\end{cfa}
    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{lstlisting}
     1150\begin{cfa}
    11511151void p( int x, int y = 2, int z = 3 ) {...}
    11521152
    11531153
    1154 \end{lstlisting}
     1154\end{cfa}
    11551155&
    1156 \begin{lstlisting}
     1156\begin{cfa}
    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{lstlisting}
     1160\end{cfa}
    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{lstlisting}
     1166\begin{cfa}
    11671167p( 1, /* default */, 5 );               §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
    1168 \end{lstlisting}
     1168\end{cfa}
    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{lstlisting}
     1188\begin{cfa}
    11891189struct S {
    11901190        enum C { R, G, B };
     
    12031203        union U u;
    12041204}
    1205 \end{lstlisting}
     1205\end{cfa}
    12061206&
    1207 \begin{lstlisting}
     1207\begin{cfa}
    12081208enum C { R, G, B };
    12091209union U { int i, j; };
     
    12221222
    12231223
    1224 \end{lstlisting}
     1224\end{cfa}
    12251225&
    1226 \begin{lstlisting}
     1226\begin{cfa}
    12271227struct S {
    12281228        enum C { R, G, B };
     
    12411241        union ®S.T.®U u;
    12421242}
    1243 \end{lstlisting}
     1243\end{cfa}
    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{lstlisting}
     1256\begin{cfa}
    12571257forall( otype T | { int ?<?( T, T ); } )
    12581258void qsort( const T * arr, size_t dimension );
    1259 \end{lstlisting}
     1259\end{cfa}
    12601260which can be used to sort in ascending and descending order by locally redefining the less-than operator into greater-than.
    1261 \begin{lstlisting}
     1261\begin{cfa}
    12621262const unsigned int size = 5;
    12631263int ia[size];
     
    12681268        qsort( ia, size );      §\C{// sort descending order by local redefinition}§
    12691269}
    1270 \end{lstlisting}
     1270\end{cfa}
    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{lstlisting}
     1275\begin{cfa}
    12761276[* [int]( int )] foo() {                §\C{// int (*foo())( int )}§
    12771277        int ®i® = 7;
     
    12861286    sout | fp( 3 ) | endl;
    12871287}
    1288 \end{lstlisting}
     1288\end{cfa}
    12891289because
    12901290
     
    12981298A list of such elements is called a \newterm{lexical list}.
    12991299The general syntax of a lexical list is:
    1300 \begin{lstlisting}
     1300\begin{cfa}
    13011301[ §\emph{exprlist}§ ]
    1302 \end{lstlisting}
     1302\end{cfa}
    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{lstlisting}
     1306\begin{cfa}
    13071307[ x, y, z ]
    13081308[ 2 ]
    13091309[ v+w, x*y, 3.14159, f() ]
    1310 \end{lstlisting}
     1310\end{cfa}
    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{lstlisting}
     1320\begin{cfa}
    13211321[ §\emph{typelist}§ ]
    1322 \end{lstlisting}
     1322\end{cfa}
    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{lstlisting}
     1325\begin{cfa}
    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{lstlisting}
     1330\end{cfa}
    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{lstlisting}
     1334\begin{cfa}
    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{lstlisting}
     1338\end{cfa}
    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{lstlisting}
     1344\begin{cfa}
    13451345f( [ 1, x+2, fred() ] );
    13461346f( 1, x+2, fred() );
    1347 \end{lstlisting}
     1347\end{cfa}
    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{lstlisting}
     1350\begin{cfa}
    13511351[ int, int ] w1;
    13521352[ int, int, int ] w2;
     
    13611361g( 1, w1 );
    13621362g( w2 );
    1363 \end{lstlisting}
     1363\end{cfa}
    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{lstlisting}
     1373\begin{cfa}
    13741374[ 1, 3, 5 ]
    13751375[ 1, (2, 3), 5 ]
    1376 \end{lstlisting}
     1376\end{cfa}
    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{lstlisting}
     1382\begin{cfa}
    13831383const volatile [ int, float, const int ] x;
    1384 \end{lstlisting}
     1384\end{cfa}
    13851385is equivalent to:
    1386 \begin{lstlisting}
     1386\begin{cfa}
    13871387[ const volatile int, const volatile float, const volatile int ] x;
    1388 \end{lstlisting}
     1388\end{cfa}
    13891389Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg:
    1390 \begin{lstlisting}
     1390\begin{cfa}
    13911391extern [ int, int ] w1;
    13921392static [ int, int, int ] w2;
    1393 \end{lstlisting}
     1393\end{cfa}
    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{lstlisting}
     1407\begin{cfa}
    14081408[ int, int, int, int ] w;
    14091409w = [ 1, 2, 3, 4 ];
    1410 \end{lstlisting}
     1410\end{cfa}
    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{lstlisting}
     1414\begin{cfa}
    14151415[ a, b, c, d ] = w
    1416 \end{lstlisting}
     1416\end{cfa}
    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{lstlisting}
     1420\begin{cfa}
    14211421[ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ];
    1422 \end{lstlisting}
     1422\end{cfa}
    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{lstlisting}
     1431\begin{cfa}
    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{lstlisting}
     1435\end{cfa}
    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{lstlisting}
     1450\begin{cfa}
    14511451[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
    1452 \end{lstlisting}
     1452\end{cfa}
    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{lstlisting}
     1459\begin{cfa}
    14601460[ x, y, z ] = 1.5;
    1461 \end{lstlisting}
     1461\end{cfa}
    14621462is equivalent to:
    1463 \begin{lstlisting}
     1463\begin{cfa}
    14641464x = 1.5; y = 1.5; z = 1.5;
    1465 \end{lstlisting}
     1465\end{cfa}
    14661466This semantics is not the same as the following in C:
    1467 \begin{lstlisting}
     1467\begin{cfa}
    14681468x = y = z = 1.5;
    1469 \end{lstlisting}
     1469\end{cfa}
    14701470as conversions between intermediate assignments may lose information.
    14711471A more complex example is:
    1472 \begin{lstlisting}
     1472\begin{cfa}
    14731473[ i, y[i], z ] = a + b;
    1474 \end{lstlisting}
     1474\end{cfa}
    14751475which is equivalent to:
    1476 \begin{lstlisting}
     1476\begin{cfa}
    14771477t = a + b;
    14781478a1 = &i; a2 = &y[i]; a3 = &z;
    14791479*a1 = t; *a2 = t; *a3 = t;
    1480 \end{lstlisting}
     1480\end{cfa}
    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{lstlisting}
     1490\begin{cfa}
    14911491[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
    1492 \end{lstlisting}
     1492\end{cfa}
    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{lstlisting}
     1497\begin{cfa}
    14981498[ x, y, z ] = [ 1, 2, 3 ];
    1499 \end{lstlisting}
     1499\end{cfa}
    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{lstlisting}
     1502\begin{cfa}
    15031503[ i, y[ i ], z ] = [ 1, i, a + b ];
    1504 \end{lstlisting}
     1504\end{cfa}
    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{lstlisting}
     1508\begin{cfa}
    15091509[ x, y ] = [ y, x ];
    1510 \end{lstlisting}
     1510\end{cfa}
    15111511correctly interchanges (swaps) the values stored in ©x© and ©y©.
    15121512The following cases are errors:
    1513 \begin{lstlisting}
     1513\begin{cfa}
    15141514[ a, b, c ] = [ 1, 2, 3, 4 ];
    15151515[ a, b, c ] = [ 1, 2 ];
    1516 \end{lstlisting}
     1516\end{cfa}
    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{lstlisting}
     1521\begin{cfa}
    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{lstlisting}
     1524\end{cfa}
    15251525
    15261526
     
    15291529As in C, \CFA mass and multiple assignments can be cascaded, producing cascade assignment.
    15301530Cascade assignment has the following form:
    1531 \begin{lstlisting}
     1531\begin{cfa}
    15321532§\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
    1533 \end{lstlisting}
     1533\end{cfa}
    15341534and it has the same parallel semantics as for mass and multiple assignment.
    15351535Some examples of cascade assignment are:
    1536 \begin{lstlisting}
     1536\begin{cfa}
    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{lstlisting}
     1541\end{cfa}
    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{lstlisting}
     1548\begin{cfa}
    15491549struct {
    15501550        int f1;                                 §\C{// named field}§
     
    15551555        int (*)(int);                   §\C{// disallowed, unnamed field}§
    15561556};
    1557 \end{lstlisting}
     1557\end{cfa}
    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{lstlisting}
     1561\begin{cfa}
    15621562struct {
    15631563        int , , ;                               §\C{// 3 unnamed fields}§
    15641564}
    1565 \end{lstlisting}
     1565\end{cfa}
    15661566
    15671567
     
    15701570Tuples may be used to select multiple fields of a record by field name.
    15711571Its general form is:
    1572 \begin{lstlisting}
     1572\begin{cfa}
    15731573§\emph{expr}§ . [ §\emph{fieldlist}§ ]
    15741574§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
    1575 \end{lstlisting}
     1575\end{cfa}
    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{lstlisting}
     1580\begin{cfa}
    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{lstlisting}
     1588\end{cfa}
    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{lstlisting}
     1593\begin{cfa}
    15941594struct inner {
    15951595        int f2, f3;
     
    16021602
    16031603o.[ f1, i.[ f2, f3 ], f4 ] = [ 11, 12, 13, 3.14159 ];
    1604 \end{lstlisting}
     1604\end{cfa}
    16051605
    16061606
     
    16171617\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    16181618\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    1619 \begin{lstlisting}
     1619\begin{cfa}
    16201620®L1:® do {
    16211621        ®L2:® while ( ... ) {
     
    16271627        } // while
    16281628} while ( ... );
    1629 \end{lstlisting}
     1629\end{cfa}
    16301630&
    1631 \begin{lstlisting}
     1631\begin{cfa}
    16321632do {
    16331633        while ( ... ) {
     
    16391639        L2: ; }
    16401640L1: ; } while ( ... );
    1641 \end{lstlisting}
     1641\end{cfa}
    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{lstlisting}
     1650\begin{cfa}
    16511651®L1:® {
    16521652        ... §declarations§ ...
     
    16651665        } // switch
    16661666} // compound
    1667 \end{lstlisting}
     1667\end{cfa}
    16681668&
    1669 \begin{lstlisting}
     1669\begin{cfa}
    16701670{
    16711671        ... §declarations§ ...
     
    16841684        } L2: ;
    16851685} L1: ;
    1686 \end{lstlisting}
     1686\end{cfa}
    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{lstlisting}
     1716\begin{cfa}
    17171717switch ( i ) {
    17181718  case 1:
     
    17231723        break;  // exit switch statement
    17241724}
    1725 \end{lstlisting}
     1725\end{cfa}
    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{lstlisting}
     1729\begin{cfa}
    17301730switch ( argc ) {
    17311731  case 3:
     
    17381738        // usage message
    17391739}
    1740 \end{lstlisting}
     1740\end{cfa}
    17411741&
    1742 \begin{lstlisting}
     1742\begin{cfa}
    17431743
    17441744if ( argc == 3 ) {
     
    17511751        // usage message
    17521752}
    1753 \end{lstlisting}
     1753\end{cfa}
    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{lstlisting}
     1759\begin{cfa}
    17601760switch ( i ) {
    17611761  case 1: case 3: case 5:       // odd values
     
    17661766        break;
    17671767}
    1768 \end{lstlisting}
     1768\end{cfa}
    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{lstlisting}
     1775\begin{cfa}
    17761776switch ( i ) {
    17771777  case 0:
     
    17881788        } // while
    17891789} // switch
    1790 \end{lstlisting}
     1790\end{cfa}
    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{lstlisting}
     1797\begin{cfa}
    17981798register int n = (count + 7) / 8;
    17991799switch ( count % 8 ) {
     
    18081808                } while ( --n > 0 );
    18091809}
    1810 \end{lstlisting}
     1810\end{cfa}
    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{lstlisting}
     1826\begin{cfa}
    18271827switch ( x ) {
    18281828        ®int y = 1;®                            §\C{// unreachable initialization}§
     
    18351835        ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
    18361836}
    1837 \end{lstlisting}
     1837\end{cfa}
    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{lstlisting}
     1860\begin{cfa}
    18611861case 1:  case 2:  case 3: ...
    1862 \end{lstlisting}
     1862\end{cfa}
    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{lstlisting}
     1866\begin{cfa}
    18671867®choose® ( i ) {
    18681868  case 1:  case 2:  case 3:
     
    18781878        j = 3;
    18791879}
    1880 \end{lstlisting}
     1880\end{cfa}
    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{lstlisting}
     1895\begin{cfa}
    18961896switch ( x ) {
    18971897        ®int i = 0;®                            §\C{// allowed only at start}§
     
    19061906  ...
    19071907}
    1908 \end{lstlisting}
     1908\end{cfa}
    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{lstlisting}
     1921\begin{cfa}
    19221922switch ( i ) {
    19231923  case ®1, 3, 5®:
     
    19261926        ...
    19271927}
    1928 \end{lstlisting}
     1928\end{cfa}
    19291929&
    1930 \begin{lstlisting}
     1930\begin{cfa}
    19311931switch ( i ) {
    19321932  case 1: case 3 : case 5:
     
    19351935        ...
    19361936}
    1937 \end{lstlisting}
     1937\end{cfa}
    19381938&
    1939 \begin{lstlisting}
     1939\begin{cfa}
    19401940
    19411941// odd values
     
    19441944
    19451945
    1946 \end{lstlisting}
     1946\end{cfa}
    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{lstlisting}
     1954\begin{cfa}
    19551955switch ( i ) {
    19561956  case ®1~5:®
     
    19591959        ...
    19601960}
    1961 \end{lstlisting}
     1961\end{cfa}
    19621962&
    1963 \begin{lstlisting}
     1963\begin{cfa}
    19641964switch ( i )
    19651965  case ®1 ... 5®:
     
    19681968        ...
    19691969}
    1970 \end{lstlisting}
     1970\end{cfa}
    19711971&
    1972 \begin{lstlisting}
     1972\begin{cfa}
    19731973
    19741974// 1, 2, 3, 4, 5
     
    19771977
    19781978
    1979 \end{lstlisting}
     1979\end{cfa}
    19801980\end{tabular}
    19811981\end{quote2}
    19821982Lists of subranges are also allowed.
    1983 \begin{lstlisting}
     1983\begin{cfa}
    19841984case ®1~5, 12~21, 35~42®:
    1985 \end{lstlisting}
     1985\end{cfa}
    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{lstlisting}
     1991\begin{cfa}
    19921992exception void h( int i );
    19931993exception int h( int i, double d );
     
    20062006} finally {
    20072007}
    2008 \end{lstlisting}
     2008\end{cfa}
    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{lstlisting}
     2019\begin{cfa}
    20202020// SensorValue is a distinct type and represented as an int
    20212021type SensorValue = int;
    2022 \end{lstlisting}
     2022\end{cfa}
    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{lstlisting}
     2028\begin{cfa}
    20292029type SensorValue = int;
    20302030void printValue(int v) {...}
     
    20392039
    20402040process(s); // implicit conversion to int
    2041 \end{lstlisting}
     2041\end{cfa}
    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{lstlisting}
     2049\begin{cfa}
    20502050type SensorValue = int;
    20512051// ()? is the overloaded conversion operator identifier
     
    20582058SensorValue s = ...;
    20592059process(s); // implicit call to conversion operator
    2060 \end{lstlisting}
     2060\end{cfa}
    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{lstlisting}
     2066\begin{cfa}
    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{lstlisting}
     2079\end{cfa}
    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{lstlisting}
     2082\begin{cfa}
    20832083type SensorValue = int;
    20842084explicit SensorValue ()?(int);
     
    20882088process(s); // compile-time error
    20892089process((int) s); // type is converted, no function is called
    2090 \end{lstlisting}
     2090\end{cfa}
    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{lstlisting}
     2098\begin{cfa}
    20992099struct Point {
    21002100        double x;
     
    21032103
    21042104Point p = {0.0, 0.0};
    2105 \end{lstlisting}
     2105\end{cfa}
    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{lstlisting}
     2112\begin{cfa}
    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{lstlisting}
     2124\end{cfa}
    21252125
    21262126
     
    21322132
    21332133\begin{figure}
    2134 \begin{lstlisting}
     2134\begin{cfa}
    21352135struct Widget {
    21362136        int id;
     
    21742174^bar; // explicit call to destructor
    21752175^?(bar); // explicit call to destructor
    2176 \end{lstlisting}
     2176\end{cfa}
    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{lstlisting}
     2213\begin{cfa}
    22142214int foo(int a, int b) {
    22152215        float sum = 0.0;
     
    22242224        ...
    22252225}
    2226 \end{lstlisting}
     2226\end{cfa}
    22272227
    22282228
     
    22452245For example, to define the constants for a complex type, the programmer would define the following:
    22462246
    2247 \begin{lstlisting}
     2247\begin{cfa}
    22482248struct Complex {
    22492249        double real;
     
    22632263...
    22642264}
    2265 \end{lstlisting}
     2265\end{cfa}
    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{lstlisting}
     2273\begin{cfa}
    22742274int pi = 3;
    22752275float pi = 3.14;
    22762276char pi = .p.;
    2277 \end{lstlisting}
     2277\end{cfa}
    22782278
    22792279
     
    22832283
    22842284The examples below give some basic intuition about how the resolution works.
    2285 \begin{lstlisting}
     2285\begin{cfa}
    22862286// Choose the one with less conversions
    22872287int doSomething(int value) {...} // option 1
     
    23062306
    23072307f = bar(d, e); // chooses option 5
    2308 \end{lstlisting}
     2308\end{cfa}
    23092309
    23102310
     
    23762376These operators are called using the normal C syntax.
    23772377
    2378 \begin{lstlisting}
     2378\begin{cfa}
    23792379type Complex = struct { // define a Complex type
    23802380        double real;
     
    24062406c = a + b;
    24072407print(.sum = . + c);
    2408 \end{lstlisting}
     2408\end{cfa}
    24092409
    24102410
     
    24152415\begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
    24162416\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{Indexc{gcc}} \\
    2417 \begin{lstlisting}
     2417\begin{cfa}
    24182418
    24192419auto j = 3.0 * 4;
    24202420int i;
    24212421auto k = i;
    2422 \end{lstlisting}
     2422\end{cfa}
    24232423&
    2424 \begin{lstlisting}
     2424\begin{cfa}
    24252425#define expr 3.0 * i
    24262426typeof(expr) j = expr;
    24272427int i;
    24282428typeof(i) k = i;
    2429 \end{lstlisting}
     2429\end{cfa}
    24302430&
    2431 \begin{lstlisting}
     2431\begin{cfa}
    24322432
    24332433// use type of initialization expression
    24342434
    24352435// use type of primary variable
    2436 \end{lstlisting}
     2436\end{cfa}
    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{lstlisting}
     2453\begin{cfa}
    24542454auto j = ®...®
    2455 \end{lstlisting}
     2455\end{cfa}
    24562456and the need to write a routine to compute using ©j©
    2457 \begin{lstlisting}
     2457\begin{cfa}
    24582458void rtn( ®...® parm );
    24592459rtn( j );
    2460 \end{lstlisting}
     2460\end{cfa}
    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{lstlisting}
     2490\begin{cfa}
    24912491generic(type T)
    24922492void swap(T &a, T &b) {
     
    25012501Point p1, p2;
    25022502swap(p1, p2);
    2503 \end{lstlisting}
     2503\end{cfa}
    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{lstlisting}
     2513\begin{cfa}
    25142514generic (type T | bool ?<?(T, T) )
    25152515
     
    25172517        return a < b ? a : b;
    25182518}
    2519 \end{lstlisting}
     2519\end{cfa}
    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{lstlisting}
     2528\begin{cfa}
    25292529generic (type T, type U | { T foo(T, U); U bar(U); })
    25302530
     
    25322532        return foo(t, bar(u));
    25332533}
    2534 \end{lstlisting}
     2534\end{cfa}
    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{lstlisting}
     2548\begin{cfa}
    25492549generic (type T)
    25502550interface Orderable {
     
    25562556        return a < b ? a : b;
    25572557}
    2558 \end{lstlisting}
     2558\end{cfa}
    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{lstlisting}
     2564\begin{cfa}
    25652565generic (type T | Orderable(T)
    25662566interface FooBarable {
     
    25682568        int Bar(T, T);
    25692569};
    2570 \end{lstlisting}
     2570\end{cfa}
    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{lstlisting}
     2581\begin{cfa}
    25822582// typedef the generic function pointers for later use
    25832583
     
    25942594        if (p(array[i])) f(NULL, array[i]);
    25952595}
    2596 \end{lstlisting}
     2596\end{cfa}
    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{lstlisting}
     2610\begin{cfa}
    26112611generic (type T)
    26122612struct LinkedListElem {
     
    26322632        return false;
    26332633}
    2634 \end{lstlisting}
     2634\end{cfa}
    26352635
    26362636
     
    26552655An exception is thrown using a throw statement, which accepts one argument.
    26562656
    2657 \begin{lstlisting}
     2657\begin{cfa}
    26582658        ...
    26592659
     
    26612661
    26622662        ...
    2663 \end{lstlisting}
     2663\end{cfa}
    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{lstlisting}
     2669\begin{cfa}
    26702670        ...
    26712671
     
    26762676                printf(.caught an exception: %d\n., e);
    26772677        }
    2678 \end{lstlisting}
     2678\end{cfa}
    26792679
    26802680
     
    26912691Instead, it infers the type based on the return value, and then allocates space for the inferred type.
    26922692
    2693 \begin{lstlisting}
     2693\begin{cfa}
    26942694float *f = malloc(); // allocates the size of a float
    26952695
     
    26992699
    27002700struct S *s = malloc(); // allocates the size of a struct S
    2701 \end{lstlisting}
     2701\end{cfa}
    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{lstlisting}
     2706\begin{cfa}
    27072707type Complex = struct {
    27082708        float real;
     
    27372737}
    27382738
    2739 \end{lstlisting}
     2739\end{cfa}
    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{lstlisting}
     2766\begin{cfa}
    27672767struct S {
    27682768        int 0, 1;
    27692769} s;
    2770 \end{lstlisting}
     2770\end{cfa}
    27712771The problem occurs in accessing these fields using the selection operation ``©.©'':
    2772 \begin{lstlisting}
     2772\begin{cfa}
    27732773s.0 = 0;        // ambiguity with floating constant .0
    27742774s.1 = 1;        // ambiguity with floating constant .1
    2775 \end{lstlisting}
     2775\end{cfa}
    27762776To make this work, a space is required after the field selection:
    2777 \begin{lstlisting}
     2777\begin{cfa}
    27782778®s.§\textvisiblespace§0® = 0;
    27792779®s.§\textvisiblespace§1® = 1;
    2780 \end{lstlisting}
     2780\end{cfa}
    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{lstlisting}
     2788\begin{cfa}
    27892789int *§\textvisiblespace§?()();  // declaration: space required after '*'
    27902790*§\textvisiblespace§?()();              // expression: space required after '*'
    2791 \end{lstlisting}
     2791\end{cfa}
    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{lstlisting}
     2796\begin{cfa}
    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{lstlisting}
     2801\end{cfa}
    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{lstlisting}
     2837\begin{cfa}
    28382838type Account = monitor {
    28392839        const unsigned long number; // account number
    28402840        float balance; // account balance
    28412841};
    2842 \end{lstlisting}
     2842\end{cfa}
    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{lstlisting}
     2852\begin{cfa}
    28532853// This function accesses a constant field, it does not require
    28542854// mutual exclusion
     
    28652865        return a.balance;
    28662866}
    2867 \end{lstlisting}
     2867\end{cfa}
    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{lstlisting}
     2875\begin{cfa}
    28762876// deleting a job from a worker requires mutual exclusion
    28772877
     
    28872887        ...
    28882888}
    2889 \end{lstlisting}
     2889\end{cfa}
    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{lstlisting}
     2897\begin{cfa}
    28982898type Adder = task {
    28992899        int *row;
     
    29012901        int &subtotal;
    29022902}
    2903 \end{lstlisting}
     2903\end{cfa}
    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{lstlisting}
     2911\begin{cfa}
    29122912void ?{}(Adder &a, int r[], int s, int &st) { // constructor
    29132913        a.row = r;
     
    29462946        printf(.total is %d\n., total);
    29472947}
    2948 \end{lstlisting}
     2948\end{cfa}
    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{lstlisting}
     2961\begin{cfa}
    29622962// type T is used as a generic type for all definitions inside
    29632963// the curly brackets
     
    29842984        }
    29852985}
    2986 \end{lstlisting}
     2986\end{cfa}
    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{lstlisting}
     2993\begin{cfa}
    29942994type Ping = task {
    29952995        Pong *partner;
     
    30293029        Ping{pong}; // initialize and start ping
    30303030}
    3031 \end{lstlisting}
     3031\end{cfa}
    30323032
    30333033The same functionality can be accomplished by providing functions to be called by the partner task.
    3034 \begin{lstlisting}
     3034\begin{cfa}
    30353035type Pingpong = task {
    30363036        String msg;
     
    30603060        go(ping);
    30613061}
    3062 \end{lstlisting}
     3062\end{cfa}
    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{lstlisting}
     3094\begin{cfa}
    30953095bool isEven(unsigned int x) {
    30963096        if (x == 0) return true;
     
    31023102        else return !isEven(x - 2);
    31033103}
    3104 \end{lstlisting}
     3104\end{cfa}
    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{lstlisting}
     3139\begin{cfa}
    31403140module M;
    31413141
     
    31503150
    31513151double bCounter;
    3152 \end{lstlisting}
     3152\end{cfa}
    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{lstlisting}
     3173\begin{cfa}
    31743174module util/counter;
    31753175export int f(int i) { return i+1; }
     
    31853185        return ct.f(200); // f() from the package counter
    31863186}
    3187 \end{lstlisting}
     3187\end{cfa}
    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{lstlisting}
     3192\begin{cfa}
    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{lstlisting}
     3210\end{cfa}
    32113211
    32123212
     
    32253225If an aggregated module is imported, all the included modules in the aggregation are imported.
    32263226
    3227 \begin{lstlisting}
     3227\begin{cfa}
    32283228module std/sequence;
    32293229
     
    32373237        module std/stack;
    32383238};
    3239 \end{lstlisting}
     3239\end{cfa}
    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{lstlisting}
     3343\begin{cfa}
    33443344+ util
    33453345Do.prj #package description file
     
    33573357        sequence.do #Case 4, module std/sequence;
    33583358        test.do #Case 5
    3359 \end{lstlisting}
     3359\end{cfa}
    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{lstlisting}
     3437\begin{cfa}
    34383438+ core
    34393439        Do.prj
     
    34453445        vector.do #module std/container/vector;
    34463446        list.do #module std/container/list;
    3447 \end{lstlisting}
     3447\end{cfa}
    34483448
    34493449
     
    35343534
    35353535Here is an example of a package, util.
    3536 \begin{lstlisting}
     3536\begin{cfa}
    35373537+ util
    35383538        Do.prj #package description file
     
    35503550        sequence.do #Case 4, module std/sequence;
    35513551        test.do #Case 5
    3552 \end{lstlisting}
     3552\end{cfa}
    35533553
    35543554
     
    36413641\subsubsection{Package and Module Locating Example}
    36423642
    3643 \begin{lstlisting}
     3643\begin{cfa}
    36443644# A project's source code tree
    36453645
     
    36763676
    36773677----------------------------------------
    3678 \end{lstlisting}
    3679 
    3680 
    3681 \begin{lstlisting}
     3678\end{cfa}
     3679
     3680
     3681\begin{cfa}
    36823682# pkg directory's source code tree
    36833683
     
    37003700        security.do #module security;
    37013701------------------------------------------
    3702 \end{lstlisting}
     3702\end{cfa}
    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{lstlisting}
     3746\begin{cfa}
    37473747struct Line {
    37483748        float lnth;
     
    37713771Line line1;
    37723772Line line2 = { 3.4 };
    3773 \end{lstlisting}
     3773\end{cfa}
    37743774&
    37753775\begin{lstlisting}[language=C++]
     
    38313831\end{lstlisting}
    38323832&
    3833 \begin{lstlisting}
     3833\begin{cfa}
    38343834struct Line {
    38353835        length: f32
     
    38583858let line1:Line = Default::default();
    38593859Line line2( 3.4 );
    3860 \end{lstlisting}
     3860\end{cfa}
    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{lstlisting}
     3871\begin{cfa}
    38723872struct Cpx {
    38733873        double re, im;
     
    38793879Cpx a, b, c;
    38803880c = a + b;
    3881 \end{lstlisting}
     3881\end{cfa}
    38823882&
    3883 \begin{lstlisting}
     3883\begin{cfa}
    38843884struct Cpx {
    38853885        double re, im;
     
    38913891Cpx a, b, c;
    38923892c = a + b;
    3893 \end{lstlisting}
     3893\end{cfa}
    38943894&
    3895 \begin{lstlisting}
     3895\begin{cfa}
    38963896// no operator overloading
    38973897
     
    39023902
    39033903
    3904 \end{lstlisting}
     3904\end{cfa}
    39053905&
    3906 \begin{lstlisting}
     3906\begin{cfa}
    39073907struct Cpx {
    39083908        re: f32,
     
    39213921let (a, b, mut c) = ...;
    39223922c = a + b
    3923 \end{lstlisting}
     3923\end{cfa}
    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{lstlisting}[boxpos=t]
     3934\begin{cfa}[boxpos=t]
    39353935extern "C" {
    39363936#include <sys/types.h>
     
    39433943        return s.st_size;
    39443944}
    3945 \end{lstlisting}
     3945\end{cfa}
    39463946&
    3947 \begin{lstlisting}[boxpos=t]
     3947\begin{cfa}[boxpos=t]
    39483948/*
    39493949#cgo
     
    39623962        return buf._st_size
    39633963}
    3964 \end{lstlisting}
     3964\end{cfa}
    39653965&
    3966 \begin{lstlisting}[boxpos=t]
     3966\begin{cfa}[boxpos=t]
    39673967use libc::{c_int, size_t};
    39683968// translated from sys/stat.h
     
    39863986        }
    39873987}
    3988 \end{lstlisting}
     3988\end{cfa}
    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{lstlisting}
     3999\begin{cfa}
    40004000generic(type T, type N |
    40014001        { int ?<?(N, N); })
     
    40184018        return maximize(length, n, p);
    40194019}
    4020 \end{lstlisting}
     4020\end{cfa}
    40214021&
    4022 \begin{lstlisting}
     4022\begin{cfa}
    40234023template<typename T, typename F>
    40244024T *maximize(const F &f,
     
    40434043        }, n, p);
    40444044}
    4045 \end{lstlisting}
     4045\end{cfa}
    40464046&
    4047 \begin{lstlisting}
     4047\begin{cfa}
    40484048// Go does not support generics!
    40494049func maximize(
     
    40734073        a).(string)
    40744074}
    4075 \end{lstlisting}
     4075\end{cfa}
    40764076&
    4077 \begin{lstlisting}
     4077\begin{cfa}
    40784078use std::cmp::Ordering;
    40794079
     
    41014101        maximize(|x: &String| x.len(), a)
    41024102}
    4103 \end{lstlisting}
     4103\end{cfa}
    41044104\end{tabular}
    41054105\end{flushleft}
     
    41094109\subsubsection{Modules / Packages}
    41104110
    4111 \begin{lstlisting}
     4111\begin{cfa}
    41124112\CFA
    41134113\CC
     
    41854185        println!(.{}., M::inc(100));
    41864186}
    4187 \end{lstlisting}
     4187\end{cfa}
    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{lstlisting}
     4197\begin{cfa}
    41984198task Nonzero {
    41994199        int *data;
     
    42364236        return res;
    42374237}
    4238 \end{lstlisting}
     4238\end{cfa}
    42394239&
    4240 \begin{lstlisting}
     4240\begin{cfa}
    42414241#include <thread>
    42424242#include <mutex>
     
    42794279        return res;
    42804280}
    4281 \end{lstlisting}
     4281\end{cfa}
    42824282&
    4283 \begin{lstlisting}
     4283\begin{cfa}
    42844284package main
    42854285
     
    43044304        fmt.Println(res)
    43054305}
    4306 \end{lstlisting}
     4306\end{cfa}
    43074307&
    4308 \begin{lstlisting}
     4308\begin{cfa}
    43094309use std::thread;
    43104310use std::sync:mpsc::channel;
     
    43394339        println!(.{}., res);
    43404340}
    4341 \end{lstlisting}
     4341\end{cfa}
    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{lstlisting}
     4438\begin{cfa}
    44394439int rtn( int i );
    44404440int rtn( char c );
    44414441rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
    4442 \end{lstlisting}
     4442\end{cfa}
    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{lstlisting}
     4445\begin{cfa}
    44464446sout | 'x' | " " | (int)'x' | endl;
    44474447x 120
    4448 \end{lstlisting}
     4448\end{cfa}
    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{lstlisting}
     4451\begin{cfa}
    44524452sizeof( 'x' ) == sizeof( int )
    4453 \end{lstlisting}
     4453\end{cfa}
    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{lstlisting}
     4462\begin{cfa}
    44634463char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
    44644464char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
    4465 \end{lstlisting}
     4465\end{cfa}
    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{lstlisting}
     4469\begin{cfa}
    44704470char * p = "abc";
    44714471p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
    4472 \end{lstlisting}
     4472\end{cfa}
    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{lstlisting}
     4482\begin{cfa}
    44834483int i;                                                  §\C{// forward definition}§
    44844484int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
    44854485int i = 0;                                              §\C{// definition}§
    4486 \end{lstlisting}
     4486\end{cfa}
    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{lstlisting}
     4489\begin{cfa}
    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{lstlisting}
     4494\end{cfa}
    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{lstlisting}
     4504\begin{cfa}
    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{lstlisting}
     4518\end{cfa}
    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{lstlisting}
     4533\begin{cfa}
    45344534struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
    45354535struct X {
    45364536struct Y { /* ... */ } y;
    45374537};
    4538 \end{lstlisting}
     4538\end{cfa}
    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{lstlisting}
     4604\begin{cfa}
    46054605int x = 0, y = 1, z = 2;
    46064606®sout® ®|® x ®|® y ®|® z ®| endl®;
    4607 \end{lstlisting}
     4607\end{cfa}
    46084608&
    4609 \begin{lstlisting}
     4609\begin{cfa}
    46104610
    46114611cout << x << " " << y << " " << z << endl;
    4612 \end{lstlisting}
     4612\end{cfa}
    46134613\end{tabular}
    46144614\end{quote2}
     
    46214621\textbf{\CFA:}
    46224622&
    4623 \begin{lstlisting}
     4623\begin{cfa}
    46244624sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
    4625 \end{lstlisting}
     4625\end{cfa}
    46264626\\
    46274627\textbf{\CC:}
    46284628&
    4629 \begin{lstlisting}
     4629\begin{cfa}
    46304630cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
    4631 \end{lstlisting}
     4631\end{cfa}
    46324632\end{tabular}
    46334633\end{quote2}
     
    46394639\item
    46404640A separator does not appear at the start or end of a line.
    4641 \begin{lstlisting}[belowskip=0pt]
     4641\begin{cfa}[belowskip=0pt]
    46424642sout | 1 | 2 | 3 | endl;
    4643 \end{lstlisting}
    4644 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4643\end{cfa}
     4644\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    464546451 2 3
    4646 \end{lstlisting}
     4646\end{cfa}
    46474647\item
    46484648A separator does not appear before or after a character literal or variable.
    4649 \begin{lstlisting}
     4649\begin{cfa}
    46504650sout | '1' | '2' | '3' | endl;
    46514651123
    4652 \end{lstlisting}
     4652\end{cfa}
    46534653\item
    46544654A separator does not appear before or after a null (empty) C string
    4655 \begin{lstlisting}
     4655\begin{cfa}
    46564656sout | 1 | "" | 2 | "" | 3 | endl;
    46574657123
    4658 \end{lstlisting}
     4658\end{cfa}
    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{lstlisting}[mathescape=off]
     4663\begin{cfa}[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{lstlisting}
     4666\end{cfa}
    46674667%$
    4668 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4668\begin{cfa}[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{lstlisting}
     4670\end{cfa}
    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{lstlisting}[belowskip=0pt]
     4675\begin{cfa}[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{lstlisting}
    4679 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4678\end{cfa}
     4679\begin{cfa}[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{lstlisting}}%
     4681\end{cfa}}%
    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{lstlisting}[belowskip=0pt]
     4684\begin{cfa}[belowskip=0pt]
    46854685sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl;
    4686 \end{lstlisting}
    4687 \begin{lstlisting}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
     4686\end{cfa}
     4687\begin{cfa}[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{lstlisting}
     4689\end{cfa}
    46904690\end{enumerate}
    46914691The following \CC-style \Index{manipulator}s allow further control over implicit seperation.
    4692 \begin{lstlisting}[mathescape=off,belowskip=0pt]
     4692\begin{cfa}[mathescape=off,belowskip=0pt]
    46934693sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start of line}§
    4694 \end{lstlisting}
    4695 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4694\end{cfa}
     4695\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    46964696 1 2 3
    4697 \end{lstlisting}
    4698 \begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4697\end{cfa}
     4698\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    46994699sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// turn off implicit separator locally}§
    4700 \end{lstlisting}
    4701 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4700\end{cfa}
     4701\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    4702470212 3
    4703 \end{lstlisting}
    4704 \begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4703\end{cfa}
     4704\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    47054705sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// turn off implicit separation globally}§
    4706 \end{lstlisting}
    4707 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4706\end{cfa}
     4707\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    47084708123
    4709 \end{lstlisting}
    4710 \begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4709\end{cfa}
     4710\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    47114711sout | 1 | sepOn | 2 | 3 | endl;                        §\C{// turn on implicit separator locally}§
    4712 \end{lstlisting}
    4713 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4712\end{cfa}
     4713\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    471447141 23
    4715 \end{lstlisting}
    4716 \begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4715\end{cfa}
     4716\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    47174717sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// turn on implicit separation globally}§
    4718 \end{lstlisting}
    4719 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4718\end{cfa}
     4719\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    47204720 1 2 3
    4721 \end{lstlisting}
    4722 \begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
     4721\end{cfa}
     4722\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
    47234723sepSet( sout, ", $" );                                          §\C{// change separator from " " to ", \$"}§
    47244724sout | 1 | 2 | 3 | endl;
    4725 \end{lstlisting}
     4725\end{cfa}
    47264726%$
    4727 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt]
     4727\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
    472847281, $2, $3
    4729 \end{lstlisting}
     4729\end{cfa}
    47304730%$
    47314731\begin{comment}
     
    47694769
    47704770\leavevmode
    4771 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     4771\begin{cfa}[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{lstlisting}
     4786\end{cfa}
    47874787
    47884788
     
    47904790
    47914791\leavevmode
    4792 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     4792\begin{cfa}[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{lstlisting}
     4818\end{cfa}
    48194819
    48204820
     
    48224822
    48234823\leavevmode
    4824 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     4824\begin{cfa}[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{lstlisting}
     4830\end{cfa}
    48314831
    48324832
     
    48344834
    48354835\leavevmode
    4836 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     4836\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    48374837char abs( char );§\indexc{abs}§
    48384838int abs( int );
     
    48454845double abs( double _Complex );
    48464846long double abs( long double _Complex );
    4847 \end{lstlisting}
     4847\end{cfa}
    48484848
    48494849
     
    48514851
    48524852\leavevmode
    4853 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     4853\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    48544854void rand48seed( long int s );§\indexc{rand48seed}§
    48554855char rand48();§\indexc{rand48}§
     
    48634863double _Complex rand48();
    48644864long double _Complex rand48();
    4865 \end{lstlisting}
     4865\end{cfa}
    48664866
    48674867
     
    48694869
    48704870\leavevmode
    4871 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     4871\begin{cfa}[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{lstlisting}
     4883\end{cfa}
    48844884
    48854885
     
    48934893
    48944894\leavevmode
    4895 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     4895\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    48964896float fabs( float );§\indexc{fabs}§
    48974897double fabs( double );
     
    49374937double nan( const char * );
    49384938long double nan( const char * );
    4939 \end{lstlisting}
     4939\end{cfa}
    49404940
    49414941
     
    49434943
    49444944\leavevmode
    4945 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     4945\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    49464946float exp( float );§\indexc{exp}§
    49474947double exp( double );
     
    49944994double logb( double );
    49954995long double logb( long double );
    4996 \end{lstlisting}
     4996\end{cfa}
    49974997
    49984998
     
    50005000
    50015001\leavevmode
    5002 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     5002\begin{cfa}[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{lstlisting}
     5024\end{cfa}
    50255025
    50265026
     
    50285028
    50295029\leavevmode
    5030 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     5030\begin{cfa}[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{lstlisting}
     5080\end{cfa}
    50815081
    50825082
     
    50845084
    50855085\leavevmode
    5086 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     5086\begin{cfa}[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{lstlisting}
     5128\end{cfa}
    51295129
    51305130
     
    51325132
    51335133\leavevmode
    5134 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     5134\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    51355135float erf( float );§\indexc{erf}§
    51365136double erf( double );
     
    51575157double tgamma( double );
    51585158long double tgamma( long double );
    5159 \end{lstlisting}
     5159\end{cfa}
    51605160
    51615161
     
    51635163
    51645164\leavevmode
    5165 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     5165\begin{cfa}[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{lstlisting}
     5213\end{cfa}
    52145214
    52155215
     
    52175217
    52185218\leavevmode
    5219 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     5219\begin{cfa}[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{lstlisting}
     5254\end{cfa}
    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{lstlisting}[belowskip=0pt]
     5263\begin{cfa}[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{lstlisting}
     5306\end{cfa}
    53075307
    53085308
Note: See TracChangeset for help on using the changeset viewer.