Changeset 3a48e283


Ignore:
Timestamp:
Apr 7, 2017, 2:32:07 PM (4 years ago)
Author:
Aaron Moss <a3moss@…>
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:
a0ad7dc
Parents:
122aecd (diff), 3db60cb (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:
2 added
10 edited

Legend:

Unmodified
Added
Removed
  • doc/LaTeXmacros/common.tex

    r122aecd r3a48e283  
    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

    r122aecd r3a48e283  
    36453645    contributer = {pabuhr@plg},
    36463646    author      = {James Gosling and Bill Joy and Guy Steele and Gilad Bracha and Alex Buckley},
    3647     title       = {The {Java} Language Specification},
     3647    title       = {{Java} Language Specification},
    36483648    publisher   = {Oracle},
    36493649    year        = 2015,
    3650     edition     = {Java SE 8},
     3650    edition     = {Java SE8},
    36513651}
    36523652
     
    45634563}
    45644564
    4565 @book{obj-c-book,
     4565@manual{obj-c-book,
    45664566    keywords = {objective-c},
    45674567    contributor = {a3moss@uwaterloo.ca},
    45684568    author = {{Apple Computer Inc.}},
    45694569    title = {The {Objective-C} Programming Language},
    4570     year = 2002
     4570    publisher = {Apple Computer Inc.},
     4571    address = {Cupertino, CA},
     4572    year = 2003
    45714573}
    45724574
    45734575@online{xcode7,
    4574     keywords = {objective-c},
    4575     contributor = {a3moss@uwaterloo.ca},
    4576     author = {{Apple Computer Inc.}},
    4577     title = {{Xcode} 7 Release Notes},
    4578     year = 2015,
    4579     url = {https://developer.apple.com/library/content/documentation/Xcode/Conceptual/RN-Xcode-Archive/Chapters/xc7_release_notes.html},
    4580     urldate = {2017-04-04}
     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}
    45814583}
    45824584
     
    48674869    journal     = {Computer Languages},
    48684870    year        = 1987,
    4869     volume      = 12, number = {3/4}, pages = {163-172},
     4871    volume      = 12,
     4872    number      = {3/4},
     4873    pages       = {163-172},
    48704874    abstract    = {
    48714875        Packages in the Ada language provide a mechanism for extending the
     
    58795883    organization= {The Rust Project Developers},
    58805884    year        = 2015,
    5881     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}},
    58825886}
    58835887
     
    65776581}
    65786582
    6579 @unpublished{TIOBE,
     6583@online{TIOBE,
    65806584    contributer = {pabuhr@plg},
    65816585    author      = {{TIOBE Index}},
    6582     title       = {},
    65836586    year        = {March 2017},
    6584     note        = {\url{http://www.tiobe.com/tiobe_index}},
     6587    url         = {http://www.tiobe.com/tiobe_index},
    65856588}
    65866589
  • doc/generic_types/acmart.cls

    r122aecd r3a48e283  
    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

    r122aecd r3a48e283  
    5151stringstyle=\tt,                                                                                % use typewriter font
    5252tabsize=4,                                                                                              % 4 space tabbing
    53 xleftmargin=\parindent,                                                                 % indent code to paragraph indentation
     53xleftmargin=\parindentlnth,                                                             % indent code to paragraph indentation
    5454%mathescape=true,                                                                               % LaTeX math escape in CFA code $...$
    5555escapechar=\$,                                                                                  % LaTeX escape in CFA code
     
    167167int forty_two = identity( 42 );                         $\C{// T is bound to int, forty\_two == 42}$
    168168\end{lstlisting}
    169 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 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 @dtype T@, where @dtype@ is short for ``data type''.
    170 
    171 Here, the runtime cost of polymorphism is spread over each polymorphic call, due to passing more arguments to polymorphic functions; preliminary experiments have shown this overhead is similar to \CC virtual function calls. An advantage of this design is that, unlike \CC template functions, \CFA @forall@ functions are compatible with C \emph{separate} compilation.
     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.
    172172
    173173Since 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:
     
    176176int val = twice( twice( 3.7 ) );
    177177\end{lstlisting}
    178 which works for any type @T@ with a matching addition operator. The polymorphism is achieved by creating a wrapper function for calling @+@ with @T@ bound to @double@, then passing this function to the first call of @twice@. There is now the option of using the same @twice@ and converting the result to @int@ on assignment, or creating another @twice@ with type parameter @T@ bound to @int@ because \CFA uses the return type in its type analysis. The first approach has a late conversion from @int@ to @double@ on the final assignment, while the second has an eager conversion to @int@. \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition.
    179 
    180 Monomorphic specializations of polymorphic functions can satisfy polymorphic type-assertions.
    181 % \begin{lstlisting}
    182 % forall(otype T `| { T twice(T); }`)           $\C{// type assertion}$
    183 % T four_times(T x) { return twice( twice(x) ); }
    184 % double twice(double d) { return d * 2.0; }    $\C{// (1)}$
    185 % double magic = four_times(10.5);                      $\C{// T bound to double, uses (1) to satisfy type assertion}$
    186 % \end{lstlisting}
    187 \begin{lstlisting}
    188 forall( otype T `| { int ?<?( T, T ); }` ) void qsort( const T * arr, size_t size );
    189 forall( otype T `| { int ?<?( T, T ); }` ) T * bsearch( T key, const T * arr, size_t size );
    190 double vals[10] = { /* 10 floating-point values */ };
    191 qsort( vals, 10 );                                                      $\C{// sort array}$
    192 double * val = bsearch( 5.0, vals, 10 );        $\C{// binary search sorted array for key}$
    193 \end{lstlisting}
    194 @qsort@ and @bsearch@ work for any type @T@ with a matching @<@ operator, and the built-in monomorphic specialization of @<@ for type @double@ is passed as an implicit parameter to the calls of @qsort@ and @bsearch@.
    195 
    196 Crucial to the design of a new programming language are the libraries to access thousands of external features.
    197 \CFA inherits a massive compatible library-base, where other programming languages have to rewrite or provide fragile inter-language communication with C.
    198 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:
    199183\begin{lstlisting}
    200184void * bsearch( const void * key, const void * base, size_t nmemb, size_t size,
     
    202186int comp( const void * t1, const void * t2 ) { return *(double *)t1 < *(double *)t2 ? -1 :
    203187                                *(double *)t2 < *(double *)t1 ? 1 : 0; }
     188double vals[10] = { /* 10 floating-point values */ };
    204189double key = 5.0;
    205 double * val = (double *)bsearch( &key, vals, size, sizeof(vals[0]), comp );
    206 \end{lstlisting}
    207 which can be augmented simply with a generalized, 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:
    208193\begin{lstlisting}
    209194forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) {
    210195        int comp( const void * t1, const void * t2 ) { /* as above with double changed to T */ }
    211         return (T *)bsearch( &key, arr, size, sizeof(T), comp );
    212 }
     196        return (T *)bsearch( &key, arr, size, sizeof(T), comp ); }
    213197forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
    214198        T *result = bsearch( key, arr, size );  $\C{// call first version}$
    215         return result ? result - arr : size;            $\C{// pointer subtraction includes sizeof(T)}$
    216 }
     199        return result ? result - arr : size; }  $\C{// pointer subtraction includes sizeof(T)}$
    217200double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
    218201int posn = bsearch( 5.0, vals, 10 );
     
    222205\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@.
    223206
    224 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:
    225 \begin{lstlisting}
    226 {
    227         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}$
    228221        qsort( vals, size );                                    $\C{// descending sort}$
    229222}
     
    251244\smallskip\par\noindent
    252245Hence, 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.
    253257
    254258
     
    262266        T ?+=?( T *, T );
    263267        T ++?( T * );
    264         T ?++( T * );
    265 };
     268        T ?++( T * ); };
    266269forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) {  // use trait
    267270        `T` total = { `0` };                                    $\C{// instantiate T from 0 by calling its constructor}$
    268271        for ( unsigned int i = 0; i < size; i += 1 )
    269272                total `+=` a[i];                                        $\C{// select appropriate +}$
    270         return total;
    271 }
     273        return total; }
    272274\end{lstlisting}
    273275
     
    278280        void ?{}( T *, T );                                             $\C{// copy constructor}$
    279281        void ?=?( T *, T );                                             $\C{// assignment operator}$
    280         void ^?{}( T * );                                               $\C{// destructor}$
    281 };
     282        void ^?{}( T * ); };                                    $\C{// destructor}$
    282283\end{lstlisting}
    283284Given 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.
     
    385386\end{lstlisting}
    386387
     388
    387389\subsection{Dynamic Generic Types}
    388390
  • doc/proposals/concurrency/concurrency.tex

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

    r122aecd r3a48e283  
    1414
    1515\longnewglossaryentry{group-acquire}
    16 {name={bulked acquiring}}
     16{name={bulk acquiring}}
    1717{
    1818Implicitly acquiring several monitors when entering a monitor.
     19}
     20
     21\longnewglossaryentry{mon-ctx}
     22{name={monitor context}}
     23{
     24The state of the current thread regarding which monitors are owned.
    1925}
    2026
  • doc/proposals/concurrency/style.tex

    r122aecd r3a48e283  
    11\input{common}                                          % bespoke macros used in the document
     2
     3\CFADefaultStyle
    24
    35\lstset{
  • doc/proposals/concurrency/version

    r122aecd r3a48e283  
    1 0.7.61
     10.7.134
  • doc/refrat/refrat.tex

    r122aecd r3a48e283  
    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

    r122aecd r3a48e283  
    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.