source: doc/user/user.tex @ e55ca05

aaron-thesisarm-ehcleanup-dtorsctordeferred_resndemanglerenumforall-pointer-decaygc_noraiijacob/cs343-translationjenkins-sandboxmemorynew-astnew-ast-unique-exprnew-envno_listpersistent-indexerpthread-emulationqualifiedEnumresolv-newstringwith_gc
Last change on this file since e55ca05 was e55ca05, checked in by Peter A. Buhr <pabuhr@…>, 6 years ago

fix bibliography for manuals, refactor common LaTeX macros

  • Property mode set to 100644
File size: 170.0 KB
Line 
1%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
2%%
3%% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
4%%
5%% The contents of this file are covered under the licence agreement in the
6%% file "LICENCE" distributed with Cforall.
7%%
8%% user.tex --
9%%
10%% Author           : Peter A. Buhr
11%% Created On       : Wed Apr  6 14:53:29 2016
12%% Last Modified By : Peter A. Buhr
13%% Last Modified On : Fri Apr  8 11:40:53 2016
14%% Update Count     : 42
15%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
16
17% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
18
19\documentclass[openright,twoside]{article}
20%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
21
22% Latex packages used in the document.
23\usepackage[T1]{fontenc}
24\usepackage{textcomp}
25\usepackage[latin1]{inputenc}
26\usepackage{upquote}
27\usepackage{fullpage,times}
28\usepackage{xspace}
29\usepackage{varioref}
30\usepackage{listings}
31\usepackage{footmisc}
32\usepackage{comment}
33\usepackage{latexsym}                                   % \Box
34\usepackage{mathptmx}                                   % better math font with "times"
35\usepackage[pagewise]{lineno}
36\renewcommand{\linenumberfont}{\scriptsize\sffamily}
37\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
38\usepackage{breakurl}
39\renewcommand{\UrlFont}{\small\sf}
40
41%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
42
43% Names used in the document.
44
45\newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
46
47%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
48
49% Bespoke macros used in the document.
50\input{common}
51
52\setcounter{secnumdepth}{3}     % number subsubsections
53\setcounter{tocdepth}{3}                % subsubsections in table of contents
54\makeindex
55
56%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
57
58\begin{document}
59\pagestyle{headings}
60\linenumbers                                    % comment out to turn off line numbering
61
62\title{\Huge
63\vspace*{1in}
64\CFA (\CFL) User Manual                         \\
65Version 1.0                                                     \\
66\vspace*{0.25in}
67\huge``describe not prescribe''         \\
68\vspace*{1in}
69}% title
70\author{\huge
71Peter A. Buhr and ...                           \\
72}% author
73\date{
74DRAFT\\\today
75}% date
76
77\pagenumbering{roman}
78\pagestyle{plain}
79
80\maketitle
81
82\vspace*{\fill}
83\thispagestyle{empty}
84\noindent
85\copyright\,2016 \CFA Project \\ \\
86\noindent
87This work is licensed under the Creative Commons Attribution 4.0 International License.
88To view a copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.
89\vspace*{1in}
90
91\clearpage
92\pdfbookmark[1]{Contents}{section}
93\tableofcontents
94
95\clearpage
96\pagenumbering{arabic}
97
98
99\section{Introduction}
100
101\CFA\footnote{Pronounced ``C-for-all'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed an as evolutionary step forward from the C programming language.
102The syntax of the \CFA language builds from that of C, and should look immediately familiar to C programmers.
103% Any language feature that is not described here can be assumed to be using the standard C11 syntax.
104\CFA has added many modern programming-language features, which directly leads to increased safety and productivity, while maintaining interoperability with existing C programs, and maintaining C-like performance.
105Like C, \CFA is a statically typed, procedural language with a low-overhead runtime, meaning there is no global garbage-collection.
106The primary new features include parametric-polymorphism routines and types, exceptions, concurrency, and modules.
107
108One of the main design philosophies of \CFA is to ``describe not prescribe'', which means \CFA tries to provide a pathway from low-level C programming to high-level \CFA programming, but it does not force programmers to ``do the right thing''.
109Programmers can cautiously add \CFA extensions to their C programs in any order and at any time to incrementally move towards safer, higher-level programming features.
110A programmer is always free to reach back to C from \CFA for any reason, and in many cases, new \CFA features have a fallback to a C mechanism.
111There is no notion or requirement for rewriting a legacy C program in \CFA;
112instead, a programmer evolves an existing C program into \CFA by incrementally incorporating \CFA features.
113New programs can be written in \CFA using a combination of C and \CFA features.
114\CC had a similar goal 30 years ago, but has struggled over the intervening time to incorporate modern programming-language features because of early design choices.
115\CFA has 30 years of hindsight and a much cleaner starting point than \CC.
116
117Like \CC, there may be both an old and new ways to achieve the same effect.
118For example, the following programs compare the \CFA and C I/O mechanisms.
119\begin{quote2}
120\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
121\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
122\begin{lstlisting}
123#include <fstream>
124int main( void ) {
125        int x = 0, y = 1, z = 2;
126        sout | x | y | z | endl;
127}
128\end{lstlisting}
129&
130\begin{lstlisting}
131#include <stdio.h>
132int main( void ) {
133        int x = 0, y = 1, z = 2;
134        printf( "%d %d %d\n", x, y, z );
135}
136\end{lstlisting}
137\end{tabular}
138\end{quote2}
139Both programs output the same result.
140While the \CFA I/O looks similar to the \CC style of output, there are several important differences, such as automatic spacing between variables as in Python (see also~\VRef{s:IOLibrary}).
141
142This document is a reference manual for the \CFA programming language, targeted at \CFA programmers.
143Implementers may also refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
144In its current state, this document covers the intended core features of the language.
145Changes to the syntax and additional features are expected to be included in later revisions.
146% For additional information, see \url{http://wiki.do-lang.org}.
147
148
149\section{History}
150
151The \CFA project started with K-W C~\cite{Till89,Buhr94a}, which extended C with new declaration syntax, multiple return values from routines, and extended assignment capabilities using the notion of tuples.
152(See~\cite{Werther96} for some similar work, but for \CC.)
153The original \CFA project~\cite{Ditchfield92} extended the C type system with parametric polymorphism and overloading, as opposed to the \CC approach of object-oriented extensions to the C type-system.
154A first implementation of the core Cforall language was created~\cite{Bilson03,Esteves04}, but at the time there was little interesting in extending C, so work did not continue.
155As the saying goes, ``What goes around, comes around'', and there is now renewed interest in the C programming language, so the \CFA project has been restarted.
156
157
158\section{Motivation: Why fix C?}
159
160Even with all its problems, C is a very popular programming language because it allows writing software at virtually any level in a computer system without restriction.
161For systems programming, where direct access to hardware and dealing with real-time issues is a requirement, C is usually the language of choice.
162As well, there are millions of lines of C legacy code, forming the base for many software development projects (especially on UNIX systems).
163The TIOBE index (\url{http://www.tiobe.com/tiobe_index}) for March 2016 shows programming-language popularity, with Java 20.5\%, C 14.5\%, \CC 6.7\%, \CS 4.3\%, Python 4.3\%, and all other programming languages below 3\%.
164Hence, C is still an extremely important programming language, with double the usage of \CC, where \CC itself is largely C code.
165Finally, love it or hate it, C has been an important and influential part of computer science for 40 years and it appears it will continue to be for many more years.
166Unfortunately, C has too many problems and omissions to make it an acceptable programming language for modern needs.
167
168The goal of this project is to engineer modern language features into C in an evolutionary rather than revolutionary way.
169\CC~\cite{c++,ANSI14:C++} is an example of a similar project;
170however, it largely extended the language, and did not address existing problems.\footnote{%
171Two important existing problems addressed were changing the type of character literals from \lstinline@int@ to \lstinline@char@ and enumerator from \lstinline@int@ to the type of its enumerators.}
172Fortran~\cite{Fortran08}, Ada~\cite{Ada12}, and Cobol~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features are added and problems fixed within the framework of the existing language.
173Java~\cite{Java8}, Go~\cite{Go}, Rust~\cite{Rust} and D~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
174These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
175As a result, there is a significant learning curve to move to these languages, and C legacy-code must be complete rewritten.
176These costs can be prohibitive for many companies with a large software base in C/\CC, and many programmers that require retraining to a new programming language.
177
178The result of this project is a language that is largely backwards compatible with C11~\cite{C11}, but containing many modern language features and fixing some of the well known C problems.
179Without significant extension to the C programming language, C will be unable to cope with the needs of modern programming problems and programmers;
180as a result, it will fade into disuse.
181Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
182While C11 made a few simple extensions to the language, nothing was added to address existing problems in the language or to augment the language with modern language features.
183While some may argue that modern language features may make C complex and inefficient, it is clear a language without modern capabilities is insufficient for the advanced programming problems existing today.
184
185
186\section{Interoperability}
187
188\CFA is designed to integrate well with existing C programs and libraries.
189The most important feature of interoperability is to use the same calling conventions, so there is no overhead to call existing C routines.
190This feature allows users of \CFA to take advantage of the existing panoply of C libraries from inside their \CFA code.
191In fact, one of the biggest issues for any new programming language is establishing a minimum level of library code to support a large body of activities.
192Programming-language developers often state that adequate library support costs many times more than designing and implementing the language itself.
193Like \CC, \CFA starts with immediate access to all exiting C libraries, and in many cases, can easily wrap library routines with simpler and safer interfaces, at very low cost.
194
195However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
196For example, the C math-library provides the following routines for computing the absolute value of the basic type: \lstinline@abs@, \lstinline@labs@, \lstinline@llabs@, \lstinline@fabs@, \lstinline@fabsf@, \lstinline@fabsl@, \lstinline@cabsf@, \lstinline@cabs@, and \lstinline@cabsl@.
197Whereas, \CFA wraps each of these routines into one with the common name \lstinline@abs@.
198\begin{lstlisting}
199extern "C" {
200#include <stdlib.h>                     // provide C prototype for integer "abs" routine
201} // extern "C"
202
203char abs( char );
204long int abs( long int );       // @{\CFA}@ overload name "abs" for other types
205long long int abs( long long int );
206float abs( float );
207double abs( double );
208long double abs( long double );
209float _Complex abs( float _Complex );
210double _Complex abs( double _Complex );
211long double _Complex abs( long double _Complex );
212\end{lstlisting}
213The problem is the name clash between the library routine \lstinline@abs@ and the \CFA names \lstinline@abs@.
214Hence, names appearing in an \lstinline@extern "C"@ block have \newterm{C linkage}.
215Then overloading polymorphism uses a mechanism called \newterm{name mangling} to create unique names that are different from C names, which are not mangled.
216Hence, there is the same need as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
217There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
218This example strongly illustrates a core idea in \CFA: \emph{the power of a name}.
219The name ``\lstinline@abs@'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
220Hence, knowing the name \lstinline@abs@ should be sufficient to apply it to any type where it is applicable.
221The time savings and safety of using one name uniformly versus @N@ unique names should not be underestimated.
222
223
224\section{Compiling \CFA}
225
226The command \lstinline@cfa@ is used to compile \CFA program(s).
227This command works like the GNU \lstinline@gcc@\index{gcc} command, e.g.:
228\begin{lstlisting}
229cfa [ gcc-options ] C/@{\CFA}@-files [ assembler/loader-files ]
230\end{lstlisting}
231By default, \CFA programs having the following \lstinline@gcc@ flags turned on:
232\begin{description}
233\item
234\hspace*{-4pt}\lstinline@-std=gnu99@
235The 1999 C standard plus GNU extensions.
236\end{description}
237The following new \CFA option is available:
238\begin{description}
239\item
240\hspace*{-4pt}\lstinline@-CFA@
241Only the C preprocessor and the \CFA translator steps are performed and the transformed program is written to standard output, which makes it possible to examine the code generated by the \CFA translator.
242\end{description}
243
244
245\section{Underscores in Constants}
246
247Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.:
248\begin{lstlisting}
2492`_`147`_`483`_`648;                            // decimal constant
25056_ul;                                          // decimal unsigned long constant
2510_377;                                          // octal constant
2520x_ff_ff;                                       // hexadecimal constant
2530x_ef3d_aa5c;                           // hexadecimal constant
2543.141_592_654;                          // floating point constant
25510_e_+1_00;                                     // floating point constant
2560x_ff_ff_p_3;                           // hexadecimal floating point
2570x_1.ffff_ffff_p_128_l;         // hexadecimal floating point long constant
258L_"\x_ff_ee";                           // wide character constant
259\end{lstlisting}
260The rules for placement of underscores is as follows:
261\begin{enumerate}
262\item
263A sequence of underscores is disallowed, e.g., \lstinline@12__34@ is invalid.
264\item
265Underscores may only appear within a sequence of digits (regardless of the digit radix).
266In other words, an underscore cannot start or end a sequence of digits, e.g., \lstinline@_1@, \lstinline@1_@ and \lstinline@_1_@ are invalid (actually, the 1st and 3rd examples are identifier names).
267\item
268A numeric prefix may end with an underscore;
269a numeric infix may begin and/or end with an underscore;
270a numeric suffix may begin with an underscore.
271For example, the octal \lstinline@0@ or hexadecimal \lstinline@0x@ prefix may end with an underscore \lstinline@0_377@ or \lstinline@0x_ff@;
272the exponent infix \lstinline@E@ may start or end with an underscore \lstinline@1.0_E10@, \lstinline@1.0E_10@ or \lstinline@1.0_E_10@;
273the type suffixes \lstinline@U@, \lstinline@L@, etc. may start with an underscore \lstinline@1_U@, \lstinline@1_ll@ or \lstinline@1.0E10_f@.
274\end{enumerate}
275It is significantly easier to read and type long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
276This extension is backwards compatible, matches with the use of underscore in variable names, and appears in Ada and Java.
277
278
279\section{Declarations}
280\label{s:Declarations}
281
282C declaration syntax is notoriously confusing and error prone.
283For example, many C programmers are confused by a declaration as simple as:
284\begin{lstlisting}
285int *x[ 10 ]
286\end{lstlisting}
287Is this a pointer to an array of 10 integers or an array of 10 pointers to integers?
288Another 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.
289For example, a routine returning a pointer to an array of integers is defined and used in the following way:
290\begin{lstlisting}
291int (*f())[ 10 ] {...};
292... (*f())[ 3 ] += 1;           // definition mimics usage
293\end{lstlisting}
294Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
295While attempting to make the two contexts consistent was a laudable goal, it has not worked out in practice.
296
297\CFA provides its own type, variable and routine declarations, using a slightly different syntax.
298The new declarations place modifiers to the left of the base type, while C declarations place modifiers to the right of the base type.
299The only exception is bit field specification, which always appear to the right of the base type.
300C and the new \CFA declarations may appear together in the same program block, but cannot be mixed within a specific declaration.
301Unsupported are K\&R C declarations where the base type defaults to \lstinline@int@, if no type is specified\footnote{
302At 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}},
303e.g.:
304\begin{lstlisting}
305x;                                      // int x
306*y;                                     // int *y
307f( p1, p2 );            // int f( int p1, int p2 );
308f( p1, p2 ) {}          // int f( int p1, int p2 ) {}
309\end{lstlisting}
310
311In \CFA declarations, the same tokens are used as in C: the character \lstinline@*@ is used to indicate a pointer, square brackets \lstinline@[@\,\lstinline@]@ are used to represent an array, and parentheses \lstinline@()@ are used to indicate a routine parameter.
312However, unlike C, \CFA type declaration tokens are specified from left to right and the entire type specification is distributed across all variables in the declaration list.
313For instance, variables \lstinline@x@ and \lstinline@y@ of type pointer to integer are defined in \CFA as follows:
314\begin{quote2}
315\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
316\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
317\begin{lstlisting}
318`* int x, y;`
319\end{lstlisting}
320&
321\begin{lstlisting}
322int *x, *y;
323\end{lstlisting}
324\end{tabular}
325\end{quote2}
326Other examples are:
327\begin{quote2}
328\begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
329\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
330\begin{lstlisting}
331[ 10 ] int z;
332[ 10 ] * char w;
333* [ 10 ] double v;
334struct s {
335int f0:3;
336        * int f1;
337        [ 10 ] * int f2;
338};
339\end{lstlisting}
340&
341\begin{lstlisting}
342int z[ 10 ];
343char *w[ 10 ];
344double (*v)[ 10 ];
345struct s {
346        int f0:3;
347        int *f1;
348        int *f2[ 10 ]
349};
350\end{lstlisting}
351&
352\begin{lstlisting}
353// array of 10 integers
354// array of 10 pointers to char
355// pointer to array of 10 doubles
356
357// common bit field syntax
358
359
360
361\end{lstlisting}
362\end{tabular}
363\end{quote2}
364
365As stated above, the two styles of declaration may appear together in the same block.
366Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
367Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
368In general, mixing declaration styles in a routine or even a translation unit is not recommended, as it makes a program more difficult to read.
369Therefore, it is suggested that an entire translation unit be written in one declaration style or the other.
370
371All type qualifiers, i.e., \lstinline@const@ and \lstinline@volatile@, are used in the normal way with the new declarations but appear left to right, e.g.:
372\begin{quote2}
373\begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
374\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
375\begin{lstlisting}
376const * const int x;
377const * [ 10 ] const int y;
378\end{lstlisting}
379&
380\begin{lstlisting}
381int const * const x;
382const int (* const y)[ 10 ]
383\end{lstlisting}
384&
385\begin{lstlisting}
386// const pointer to const integer
387// const pointer to array of 10 const integers
388\end{lstlisting}
389\end{tabular}
390\end{quote2}
391All declaration qualifiers, i.e., \lstinline@extern@, \lstinline@static@, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
392The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} e.g.:
393\begin{quote2}
394\begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
395\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
396\begin{lstlisting}
397extern [ 10 ] int x;
398static * const int y;
399\end{lstlisting}
400&
401\begin{lstlisting}
402int extern x[ 10 ];
403const int static *y;
404\end{lstlisting}
405&
406\begin{lstlisting}
407// externally visible array of 10 integers
408// internally visible pointer to constant int
409\end{lstlisting}
410\end{tabular}
411\end{quote2}
412
413
414\section{Type Operators}
415
416The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine \lstinline@sizeof@:
417\begin{quote2}
418\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
419\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
420\begin{lstlisting}
421y = (* int)x;
422i = sizeof([ 10 ] * int);
423\end{lstlisting}
424&
425\begin{lstlisting}
426y = (int *)x;
427i = sizeof(int *[ 10 ]);
428\end{lstlisting}
429\end{tabular}
430\end{quote2}
431
432
433\section{Routine Definition}
434
435\CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
436The point of the new syntax is to allow returning multiple values from a routine~\cite{CLU,Galletly96}, e.g.:
437\begin{lstlisting}
438`[ int o1, int o2, char o3 ]` f( int i1, char i2, char i3 ) {
439        @\emph{routine body}@
440}
441\end{lstlisting}
442where routine \lstinline@f@ has three output (return values) and three input parameters.
443Existing C syntax cannot be extended with multiple return types because it is impossible to embed a single routine name within multiple return type specifications.
444
445In detail, the brackets, \lstinline@[]@, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
446Michael Tiemann, with help from Doug Lea, provided named return values in g++, circa 1989.}
447The value of each local return variable is automatically returned at routine termination.
448Declaration qualifiers can only appear at the start of a routine definition, e.g.:
449\begin{lstlisting}
450extern [ int x ] g( int y ) {}
451\end{lstlisting}
452Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
453in 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:
454\begin{lstlisting}
455[ ] g();                                        // no input or output parameters
456[ void ] g( void );                     // no input or output parameters
457\end{lstlisting}
458
459Routine f is called as follows:
460\begin{lstlisting}
461[ i, j, ch ] = f( 3, 'a', ch );
462\end{lstlisting}
463The list of return values from f and the grouping on the left-hand side of the assignment is called a tuple and discussed in Section 12.
464
465\CFA style declarations cannot be used to declare parameters for K\&R style routine definitions because of the following ambiguity:
466\begin{lstlisting}
467int (*f(x))[ 10 ] int x; {}
468\end{lstlisting}
469The string ``\lstinline@int (*f(x))[ 10 ]@'' declares a K\&R style routine of type returning a pointer to an array of 10 integers, while the string ``\lstinline@[ 10 ] int x@'' declares a \CFA style parameter x of type array of 10 integers.
470Since the strings overlap starting with the open bracket, \lstinline@[@, there is an ambiguous interpretation for the string.
471As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
472\begin{lstlisting}
473typedef int foo;
474int f( int (* foo) );           // foo is redefined as a parameter name
475\end{lstlisting}
476The string ``\lstinline@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.
477The redefinition of a type name in a parameter list is the only context in C where the character \lstinline@*@ can appear to the left of a type name, and \CFA relies on all type modifier characters appearing to the right of the type name.
478The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts.
479
480C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.:
481\begin{lstlisting}
482[ int ] f( * int, int * );      // returns an integer, accepts 2 pointers to integers
483[ * int, int * ] f( int );      // returns 2 pointers to integers, accepts an integer
484\end{lstlisting}
485The 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:
486\begin{lstlisting}
487#define ptoa( n, d ) int (*n)[ d ]
488int f( ptoa(p,10) ) ...         // expands to int f( int (*p)[ 10 ] )
489[ int ] f( ptoa(p,10) ) ...     // expands to [ int ] f( int (*p)[ 10 ] )
490\end{lstlisting}
491Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
492
493
494\subsection{Returning Values}
495
496Named return values handle the case where it is necessary to define a local variable whose value is then returned in a \lstinline@return@ statement, as in:
497\begin{lstlisting}
498int f() {
499        int x;
500        ... x = 0; ... x = y; ...
501        return x;
502}
503\end{lstlisting}
504Because the value in the return variable is automatically returned when a \CFA routine terminates, the \lstinline@return@ statement \emph{does not} contain an expression, as in:
505\begin{lstlisting}
506`[ int x ]` f() {
507        ... x = 0; ... x = y; ...
508        `return;` // implicitly return x
509}
510\end{lstlisting}
511When the return is encountered, the current value of \lstinline@x@ is returned to the calling routine.
512As well, ``falling off the end'' of a routine without a \lstinline@return@ statement is permitted, as in:
513\begin{lstlisting}
514[ int x ] f() {
515        ... x = 0; ... x = y; ...
516} // implicitly return x
517\end{lstlisting}
518In this case, the current value of \lstinline@x@ is returned to the calling routine just as if a \lstinline@return@ had been encountered.
519
520
521\subsection{Routine Prototype}
522
523The syntax of the new routine prototype declaration follows directly from the new routine definition syntax;
524as well, parameter names are optional, e.g.:
525\begin{lstlisting}
526[ int x ] f ();                         // returning int with no parameters
527[ * int ] g (int y);            // returning pointer to int with int parameter
528[ ] h (int,char);                       // returning no result with int and char parameters
529[ * int,int ] j (int);          // returning pointer to int and int, with int parameter
530\end{lstlisting}
531This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
532It 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}), e.g.:
533\begin{quote2}
534\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
535\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
536\begin{lstlisting}
537[ int ] f(int), g;
538\end{lstlisting}
539&
540\begin{lstlisting}
541int f(int), g(int);
542\end{lstlisting}
543\end{tabular}
544\end{quote2}
545Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} e.g.:
546\begin{lstlisting}
547extern [ int ] f (int);
548static [ int ] g (int);
549\end{lstlisting}
550
551
552\section{Routine Pointers}
553
554The syntax for pointers to \CFA routines specifies the pointer name on the right, e.g.:
555\begin{lstlisting}
556* [ int x ] () fp;                      // pointer to routine returning int with no parameters
557* [ * int ] (int y) gp;         // pointer to routine returning pointer to int with int parameter
558* [ ] (int,char) hp;            // pointer to routine returning no result with int and char parameters
559* [ * int,int ] (int) jp;       // pointer to routine returning pointer to int and int, with int parameter
560\end{lstlisting}
561While parameter names are optional, \emph{a routine name cannot be specified};
562for example, the following is incorrect:
563\begin{lstlisting}
564* [ int x ] f () fp;            // routine name "f" is not allowed
565\end{lstlisting}
566
567
568\section{Named and Default Arguments}
569
570Named and default arguments~\cite{Hardgrave76}.\footnote{
571Francez~\cite{Francez77} proposed a further extension to the named-parameter passing style, which specifies what type of communication (by value, by reference, by name) the argument is passed to the routine.}
572are two mechanisms to simplify routine call.
573Both mechanisms are discussed with respect to \CFA.
574\begin{description}
575\item[Named (or Keyword) Arguments:]
576provide the ability to specify an argument to a routine call using the parameter name rather than the position of the parameter.
577For example, given the routine:
578\begin{lstlisting}
579void p( int x, int y, int z ) {...}
580\end{lstlisting}
581a positional call is:
582\begin{lstlisting}
583p( 4, 7, 3 );
584\end{lstlisting}
585whereas a named (keyword) call may be:
586\begin{lstlisting}
587p( z : 3, x : 4, y : 7 ); // rewrite $\Rightarrow$ p( 4, 7, 3 )
588\end{lstlisting}
589Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
590The compiler rewrites a named call into a positional call.
591The advantages of named parameters are:
592\begin{itemize}
593\item
594Remembering the names of the parameters may be easier than the order in the routine definition.
595\item
596Parameter names provide documentation at the call site (assuming the names are descriptive).
597\item
598Changes can be made to the order or number of parameters without affecting the call (although the call must still be recompiled).
599\end{itemize}
600
601Unfortunately, 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.
602For example, the following routine prototypes and definition are all valid.
603\begin{lstlisting}
604void p( int, int, int );                        // equivalent prototypes
605void p( int x, int y, int z );
606void p( int y, int x, int z );
607void p( int z, int y, int x );
608void p( int q, int r, int s ) {}        // match with this definition
609\end{lstlisting}
610Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
611Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports.
612The former is easy to do, while the latter is more complex.
613Currently, \CFA does \emph{not} attempt to support named arguments.
614
615\item[Default Arguments]
616provide the ability to associate a default value with a parameter so it can be optionally specified in the argument list.
617For example, given the routine:
618\begin{lstlisting}
619void p( int x = 1, int y = 2, int z = 3 ) {...}
620\end{lstlisting}
621the allowable positional calls are:
622\begin{lstlisting}
623p();                            // rewrite $\Rightarrow$ p( 1, 2, 3 )
624p( 4 );                         // rewrite $\Rightarrow$ p( 4, 2, 3 )
625p( 4, 4 );                      // rewrite $\Rightarrow$ p( 4, 4, 3 )
626p( 4, 4, 4 );           // rewrite $\Rightarrow$ p( 4, 4, 4 )
627// empty arguments
628p(  , 4, 4 );           // rewrite $\Rightarrow$ p( 1, 4, 4 )
629p( 4,  , 4 );           // rewrite $\Rightarrow$ p( 4, 2, 4 )
630p( 4, 4,   );           // rewrite $\Rightarrow$ p( 4, 4, 3 )
631p( 4,  ,   );           // rewrite $\Rightarrow$ p( 4, 2, 3 )
632p(  , 4,   );           // rewrite $\Rightarrow$ p( 1, 4, 3 )
633p(  ,  , 4 );           // rewrite $\Rightarrow$ p( 1, 2, 4 )
634p(  ,  ,   );           // rewrite $\Rightarrow$ p( 1, 2, 3 )
635\end{lstlisting}
636Here the missing arguments are inserted from the default values in the parameter list.
637The compiler rewrites missing default values into explicit positional arguments.
638The advantages of default values are:
639\begin{itemize}
640\item
641Routines with a large number of parameters are often very generalized, giving a programmer a number of different options on how a computation is performed.
642For many of these kinds of routines, there are standard or default settings that work for the majority of computations.
643Without default values for parameters, a programmer is forced to specify these common values all the time, resulting in long argument lists that are error prone.
644\item
645When a routine's interface is augmented with new parameters, it extends the interface providing generalizability\footnote{
646``It should be possible for the implementor of an abstraction to increase its generality.
647So long as the modified abstraction is a generalization of the original, existing uses of the abstraction will not require change.
648It might be possible to modify an abstraction in a manner which is not a generalization without affecting existing uses, but, without inspecting the modules in which the uses occur, this possibility cannot be determined.
649This criterion precludes the addition of parameters, unless these parameters have default or inferred values that are valid for all possible existing applications.''~\cite[p.~128]{Cormack90}}
650(somewhat like the generalization provided by inheritance for classes).
651That is, all existing calls are still valid, although the call must still be recompiled.
652\end{itemize}
653The only disadvantage of default arguments is that unintentional omission of an argument may not result in a compiler-time error.
654Instead, a default value is used, which may not be the programmer's intent.
655
656Default values may only appear in a prototype versus definition context:
657\begin{lstlisting}
658void p( int x, int y = 2, int z = 3 );          // prototype: allowed
659void p( int, int = 2, int = 3 );                        // prototype: allowed
660void p( int x, int y = 2, int z = 3 ) {}        // definition: not allowed
661\end{lstlisting}
662The reason for this restriction is to allow separate compilation.
663Multiple prototypes with different default values is an error.
664\end{description}
665
666Ellipse (``...'') arguments present problems when used with default arguments.
667The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities:
668\begin{lstlisting}
669p( /* positional */, . . ., /* named */ );
670p( /* positional */, /* named */, . . . );
671\end{lstlisting}
672While it is possible to implement both approaches, the first possibly is more complex than the second, e.g.:
673\begin{lstlisting}
674p( int x, int y, int z, . . . );
675p( 1, 4, 5, 6, z : 3, y : 2 ); // assume p( /* positional */, . . ., /* named */ );
676p( 1, z : 3, y : 2, 4, 5, 6 ); // assume p( /* positional */, /* named */, . . . );
677\end{lstlisting}
678In 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.
679Hence, this approach seems significantly more difficult, and hence, confusing and error prone.
680In the second call, the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
681
682The problem is exacerbated with default arguments, e.g.:
683\begin{lstlisting}
684void p( int x, int y = 2, int z = 3. . . );
685p( 1, 4, 5, 6, z : 3 );         // assume p( /* positional */, . . ., /* named */ );
686p( 1, z : 3, 4, 5, 6 );         // assume p( /* positional */, /* named */, . . . );
687\end{lstlisting}
688The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
689therefore, argument 5 subsequently conflicts with the named argument z : 3.
690In the second call, the default value for y is implicitly inserted after argument 1 and the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
691For these reasons, \CFA requires named arguments before ellipse arguments.
692Finally, while ellipse arguments are needed for a small set of existing C routines, like printf, the extended \CFA type system largely eliminates the need for ellipse arguments (see Section 24), making much of this discussion moot.
693
694Default arguments and overloading (see Section 24) are complementary.
695While in theory default arguments can be simulated with overloading, as in:
696\begin{quote2}
697\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
698\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{default arguments}}  & \multicolumn{1}{c}{\textbf{overloading}}      \\
699\begin{lstlisting}
700void p( int x, int y = 2, int z = 3 ) {...}
701
702
703\end{lstlisting}
704&
705\begin{lstlisting}
706void p( int x, int y, int z ) {...}
707void p( int x ) { p( x, 2, 3 ); }
708void p( int x, int y ) { p( x, y, 3 ); }
709\end{lstlisting}
710\end{tabular}
711\end{quote2}
712the number of required overloaded routines is linear in the number of default values, which is unacceptable growth.
713In general, overloading should only be used over default arguments if the body of the routine is significantly different.
714Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
715\begin{lstlisting}
716p( 1, /* default */, 5 );               // rewrite $\Rightarrow$ p( 1, 2, 5 )
717\end{lstlisting}
718
719Given the \CFA restrictions above, both named and default arguments are backwards compatible.
720\CC only supports default arguments;
721Ada supports both named and default arguments.
722
723
724\section{Type/Routine Nesting}
725
726Nesting of types and routines is useful for controlling name visibility (\newterm{name hiding}).
727
728
729\subsection{Type Nesting}
730
731\CFA allows \Index{type nesting}, and type qualification of the nested types, where as C hoists\index{type!hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
732\begin{quote2}
733\begin{tabular}{@{}l@{\hspace{30pt}}l|l@{}}
734\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{C Type Nesting}}     & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
735\hline
736\begin{lstlisting}
737struct S {
738        enum C { R, G, B };
739        struct T {
740                union U { int i, j; };
741                enum C c;
742                short int i, j;
743        };
744        struct T t;
745} s;
746
747int fred() {
748        s.t.c = R;
749        struct T t = { R, 1, 2 };
750        enum C c;
751        union U u;
752}
753\end{lstlisting}
754&
755\begin{lstlisting}
756enum C { R, G, B };
757union U { int i, j; };
758struct T {
759        enum C c;
760        short int i, j;
761};
762struct S {
763        struct T t;
764} s;
765       
766
767
768
769
770
771
772\end{lstlisting}
773&
774\begin{lstlisting}
775struct S {
776        enum C { R, G, B };
777        struct T {
778                union U { int i, j; };
779                enum C c;
780                short int i, j;
781        };
782        struct T t;
783} s;
784
785int fred() {
786        s.t.c = `S.`R;  // type qualification
787        struct `S.`T t = { `S.`R, 1, 2 };
788        enum `S.`C c;
789        union `S.T.`U u;
790}
791\end{lstlisting}
792\end{tabular}
793\end{quote2}
794In the left example in C, types \lstinline@C@, \lstinline@U@ and \lstinline@T@ are implicitly hoisted outside of type \lstinline@S@ into the containing block scope.
795In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``\lstinline@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``\lstinline@::@''.
796
797
798\subsection{Routine Nesting}
799
800While \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.
801For example, the C quick-sort is wrapped into the following polymorphic \CFA routine:
802\begin{lstlisting}
803forall( otype T | { int ?<?( T, T ); } )
804void qsort( const T * arr, size_t dimension );
805\end{lstlisting}
806which can be used to sort in ascending and descending order by locally redefining the less-than operator into greater-than.
807\begin{lstlisting}
808const unsigned int size = 10;
809int ia[size];
810...                                             // assign values to array ia
811qsort( ia, size );              // sort ascending order using builtin ?<?
812{
813        `int ?<?( int x, int y ) { return x > y; }` // nested routine
814        qsort( ia, size );      // sort descending order by local redefinition
815}
816\end{lstlisting}
817
818Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks;
819the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program.
820The following program in undefined in \CFA (and \lstinline@gcc@\index{gcc})
821\begin{lstlisting}
822[* [int]( int )] foo() {                // int (*foo())( int )
823        int `i` = 7;
824        int bar( int p ) {
825                `i` += 1;                                       // dependent on local variable
826                sout | `i` | endl;
827        }
828        return bar;                                     // undefined because of local dependence
829}
830int main() {
831        * [int](int) fp = foo();        // int (*fp)(int)
832    sout | fp( 3 ) | endl;
833}
834\end{lstlisting}
835because
836
837Currently, there are no \Index{lambda} expressions, i.e., unnamed routines because routine names are very important to properly select the correct routine.
838
839
840\section{Incompatible}
841
842The following incompatibles exist between C and \CFA, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
843
844\begin{enumerate}
845\item
846Change type of character literal \lstinline@int@ to \lstinline@char@.
847This change allows overloading differentiation argument type matching, e.g.:
848\begin{lstlisting}
849int function( int i );
850int function( char c );
851function( 'x' );
852\end{lstlisting}
853It is preferable that this call match the second version of function rather than the first. \\
854Effect on original feature: Change to semantics of well-defined feature. ISO C programs which depend on
855\begin{lstlisting}
856sizeof('x') == sizeof(int)
857\end{lstlisting}
858will not work the same as C++ programs. \\
859Difficulty of converting: Simple. \\
860How widely used: Programs which depend upon sizeof('x') are probably rare.
861
862\item
863Change: String literals made \lstinline@const@ \\
864The type of a string literal is changed from \lstinline@array of char@ to \lstinline@array of const char@.
865The type of a wide string literal is changed from \lstinline@array of wchar_t@ to \lstinline@array of const wchar_t@. \\
866Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
867Effect on original feature: Change to semantics of well-defined feature. \\
868Difficulty of converting: Simple syntactic transformation, because string literals can be converted to \lstinline@char*;@ (4.2).
869The most common cases are handled by a new but deprecated standard conversion:
870\begin{lstlisting}
871char* p = "abc"; // valid in C, deprecated in C++
872char* q = expr ? "abc" : "de"; // valid in C, invalid in C++
873\end{lstlisting}
874How widely used: Programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are probably rare.
875
876\item
877Change: C++ does not have \emph{tentative definitions} as in C.
878E.g., at file scope,
879\begin{lstlisting}
880int i;
881int i;
882\end{lstlisting}
883is valid in C, invalid in C++.
884This makes it impossible to define mutually referential file-local static
885objects, if initializers are restricted to the syntactic forms of C. For example,
886\begin{lstlisting}
887struct X { int i; struct X *next; };
888static struct X a;
889static struct X b = { 0, &a };
890static struct X a = { 1, &b };
891\end{lstlisting}
892Rationale: This avoids having different initialization rules for builtin types and userdefined types.
893Effect on original feature: Deletion of semantically welldefined feature. \\
894Difficulty of converting: Semantic transformation.
895In C++, the initializer for one of a set of mutuallyreferential filelocal static objects must invoke a function call to achieve the initialization.
896How widely used: Seldom.
897
898\item
899Change: A struct is a scope in C++, not in C \\
900Rationale: Class scope is crucial to C++, and a struct is a class. \\
901Effect on original feature: Change to semantics of well-defined feature. \\
902Difficulty of converting: Semantic transformation. \\
903How widely used: C programs use struct extremely frequently, but the change is only noticeable when struct, enumeration, or enumerator names are referred to outside the struct.
904The latter is probably rare.
905
906\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
907Nested types are not hoisted and can be referenced using the field selection operator ``\lstinline@.@'', unlike the \CC scope-resolution operator ``\lstinline@::@''.
908Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
909
910
911\item
912Change: In C++, the name of a nested class is local to its enclosing class.
913In C the name of the nested class belongs to the same scope as the name of the outermost enclosing class
914Example:
915\begin{lstlisting}
916struct X {
917struct Y { /* ... */ } y;
918};
919struct Y yy; // valid C, invalid C++
920\end{lstlisting}
921Rationale: C++ classes have member functions which require that classes establish scopes. The C rule
922would leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining
923locality within a class. A coherent set of scope rules for C++ based on the C rule would be very
924complicated and C++ programmers would be unable to predict reliably the meanings of nontrivial examples
925involving nested or local functions.
926Effect on original feature: Change of semantics of welldefined
927feature.
928Difficulty of converting: Semantic transformation. To make the struct type name visible in the scope of
929the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing
930struct is defined. Example:
931\begin{lstlisting}
932struct Y; // struct Y and struct X are at the same scope
933struct X {
934struct Y { /* ... */ } y;
935};
936\end{lstlisting}
937All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of
938the enclosing struct could be exported to the scope of the enclosing struct. Note: this is a consequence of
939the difference in scope rules, which is documented in 3.3.
940How widely used: Seldom.
941\end{enumerate}
942
943
944\section{Tuples}
945
946In C and \CFA, lists of elements appear in several contexts, such as the parameter list for a routine call.
947(More contexts are added shortly.)
948A list of such elements is called a tuple.
949The general syntax of a tuple is:
950\begin{lstlisting}
951[ $\emph{exprlist}$ ]
952\end{lstlisting}
953where \lstinline@$\emph{exprlist}$@ is a list of one or more expressions separated by commas.
954The brackets, \lstinline$[]$, allow differentiating between tuples and expressions containing the C comma operator.
955The following are examples of tuples:
956\begin{lstlisting}
957[ x, y, z ]
958[ 2 ]
959[ v+w, x*y, 3.14159, f() ]
960\end{lstlisting}
961Tuples are permitted to contain sub-tuples (i.e., nesting), such as \lstinline@[ [ 14, 21 ], 9 ]@, which is a 2-element tuple whose first element is itself a tuple.
962Note, a tuple is not a record (structure);
963a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1).
964In essence, tuples are largely a compile time phenomenon, having little or no runtime presence.
965
966Tuples can be organized into compile-time tuple variables;
967these variables are of \newterm{tuple type}.
968Tuple variables and types can be used anywhere lists of conventional variables and types can be used.
969The general syntax of a tuple type is:
970\begin{lstlisting}
971[ @\emph{typelist}@ ]
972\end{lstlisting}
973where \lstinline@$\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.
974Examples of tuple types include:
975\begin{lstlisting}
976[ unsigned int, char ]
977[ double, double, double ]
978[ * int, int * ]                // mix of CFA and ANSI
979[ * [ 10 ] int, * * char, * [ [ int, int ] ] (int, int) ]
980\end{lstlisting}
981Like tuples, tuple types may be nested, such as \lstinline@[ [ int, int ], int ]@, which is a 2-element tuple type whose first element is itself a tuple type.
982
983Examples of declarations using tuple types are:
984\begin{lstlisting}
985[ int, int ] x;                 // 2 element tuple, each element of type int
986* [ char, char ] y;             // pointer to a 2 element tuple
987[ [ int, int ] ] z ([ int, int ]);
988\end{lstlisting}
989The 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.
990
991As mentioned, tuples can appear in contexts requiring a list of value, such as an argument list of a routine call.
992In unambiguous situations, the tuple brackets may be omitted, e.g., a tuple that appears as an argument may have its
993square brackets omitted for convenience; therefore, the following routine invocations are equivalent:
994\begin{lstlisting}
995f( [ 1, x+2, fred() ] );
996f( 1, x+2, fred() );
997\end{lstlisting}
998Also, 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.
999For example, the following are all legal:
1000\begin{lstlisting}
1001[ int, int ] w1;
1002[ int, int, int ] w2;
1003[ void ] f (int, int, int); /* three input parameters of type int */
1004[ void ] g ([ int, int, int ]); /* 3 element tuple as input */
1005f( [ 1, 2, 3 ] );
1006f( w1, 3 );
1007f( 1, w1 );
1008f( w2 );
1009g( [ 1, 2, 3 ] );
1010g( w1, 3 );
1011g( 1, w1 );
1012g( w2 );
1013\end{lstlisting}
1014Note, in all cases 3 arguments are supplied even though the syntax may appear to supply less than 3. As mentioned, a
1015tuple does not have structure like a record; a tuple is simply converted into a list of components.
1016\begin{rationale}
1017The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as \lstinline@g( f() )@ is not supported.
1018Using a temporary variable to store the  results of the inner routine and then passing this variable to the outer routine works, however.
1019\end{rationale}
1020
1021A tuple can contain a C comma expression, provided the expression containing the comma operator is enclosed in parentheses.
1022For instance, the following tuples are equivalent:
1023\begin{lstlisting}
1024[ 1, 3, 5 ]
1025[ 1, (2, 3), 5 ]
1026\end{lstlisting}
1027The second element of the second tuple is the expression (2, 3), which yields the result 3.
1028This requirement is the same as for comma expressions in argument lists.
1029
1030Type qualifiers, i.e., const and volatile, may modify a tuple type.
1031The 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, e.g.:
1032\begin{lstlisting}
1033const volatile [ int, float, const int ] x;
1034\end{lstlisting}
1035is equivalent to:
1036\begin{lstlisting}
1037[ const volatile int, const volatile float, const volatile int ] x;
1038\end{lstlisting}
1039Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, e.g.:
1040\begin{lstlisting}
1041extern [ int, int ] w1;
1042static [ int, int, int ] w2;
1043\end{lstlisting}
1044\begin{rationale}
1045Unfortunately, C's syntax for subscripts precluded treating them as tuples.
1046The C subscript list has the form \lstinline@[i][j]...@ and not \lstinline@i, j, ...]@.
1047Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., \lstinline@f[g()]@ always means a single subscript value because there is only one set of brackets.
1048Fixing this requires a major change to C because the syntactic form \lstinline@M[i, j, k]@ already has a particular meaning: \lstinline@i, j, k@ is a comma expression.
1049\end{rationale}
1050
1051
1052\subsection{Tuple Coercions}
1053
1054There are four coercions that can be performed on tuples and tuple variables: closing, opening, flattening and structuring.
1055In addition, the coercion of dereferencing can be performed on a tuple variable to yield its value(s), as for other variables.
1056A \newterm{closing coercion} takes a set of values and converts it into a tuple value, which is a contiguous set of values, as in:
1057\begin{lstlisting}
1058[ int, int, int, int ] w;
1059w = [ 1, 2, 3, 4 ];
1060\end{lstlisting}
1061First the right-hand tuple is closed into a tuple value and then the tuple value is assigned.
1062
1063An \newterm{opening coercion} is the opposite of closing; a tuple value is converted into a tuple of values, as in:
1064\begin{lstlisting}
1065[ a, b, c, d ] = w
1066\end{lstlisting}
1067\lstinline@w@ is implicitly opened to yield a tuple of four values, which are then assigned individually.
1068
1069A \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:
1070\begin{lstlisting}
1071[ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ];
1072\end{lstlisting}
1073First the right-hand tuple is flattened and then the values are assigned individually.
1074Flattening is also performed on tuple types.
1075For example, the type \lstinline@[ int, [ int, int ], int ]@ can be coerced, using flattening, into the type \lstinline@[ int, int, int, int ]@.
1076
1077A \newterm{structuring coercion} is the opposite of flattening;
1078a tuple is structured into a more complex nested tuple.
1079For example, structuring the tuple \lstinline@[ 1, 2, 3, 4 ]@ into the tuple \lstinline@[ 1, [ 2, 3 ], 4 ]@ or the tuple type \lstinline@[ int, int, int, int ]@ into the tuple type \lstinline@[ int, [ int, int ], int ]@.
1080In the following example, the last assignment illustrates all the tuple coercions:
1081\begin{lstlisting}
1082[ int, int, int, int ] w = [ 1, 2, 3, 4 ];
1083int x = 5;
1084[ x, w ] = [ w, x ];            // all four tuple coercions
1085\end{lstlisting}
1086Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
1087therefore, the right-hand tuple is now the tuple \lstinline@[ [ 1, 2, 3, 4 ], 5 ]@.
1088This tuple is then flattened, yielding \lstinline@[ 1, 2, 3, 4, 5 ]@, which is structured into \lstinline@[ 1, [ 2, 3, 4, 5 ] ]@ to match the tuple type of the left-hand side.
1089The tuple \lstinline@[ 2, 3, 4, 5 ]@ is then closed to create a tuple value.
1090Finally, \lstinline@x@ is assigned \lstinline@1@ and \lstinline@w@ is assigned the tuple value using multiple assignment (see Section 14).
1091\begin{rationale}
1092A possible additional language extension is to use the structuring coercion for tuples to initialize a complex record with a tuple.
1093\end{rationale}
1094
1095
1096\section{Mass Assignment}
1097
1098\CFA permits assignment to several variables at once using mass assignment~\cite{CLU}.
1099Mass assignment has the following form:
1100\begin{lstlisting}
1101[ @\emph{lvalue}@, ..., @\emph{lvalue}@ ] = @\emph{expr}@;
1102\end{lstlisting}
1103The left-hand side is a tuple of \lstinline@$\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.
1104\lstinline@$\emph{expr}$@ is any standard arithmetic expression.
1105Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
1106
1107Mass assignment has parallel semantics, e.g., the statement:
1108\begin{lstlisting}
1109[ x, y, z ] = 1.5;
1110\end{lstlisting}
1111is equivalent to:
1112\begin{lstlisting}
1113x = 1.5; y = 1.5; z = 1.5;
1114\end{lstlisting}
1115This semantics is not the same as the following in C:
1116\begin{lstlisting}
1117x = y = z = 1.5;
1118\end{lstlisting}
1119as conversions between intermediate assignments may lose information.
1120A more complex example is:
1121\begin{lstlisting}
1122[ i, y[i], z ] = a + b;
1123\end{lstlisting}
1124which is equivalent to:
1125\begin{lstlisting}
1126t = a + b;
1127a1 = &i; a2 = &y[i]; a3 = &z;
1128*a1 = t; *a2 = t; *a3 = t;
1129\end{lstlisting}
1130The temporary \lstinline@t@ is necessary to store the value of the expression to eliminate conversion issues.
1131The temporaries for the addresses are needed so that locations on the left-hand side do not change as the values are assigned.
1132In this case, \lstinline@y[i]@ uses the previous value of \lstinline@i@ and not the new value set at the beginning of the mass assignment.
1133
1134
1135\section{Multiple Assignment}
1136
1137\CFA also supports the assignment of several values at once, known as multiple assignment~\cite{CLU,Galletly96}.
1138Multiple assignment has the following form:
1139\begin{lstlisting}
1140[ @\emph{lvalue}@, . . ., @\emph{lvalue}@ ] = [ @\emph{expr}@, . . ., @\emph{expr}@ ];
1141\end{lstlisting}
1142The left-hand side is a tuple of \lstinline@$\emph{lvalues}$@, and the right-hand side is a tuple of \lstinline@$\emph{expr}$@s.
1143Each \lstinline@$\emph{expr}$@ appearing on the righthand side of a multiple assignment statement is assigned to the corresponding \lstinline@$\emph{lvalues}$@ on the left-hand side of the statement using parallel semantics for each assignment.
1144An example of multiple assignment is:
1145\begin{lstlisting}
1146[ x, y, z ] = [ 1, 2, 3 ];
1147\end{lstlisting}
1148Here, the values \lstinline@1@, \lstinline@2@ and \lstinline@3@ are assigned, respectively, to the variables \lstinline@x@, \lstinline@y@ and \lstinline@z@.
1149 A more complex example is:
1150\begin{lstlisting}
1151[ i, y[ i ], z ] = [ 1, i, a + b ];
1152\end{lstlisting}
1153Here, the values \lstinline@1@, \lstinline@i@ and \lstinline@a + b@ are assigned to the variables \lstinline@i@, \lstinline@y[i]@ and \lstinline@z@, respectively.
1154 Note, the parallel semantics of
1155multiple assignment ensures:
1156\begin{lstlisting}
1157[ x, y ] = [ y, x ];
1158\end{lstlisting}
1159correctly interchanges (swaps) the values stored in \lstinline@x@ and \lstinline@y@.
1160The following cases are errors:
1161\begin{lstlisting}
1162[ a, b, c ] = [ 1, 2, 3, 4 ];
1163[ a, b, c ] = [ 1, 2 ];
1164\end{lstlisting}
1165because the number of entities in the left-hand tuple is unequal with the right-hand tuple.
1166
1167As 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;
1168both these examples produce indeterminate results:
1169\begin{lstlisting}
1170f( x++, x++ );                          // C routine call with side effects in arguments
1171[ v1, v2 ] = [ x++, x++ ];      // side effects in righthand side of multiple assignment
1172\end{lstlisting}
1173
1174
1175\section{Cascade Assignment}
1176
1177As in C, \CFA mass and multiple assignments can be cascaded, producing cascade assignment.
1178Cascade assignment has the following form:
1179\begin{lstlisting}
1180@\emph{tuple}@ = @\emph{tuple}@ = ... = @\emph{tuple}@;
1181\end{lstlisting}
1182and it has the same parallel semantics as for mass and multiple assignment.
1183Some examples of cascade assignment are:
1184\begin{lstlisting}
1185x1 = y1 = x2 = y2 = 0;
1186[ x1, y1 ] = [ x2, y2 ] = [ x3, y3 ];
1187[ x1, y1 ] = [ x2, y2 ] = 0;
1188[ x1, y1 ] = z = 0;
1189\end{lstlisting}
1190As in C, the rightmost assignment is performed first, i.e., assignment parses right to left.
1191
1192
1193\section{Field Tuples}
1194
1195Tuples may be used to select multiple fields of a record by field name.
1196Its general form is:
1197\begin{lstlisting}
1198@\emph{expr}@ . [ @\emph{fieldlist}@ ]
1199@\emph{expr}@ -> [ @\emph{fieldlist}@ ]
1200\end{lstlisting}
1201\lstinline@$\emph{expr}$@ is any expression yielding a value of type record, e.g., \lstinline@struct@, \lstinline@union@.
1202Each element of \lstinline@$\emph{ fieldlist}$@ is an element of the record specified by \lstinline@$\emph{expr}$@.
1203A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
1204the following:
1205\begin{lstlisting}
1206struct s {
1207        int f1, f2;
1208        char f3;
1209        double f4;
1210} v;
1211v.[ f3, f1, f2 ] = ['x', 11, 17 ];      // equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17
1212f( v.[ f3, f1, f2 ] );                          // equivalent to f( v.f3, v.f1, v.f2 )
1213\end{lstlisting}
1214Note, the fields appearing in a record-field tuple may be specified in any order;
1215also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple.
1216
1217If a field of a \lstinline@struct@ is itself another \lstinline@struct@, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
1218\begin{lstlisting}
1219struct inner {
1220        int f2, f3;
1221};
1222struct outer {
1223        int f1;
1224        struct inner i;
1225        double f4;
1226} o;
1227
1228o.[ f1, i.[ f2, f3 ], f4 ] = [ 11, 12, 13, 3.14159 ];
1229\end{lstlisting}
1230
1231
1232\section{Labelled Break/Continue}
1233
1234While C provides \lstinline@break@ and \lstinline@continue@ statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
1235Unfortunately, this restriction forces programmers to use \lstinline@goto@ to achieve the equivalent for more than one level of nesting.
1236To prevent having to make this switch, the \lstinline@break@ and \lstinline@continue@ are extended with a target label to support static multi-level exit~\cite{Buhr85,Java}.
1237For the labelled \lstinline@break@, it is possible to specify which control structure is the target for exit, as in:
1238\begin{quote2}
1239\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
1240\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
1241\begin{lstlisting}
1242`L1:` for ( ... ) {
1243        `L2:` for ( ... ) {
1244                `L3:` for ( ... ) {
1245                        ... break `L1`; ...
1246                        ... break `L2`; ...
1247                        ... break `L3`; // or break
1248                }
1249        }
1250}
1251\end{lstlisting}
1252&
1253\begin{lstlisting}
1254for ( ... ) {
1255        for ( ... ) {
1256                for ( ... ) {
1257                        ... goto L1; ...
1258                        ... goto L2; ...
1259                        ... goto L3; // or break
1260                } L3: ;
1261        } L2: ;
1262} L1: ;
1263\end{lstlisting}
1264\end{tabular}
1265\end{quote2}
1266The inner most loop has three exit points, which cause termination of one or more of the three nested loops, respectively.
1267For the labelled \lstinline@continue@, it is possible to specify which control structure is the target for the next loop iteration, as in:
1268\begin{quote2}
1269\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
1270\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
1271\begin{lstlisting}
1272`L1`: for ( ... ) {
1273        `L2`: for ( ... ) {
1274                `L3`: for ( ... ) {
1275                        ... continue `L1`; ...
1276                        ... continue `L2`; ...
1277                        ... continue `L3`; ...
1278
1279                }
1280
1281        }
1282
1283}
1284\end{lstlisting}
1285&
1286\begin{lstlisting}
1287for ( ... ) {
1288        for ( ... ) {
1289                for ( ... ) {
1290                        ... goto L1; ...
1291                        ... goto L2; ...
1292                        ... goto L3; ...
1293                  L3: ;
1294                }
1295          L2: ;
1296        }
1297  L1: ;
1298}
1299\end{lstlisting}
1300\end{tabular}
1301\end{quote2}
1302The inner most loop has three restart points, which cause the next loop iteration to begin, respectively.
1303For both \lstinline@break@ and \lstinline@continue@, the target label must be directly associated with a \lstinline@for@, \lstinline@while@ or \lstinline@do@ statement;
1304for \lstinline@break@, the target label can also be associated with a \lstinline@switch@ statement.
1305Both \lstinline@break@ and \lstinline@continue@ with target labels are simply a \lstinline@goto@ restricted in the following ways:
1306\begin{itemize}
1307\item
1308They cannot be used to create a loop.
1309This means that only the looping construct can be used to create a loop.
1310This restriction is important since all situations that can result in repeated execution of statements in a program are clearly delineated.
1311\item
1312Since they always transfers out of containing control structures, they cannot be used to branch into a control structure.
1313\end{itemize}
1314The advantage of the labelled \lstinline@break@/\lstinline@continue@ is that it allows static multi-level exits without having to use the \lstinline@goto@ statement and ties control flow to the target control structure rather than an arbitrary point in a program.
1315Furthermore, the location of the label at the beginning of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
1316With \lstinline@goto@, the label at the end of the control structure fails to convey this important clue early enough to the reader.
1317Finally, using an explicit target for the transfer instead of an implicit target allows new nested loop or switch constructs to be added or removed without affecting other constructs.
1318The implicit targets of the current \lstinline@break@ and \lstinline@continue@, i.e., the closest enclosing loop or \lstinline@switch@, change as certain constructs are added or removed.
1319
1320
1321\section{Switch Statement}
1322
1323C allows a number of questionable forms for the \lstinline@switch@ statement:
1324\begin{enumerate}
1325\item
1326By default, the end of a \lstinline@case@ clause\footnote{
1327In this section, the term \emph{case clause} refers to either a \lstinline@case@ or \lstinline@default@ clause.}
1328\emph{falls through} to the next \lstinline@case@ clause in the \lstinline@switch@ statement;
1329to exit a \lstinline@switch@ statement from a \lstinline@case@ clause requires explicitly terminating the clause with a transfer statement, most commonly \lstinline@break@, as in:
1330\begin{lstlisting}
1331switch ( i ) {
1332  case 1:
1333        ...
1334        // fall-through
1335  case 2:
1336        ...
1337        break;  // exit switch statement
1338}
1339\end{lstlisting}
1340The ability to fall-through to the next clause is a useful form of control flow, specifically when a sequence of case actions compound, as in:
1341\begin{lstlisting}
1342switch ( argc ) {
1343  case 3:
1344        // open output file
1345        // fall-through
1346  case 2:
1347        // open input file
1348        break;  // exit switch statement
1349  default:
1350        // usage message
1351}
1352\end{lstlisting}
1353In this example, case 2 is always done if case 3 is done.
1354This control flow is difficult to simulate with if statements or a \lstinline@switch@ statement without fall-through as code must be duplicated or placed in a separate routine.
1355C also uses fall-through to handle multiple case-values resulting in the same action, as in:
1356\begin{lstlisting}
1357switch ( i ) {
1358  case 1: case 3: case 5:       // odd values
1359        // same action
1360        break;
1361  case 2: case 4: case 6:       // even values
1362        // same action
1363        break;
1364}
1365\end{lstlisting}
1366However, this situation is handled in other languages without fall-through by allowing a list of case values.
1367While fall-through itself is not a problem, the problem occurs when fall-through is the \lstinline@default@, as this semantics is not intuitive to most programmers and is different from virtually all other programming languages with a \lstinline@switch@ statement.
1368Hence, \lstinline@default@ fall-through semantics results in a large number of programming errors as programmers often forget the \lstinline@break@ statement at the end of a \lstinline@case@ clause, resulting in inadvertent fall-through.
1369
1370\item
1371It is possible to place \lstinline@case@ clauses on statements nested \emph{within} the body of the \lstinline@switch@ statement, as in:
1372\begin{lstlisting}
1373switch ( i ) {
1374  case 0:
1375        if ( j < k ) {
1376                ...
1377          case 1:               // transfer into "if" statement
1378                if ( j < m ) {
1379                        ...
1380                  case 2:       // transfer into "if" statement
1381                        ...
1382                }
1383        }
1384  case 3:
1385        while ( j < 5 ) {
1386                ...
1387          case 4:               // transfer into "while" statement
1388                ...
1389        }
1390}
1391\end{lstlisting}
1392The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
1393The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
1394The technical problem results from the inability to ensure allocation and initialization of variables when blocks are not entered at the beginning.
1395Often transferring into a block can bypass variable declaration and/or its initialization, which results in subsequent errors.
1396There are virtually no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
1397Nevertheless, C does have an idiom where this capability is used, known as ``Duff's device''~\cite{Duff83}:
1398\begin{lstlisting}
1399register int n = (count + 7) / 8;
1400switch ( count % 8 ) {
1401case 0: do{ *to = *from++;
1402case 7:         *to = *from++;
1403case 6:         *to = *from++;
1404case 5:         *to = *from++;
1405case 4:         *to = *from++;
1406case 3:         *to = *from++;
1407case 2:         *to = *from++;
1408case 1:         *to = *from++;
1409                } while ( --n > 0 );
1410}
1411\end{lstlisting}
1412which unrolls a loop N times (N = 8 above) and uses the \lstinline@switch@ statement to deal with any iterations not a multiple of N.
1413While efficient, this sort of special purpose usage is questionable:
1414\begin{quote}
1415Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
1416discovery.~\cite{Duff83}
1417\end{quote}
1418\item
1419It is possible to place the \lstinline@default@ clause anywhere in the list of labelled clauses for a \lstinline@switch@ statement, rather than only at the end.
1420Virtually all programming languages with a \lstinline@switch@ statement require the \lstinline@default@ clause to appear last in the case-clause list.
1421The logic for this semantics is that after checking all the \lstinline@case@ clauses without success, the \lstinline@default@ clause is selected;
1422hence, physically placing the \lstinline@default@ clause at the end of the \lstinline@case@ clause list matches with this semantics.
1423This physical placement can be compared to the physical placement of an \lstinline@else@ clause at the end of a series of connected \lstinline@if@/\lstinline@else@ statements.
1424
1425\item
1426It is possible to place unreachable code at the start of a \lstinline@switch@ statement, as in:
1427\begin{lstlisting}
1428switch ( x ) {
1429        int y = 1;                      // unreachable initialization
1430        x = 7;                          // unreachable code
1431  case 3: ...
1432        y = 3;
1433        ...
1434}
1435\end{lstlisting}
1436While the declaration of the local variable \lstinline@y@ is useful and its scope is across all \lstinline@case@ clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
1437Furthermore, any statements before the first \lstinline@case@ clause can only be executed if labelled and transfered to using a \lstinline@goto@, either from outside or inside of the \lstinline@switch@.
1438As mentioned, transfer into control structures should be forbidden.
1439Transfers from within the \lstinline@switch@ body using a \lstinline@goto@ are equally unpalatable.
1440\end{enumerate}
1441Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
1442\begin{itemize}
1443\item
1444the number of \lstinline@switch@ statements is small,
1445\item
1446most \lstinline@switch@ statements are well formed (i.e., no Duff's device),
1447\item
1448the \lstinline@default@ clause is usually written as the last case-clause,
1449\item
1450and there is only a medium amount of fall-through from one \lstinline@case@ clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
1451\end{itemize}
1452These observations should help to put the effects of suggested changes into perspective.
1453% Figure 1 shows the grammar change that attempts to minimize the effect on existing C programs.
1454\begin{enumerate}
1455\item
1456Eliminating the \lstinline@default@ fall-through problem has the greatest potential for affecting existing code.
1457However, even if fall-through is removed, most \lstinline@switch@ statements would continue to work because of the explicit transfers already present at the end of each \lstinline@case@ clause, and the common placement of the \lstinline@default@ clause at the end of the case list.
1458In addition, the above grammar provides for the most common use of fall-through, i.e., a list of \lstinline@case@ clauses executing common code, e.g.:
1459\begin{lstlisting}
1460case 1:  case 2:  case 3: ...
1461\end{lstlisting}
1462Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
1463Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of \lstinline@switch@ statement, called \lstinline@choose@, with no fall-through semantics.
1464The \lstinline@choose@ statement is identical to the new \lstinline@switch@ statement, except there is no implicit fall-through between case-clauses and the \lstinline@break@ statement applies to the enclosing loop construct (as for the continue statement in a \lstinline@switch@ statement).
1465It is still possible to fall-through if a case-clause ends with the new keyword fallthru, e.g.:
1466\begin{lstlisting}
1467choose ( i ) {
1468        int i;
1469  case 3, 4:
1470        i = 3;
1471        fallthru;
1472  case 8, 10:
1473  default:
1474        j = 3;
1475}
1476\end{lstlisting}
1477The ability to fall-through is retained because it is a sufficient C-idiom that most C programmers simply expect it, and its absence might discourage these programmers from using the choose statement.
1478\item
1479Eliminating Duff's device is straightforward and only invalidates a small amount of very questionable code.
1480The solution is to allow \lstinline@case@ clauses to only appear at the same nesting level as the \lstinline@switch@ body, as is done in most other programming languages with \lstinline@switch@ statements.
1481\item
1482The issue of \lstinline@default@ at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the \lstinline@default@ clause may appear is locations other than at the end.
1483Therefore, no language change is made for this issue.
1484\item
1485Dealing with unreachable code at the start of a \lstinline@switch@ statement is solved by defining the declaration-list, including any associated initialization, at the start of a \lstinline@switch@ statement body to be executed before the transfer to the appropriate \lstinline@case@ clause.
1486This semantics is the same as for declarations at the start of a loop body, which are executed before each iteration of the loop body.
1487As well, this grammar does not allow statements to appear before the first \lstinline@case@ clause.
1488The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred.
1489The change is incompatible for statements, but any existing code using it is highly questionable, as in:
1490\begin{lstlisting}
1491switch ( i ) {
1492        L: x = 5;               // questionable code
1493  case 0:
1494        ...
1495}
1496\end{lstlisting}
1497The statement after the \lstinline@switch@ can never be executed unless it is labelled.
1498If it is labelled, it must be transfered to from outside or inside the \lstinline@switch@ statement, neither of which is acceptable control flow.
1499\end{enumerate}
1500
1501
1502\section{Case Clause}
1503
1504C restricts the \lstinline@case@ clause of a \lstinline@switch@ statement to a single value.
1505For multiple \lstinline@case@ clauses associated with the same statement, it is necessary to have multiple \lstinline@case@ clauses rather than multiple values.
1506Requiring a \lstinline@case@ clause for each value does not seem to be in the spirit of brevity normally associated with C.
1507Therefore, the \lstinline@case@ clause is extended with a list of values, as in:
1508\begin{quote2}
1509\begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
1510\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
1511\begin{lstlisting}
1512switch ( i ) {
1513  `case 1, 3, 5`:
1514        ...
1515  `case 2, 4, 6`:
1516        ...
1517}
1518\end{lstlisting}
1519&
1520\begin{lstlisting}
1521switch ( i ) {
1522  case 1: case 3 : case 5:
1523        ...
1524  case 2: case 4 : case 6:
1525        ...
1526}
1527\end{lstlisting}
1528&
1529\begin{lstlisting}
1530
1531// odd values
1532
1533// even values
1534
1535
1536\end{lstlisting}
1537\end{tabular}
1538\end{quote2}
1539In addition, two forms of subranges are allowed to specify case values: the GNU C form and a new \CFA form.
1540\begin{quote2}
1541\begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
1542\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{GNU C}}    \\
1543\begin{lstlisting}
1544switch ( i ) {
1545  `case 1~5:`
1546        ...
1547  `case 10~15:`
1548        ...
1549}
1550\end{lstlisting}
1551&
1552\begin{lstlisting}
1553switch ( i )
1554  case 1 ... 5:
1555        ...
1556  case 10 ... 15:
1557        ...
1558}
1559\end{lstlisting}
1560&
1561\begin{lstlisting}
1562
1563// 1, 2, 3, 4, 5
1564
1565// 10, 11, 12, 13, 14, 15
1566
1567
1568\end{lstlisting}
1569\end{tabular}
1570\end{quote2}
1571
1572
1573\section{Unnamed Structure Fields}
1574
1575C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.:
1576\begin{lstlisting}
1577struct {
1578        int f1;                 // named field
1579        int f2 : 4;             // named field with bit field size
1580        int : 3;                // unnamed field for basic type with bit field size
1581        int ;                   // disallowed, unnamed field
1582        int *;                  // disallowed, unnamed field
1583        int (*)(int);   // disallowed, unnamed field
1584};
1585\end{lstlisting}
1586This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
1587As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
1588A list of unnamed fields is also supported, e.g.:
1589\begin{lstlisting}
1590struct {
1591        int , , ;               // 3 unnamed fields
1592}
1593\end{lstlisting}
1594
1595
1596\section{Exception Handling}
1597
1598Exception handling provides two mechanim: change of control flow from a raise to a handler, and commumication from the riase to the handler.
1599\begin{lstlisting}
1600exception void h( int i );
1601exception int h( int i, double d );
1602
1603void f(...) {
1604        ... throw h( 3 );
1605        ... i = resume h( 3, 5.1 );
1606}
1607
1608try {
1609        f(...);
1610} catch h( int w ) {
1611        // reset
1612} resume h( int p, double x ) {
1613        return 17;  // recover
1614} finally {
1615}
1616\end{lstlisting}
1617So 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.
1618The 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.
1619
1620
1621\section{Types}
1622
1623\subsection{Type Definitions}
1624
1625\CFA allows users to define new types using the keyword type.
1626
1627\begin{lstlisting}
1628// SensorValue is a distinct type and represented as an int
1629type SensorValue = int;
1630\end{lstlisting}
1631
1632A 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.
1633This means that users can define distinct function overloads for the new type (see Overloading for more information).
1634For example:
1635
1636\begin{lstlisting}
1637type SensorValue = int;
1638void printValue(int v) {...}
1639void printValue(SensorValue v) {...}
1640void process(int v) {...}
1641
1642SensorValue s = ...;
1643
1644printValue(s); // calls version with SensorValue argument
1645
1646printValue((int) s); // calls version with int argument
1647
1648process(s); // implicit conversion to int
1649\end{lstlisting}
1650
1651If SensorValue was defined with a typedef, then these two print functions would not have unique signatures.
1652This can be very useful to create a distinct type that has the same representation as another type.
1653
1654The compiler will assume it can safely convert from the old type to the new type, implicitly.
1655Users may override this and define a function that must be called to convert from one type to another.
1656
1657\begin{lstlisting}
1658type SensorValue = int;
1659// ()? is the overloaded conversion operator identifier
1660// This function converts an int to a SensorValue
1661SensorValue ()?(int val) {
1662        ...
1663}
1664void process(int v) {...}
1665
1666SensorValue s = ...;
1667process(s); // implicit call to conversion operator
1668\end{lstlisting}
1669
1670In many cases, it is not desired for the compiler to do this implicit conversion.
1671To avoid that, the user can use the explicit modifier on the conversion operator.
1672Any places where the conversion is needed but not explicit (with a cast), will result in a compile-time error.
1673
1674\begin{lstlisting}
1675type SensorValue = int;
1676
1677// conversion from int to SensorValue; must be explicit
1678explicit SensorValue ()?(int val) {
1679        ...
1680}
1681
1682void process(int v) {...}
1683
1684SensorValue s = ...;
1685process(s); // implicit cast to int: compile-time error
1686process((int) s); // explicit cast to int: calls conversion func
1687\end{lstlisting}
1688
1689The conversion may not require any code, but still need to be explicit; in that case, the syntax can be simplified to:
1690\begin{lstlisting}
1691type SensorValue = int;
1692explicit SensorValue ()?(int);
1693void process(int v) {...}
1694
1695SensorValue s = ...;
1696process(s); // compile-time error
1697process((int) s); // type is converted, no function is called
1698\end{lstlisting}
1699
1700
1701\subsection{Structures}
1702
1703Structures in \CFA are basically the same as structures in C.
1704A structure is defined with the same syntax as in C.
1705When referring to a structure in \CFA, users may omit the struct keyword.
1706\begin{lstlisting}
1707struct Point {
1708        double x;
1709        double y;
1710};
1711
1712Point p = {0.0, 0.0};
1713\end{lstlisting}
1714
1715\CFA does not support inheritance among types, but instead uses composition to enable reuse of structure fields.
1716Composition is achieved by embedding one type into another.
1717When type A is embedded in type B, an object with type B may be used as an object of type A, and the fields of type A are directly accessible.
1718Embedding types is achieved using anonymous members.
1719For example, using Point from above:
1720\begin{lstlisting}
1721void foo(Point p);
1722
1723struct ColoredPoint {
1724        Point; // anonymous member (no identifier)
1725        int Color;
1726};
1727...
1728        ColoredPoint cp = ...;
1729        cp.x = 10.3; // x from Point is accessed directly
1730        cp.color = 0x33aaff; // color is accessed normally
1731        foo(cp); // cp can be used directly as a Point
1732\end{lstlisting}
1733
1734
1735\subsection{Constructors and Destructors}
1736
1737\CFA supports C initialization of structures, but it also adds constructors for more advanced initialization.
1738Additionally, \CFA adds destructors that are called when a variable is de-allocated (variable goes out of scope or object is deleted).
1739These functions take a reference to the structure as a parameter (see
1740References for more information).
1741
1742\begin{figure}
1743\begin{lstlisting}
1744struct Widget {
1745        int id;
1746        float size;
1747        Parts *optionalParts;
1748};
1749
1750// ?{} is the constructor operator identifier
1751// The first argument is a reference to the type to initialize
1752// Subsequent arguments can be specified for initialization
1753
1754void ?{}(Widget &w) { // default constructor
1755        w.id = -1;
1756        w.size = 0.0;
1757        w.optionalParts = 0;
1758}
1759
1760// constructor with values (does not need to include all fields)
1761void ?{}(Widget &w, int id, float size) {
1762        w.id = id;
1763        w.size = size;
1764        w.optionalParts = 0;
1765}
1766
1767// ^? is the destructor operator identifier
1768void ^?(Widget &w) { // destructor
1769        w.id = 0;
1770        w.size = 0.0;
1771        if (w.optionalParts != 0) {
1772        // This is the only pointer to optionalParts, free it
1773        free(w.optionalParts);
1774        w.optionalParts = 0;
1775        }
1776}
1777
1778Widget baz; // reserve space only
1779Widget foo{}; // calls default constructor
1780Widget bar{23, 2.45}; // calls constructor with values
1781baz{24, 0.91}; // calls constructor with values
1782?{}(baz, 24, 0.91}; // explicit call to constructor
1783^bar; // explicit call to destructor
1784^?(bar); // explicit call to destructor
1785\end{lstlisting}
1786\caption{Constructors and Destructors}
1787\end{figure}
1788
1789
1790\begin{comment}
1791\section{References}
1792
1793\CFA supports reference types similar to rvalue references in \CC.
1794A reference is essentially an alias for a variable, allowing multiple names to refer to the same object.
1795A reference can be used as a safer alternative to a pointer, because it can be used to pass a variable by reference, but it must always reference an object.
1796It cannot be NULL, it must be assigned a value at initialization, and the object it references cannot change once it is set.
1797By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks.
1798In structures, a reference can replace a pointer to an object that should always have a valid value.
1799When a structure contains a reference, all of its constructors must initialize the reference and all instances of this structure must initialize it upon definition.
1800
1801The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
1802Use \lstinline@&@ to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
1803When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
1804The \lstinline@&@ is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
1805
1806\begin{figure}
1807\begin{lstlisting}
1808// parameter p is a reference to a Point
1809void movePointUp(Point &p) {
1810        p.y += 1.0; // Uses dot-notation to access fields
1811}
1812
1813Point p1 = ...;
1814ColoredPoint cp1 = ...;
1815movePoint(p1); // reference to p1 passed to movePoint
1816movePoint(cp1); // reference to cp1 passed to movePoint
1817
1818// a ListElement cannot be created without a valid list
1819
1820struct ListElement {
1821        int element;
1822        List &list; // a list element has a reference to the list
1823}
1824
1825// The constructor must initialize the reference
1826void ?{}(ListElement &le, int e, List &l) {
1827        le.element = e;
1828        &le.list = &l; // initialize the reference
1829}
1830
1831ListElement e1{88, numberList}; // uses constructor
1832ListElement e2; // compiler error: uninitialized reference
1833Listing 10: References
1834\end{lstlisting}
1835\end{figure}
1836\end{comment}
1837
1838
1839\section{Overloading}
1840
1841Overloading refers to the capability of a programmer to define and use multiple objects in a program with the same name.
1842In \CFA, a declaration may overload declarations from outer scopes with the same name, instead of hiding them as is the case in C.
1843This may cause identical C and \CFA programs to behave differently.
1844The compiler selects the appropriate object (overload resolution) based on context information at the place where it is used.
1845Overloading allows programmers to give functions with different signatures but similar semantics the same name, simplifying the interface to users.
1846Disadvantages of overloading are that it can be used to give functions with different semantics the same name, causing confusion, or that the compiler may resolve to a different function from what the programmer expected.
1847\CFA allows overloading of functions, operators, variables, and even the constants 0 and 1.
1848
1849The compiler follows some overload resolution rules to determine the best interpretation of all of these overloads.
1850The best valid interpretations are the valid interpretations that use the fewest unsafe conversions.
1851Of these, the best are those where the functions and objects involved are the least polymorphic.
1852Of these, the best have the lowest total conversion cost, including all implicit conversions in the argument expressions.
1853Of these, the best have the highest total conversion cost for the implicit conversions (if any) applied to the argument expressions.
1854If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous.
1855For details about type inference and overload resolution, please see the \CFA Language Specification.
1856\begin{lstlisting}
1857int foo(int a, int b) {
1858        float sum = 0.0;
1859        float special = 1.0;
1860        {
1861                int sum = 0;
1862                // both the float and int versions of sum are available
1863                float special = 4.0;
1864                // this inner special hides the outer version
1865                ...
1866        }
1867        ...
1868}
1869\end{lstlisting}
1870
1871
1872\subsection{Overloaded Constant}
1873
1874The constants 0 and 1 have special meaning.
1875In \CFA, as in C, all scalar types can be incremented and
1876decremented, which is defined in terms of adding or subtracting 1.
1877The operations \lstinline@&&@, \lstinline@||@, and \lstinline@!@ can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. \lstinline@(a && b)@ becomes \lstinline@(a != 0 && b != 0)@).
1878
1879In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any
1880arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a
1881special case.
1882However, user-defined arithmetic types often need the equivalent of a 1 or 0 for their
1883functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their
1884polymorphic parameters, and user-defined pointer-like types may need a null value.
1885Defining special
1886constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline@_Bool@.
1887
1888Why just 0 and 1? Why not other integers? No other integers have special status in C.
1889A facility that let programmers declare specific constants..const Rational 12., for instance. would not be much of an improvement.
1890Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
1891The complexity of such a feature doesn.t seem worth the gain.
1892
1893For example, to define the constants for a complex type, the programmer would define the following:
1894
1895\begin{lstlisting}
1896struct Complex {
1897        double real;
1898        double imaginary;
1899}
1900
1901const Complex 0 = {0, 0};
1902const Complex 1 = {1, 0};
1903...
1904
1905        Complex a = 0;
1906...
1907
1908        a++;
1909...
1910        if (a) { // same as if (a == 0)
1911...
1912}
1913\end{lstlisting}
1914
1915
1916\subsection{Variable Overloading}
1917
1918The overload rules of \CFA allow a programmer to define multiple variables with the same name, but different types.
1919Allowing 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.
1920For example, a developer may want to do the following:
1921\begin{lstlisting}
1922int pi = 3;
1923float pi = 3.14;
1924char pi = .p.;
1925\end{lstlisting}
1926
1927
1928\subsection{Function Overloading}
1929
1930Overloaded functions in \CFA are resolved based on the number and type of arguments, type of return value, and the level of specialization required (specialized functions are preferred over generic).
1931
1932The examples below give some basic intuition about how the resolution works.
1933\begin{lstlisting}
1934// Choose the one with less conversions
1935int doSomething(int value) {...} // option 1
1936int doSomething(short value) {...} // option 2
1937
1938int a, b = 4;
1939short c = 2;
1940
1941a = doSomething(b); // chooses option 1
1942a = doSomething(c); // chooses option 2
1943
1944// Choose the specialized version over the generic
1945
1946generic(type T)
1947T bar(T rhs, T lhs) {...} // option 3
1948float bar(float rhs, float lhs){...} // option 4
1949float a, b, c;
1950double d, e, f;
1951c = bar(a, b); // chooses option 4
1952
1953// specialization is preferred over unsafe conversions
1954
1955f = bar(d, e); // chooses option 5
1956\end{lstlisting}
1957
1958
1959\subsection{Operator Overloading}
1960
1961\CFA also allows operators to be overloaded, to simplify the use of user-defined types.
1962Overloading the operators allows the users to use the same syntax for their custom types that they use for built-in types, increasing readability and improving productivity.
1963\CFA uses the following special identifiers to name overloaded operators:
1964
1965\begin{table}[hbt]
1966\hfil
1967\begin{tabular}[t]{ll}
1968%identifier & operation \\ \hline
1969\lstinline@?[?]@ & subscripting \impl{?[?]}\\
1970\lstinline@?()@ & function call \impl{?()}\\
1971\lstinline@?++@ & postfix increment \impl{?++}\\
1972\lstinline@?--@ & postfix decrement \impl{?--}\\
1973\lstinline@++?@ & prefix increment \impl{++?}\\
1974\lstinline@--?@ & prefix decrement \impl{--?}\\
1975\lstinline@*?@ & dereference \impl{*?}\\
1976\lstinline@+?@ & unary plus \impl{+?}\\
1977\lstinline@-?@ & arithmetic negation \impl{-?}\\
1978\lstinline@~?@ & bitwise negation \impl{~?}\\
1979\lstinline@!?@ & logical complement \impl{"!?}\\
1980\lstinline@?*?@ & multiplication \impl{?*?}\\
1981\lstinline@?/?@ & division \impl{?/?}\\
1982\end{tabular}\hfil
1983\begin{tabular}[t]{ll}
1984%identifier & operation \\ \hline
1985\lstinline@?%?@ & remainder \impl{?%?}\\
1986\lstinline@?+?@ & addition \impl{?+?}\\
1987\lstinline@?-?@ & subtraction \impl{?-?}\\
1988\lstinline@?<<?@ & left shift \impl{?<<?}\\
1989\lstinline@?>>?@ & right shift \impl{?>>?}\\
1990\lstinline@?<?@ & less than \impl{?<?}\\
1991\lstinline@?<=?@ & less than or equal \impl{?<=?}\\
1992\lstinline@?>=?@ & greater than or equal \impl{?>=?}\\
1993\lstinline@?>?@ & greater than \impl{?>?}\\
1994\lstinline@?==?@ & equality \impl{?==?}\\
1995\lstinline@?!=?@ & inequality \impl{?"!=?}\\
1996\lstinline@?&?@ & bitwise AND \impl{?&?}\\
1997\end{tabular}\hfil
1998\begin{tabular}[t]{ll}
1999%identifier & operation \\ \hline
2000\lstinline@?^?@ & exclusive OR \impl{?^?}\\
2001\lstinline@?|?@ & inclusive OR \impl{?"|?}\\
2002\lstinline@?=?@ & simple assignment \impl{?=?}\\
2003\lstinline@?*=?@ & multiplication assignment \impl{?*=?}\\
2004\lstinline@?/=?@ & division assignment \impl{?/=?}\\
2005\lstinline@?%=?@ & remainder assignment \impl{?%=?}\\
2006\lstinline@?+=?@ & addition assignment \impl{?+=?}\\
2007\lstinline@?-=?@ & subtraction assignment \impl{?-=?}\\
2008\lstinline@?<<=?@ & left-shift assignment \impl{?<<=?}\\
2009\lstinline@?>>=?@ & right-shift assignment \impl{?>>=?}\\
2010\lstinline@?&=?@ & bitwise AND assignment \impl{?&=?}\\
2011\lstinline@?^=?@ & exclusive OR assignment \impl{?^=?}\\
2012\lstinline@?|=?@ & inclusive OR assignment \impl{?"|=?}\\
2013\end{tabular}
2014\hfil
2015\caption{Operator Identifiers}
2016\label{opids}
2017\end{table}
2018
2019These identifiers are defined such that the question marks in the name identify the location of the operands.
2020These operands represent the parameters to the functions, and define how the operands are mapped to the function call.
2021For example, \lstinline@a + b@ becomes \lstinline@?+?(a, b)@.
2022
2023In the example below, a new type, myComplex, is defined with an overloaded constructor, + operator, and string operator.
2024These operators are called using the normal C syntax.
2025
2026\begin{lstlisting}
2027type Complex = struct { // define a Complex type
2028        double real;
2029        double imag;
2030}
2031
2032// Constructor with default values
2033
2034void ?{}(Complex &c, double real = 0.0, double imag = 0.0) {
2035        c.real = real;
2036        c.imag = imag;
2037}
2038
2039Complex ?+?(Complex lhs, Complex rhs) {
2040        Complex sum;
2041        sum.real = lhs.real + rhs.real;
2042        sum.imag = lhs.imag + rhs.imag;
2043        return sum;
2044}
2045
2046String ()?(const Complex c) {
2047        // use the string conversions for the structure members
2048        return (String)c.real + . + . + (String)c.imag + .i.;
2049}
2050...
2051
2052Complex a, b, c = {1.0}; // constructor for c w/ default imag
2053...
2054c = a + b;
2055print(.sum = . + c);
2056\end{lstlisting}
2057
2058
2059\section{Auto Type-Inferencing}
2060
2061Auto type-inferencing occurs in a declaration where a variable's type is inferred from its initialization expression type.
2062\begin{quote2}
2063\begin{tabular}{@{}l@{\hspace{30pt}}ll@{}}
2064\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{\lstinline@gcc@}\index{gcc} \\
2065\begin{lstlisting}
2066
2067auto j = 3.0 * 4;
2068int i;
2069auto k = i;
2070\end{lstlisting}
2071&
2072\begin{lstlisting}
2073#define expr 3.0 * i
2074typeof(expr) j = expr;
2075int i;
2076typeof(i) k = i;
2077\end{lstlisting}
2078&
2079\begin{lstlisting}
2080
2081// use type of initialization expression
2082
2083// use type of primary variable
2084\end{lstlisting}
2085\end{tabular}
2086\end{quote2}
2087The two important capabilities are:
2088\begin{itemize}
2089\item
2090preventing having to determine or write out long generic types,
2091\item
2092ensure secondary variables, related to a primary variable, always have the same type.
2093\end{itemize}
2094
2095In \CFA, \lstinline@typedef@ provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
2096\lstinline@gcc@ provides \lstinline@typeof@ to declare a secondary variable from a primary variable.
2097\CFA also relies heavily on the specification of the left-hand side of assignment for type inferencing, so in many cases it is crucial to specify the type of the left-hand side to select the correct type of the right-hand expression.
2098Only for overloaded routines with the same return type is variable type-inferencing possible.
2099Finally, \lstinline@auto@ presents the programming problem of tracking down a type when the type is actually needed.
2100For example, given
2101\begin{lstlisting}
2102auto j = `...`
2103\end{lstlisting}
2104and the need to write a routine to compute using \lstinline@j@
2105\begin{lstlisting}
2106void rtn( `...` parm );
2107rtn( j );
2108\end{lstlisting}
2109A programmer must work backwards to determine the type of \lstinline@j@'s initialization expression, reconstructing the possibly long generic type-name.
2110In this situation, having the type name or a short alias is very useful.
2111
2112There is also the conundrum in type inferencing of when to \emph{\Index{brand}} a type.
2113That is, when is the type of the variable more important than the type of its initialization expression.
2114For example, if a change is made in an initialization expression, it can cause hundreds or thousands of cascading type changes and/or errors.
2115At some point, a programmer wants the type of the variable to remain constant and the expression to be in error when it changes.
2116
2117Given \lstinline@typedef@ and \lstinline@typeof@ in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
2118Should a significant need arise, this feature can be revisited.
2119
2120
2121\section{Generics}
2122
2123\CFA supports parametric polymorphism to allow users to define generic functions and types.
2124Generics allow programmers to use type variables in place of concrete types so that the code can be reused with multiple types.
2125The type parameters can be restricted to satisfy a set of constraints.
2126This enables \CFA to build fully compiled generic functions and types, unlike other languages like \CC where templates are expanded or must be explicitly instantiated.
2127
2128
2129\subsection{Generic Functions}
2130
2131Generic functions in \CFA are similar to template functions in \CC, and will sometimes be expanded into specialized versions, just like in \CC.
2132The difference, however, is that generic functions in \CFA can also be separately compiled, using function pointers for callers to pass in all needed functionality for the given type.
2133This means that compiled libraries can contain generic functions that can be used by programs linked with them (statically or dynamically).
2134Another advantage over \CC templates is unlike templates, generic functions are statically checked, even without being instantiated.
2135
2136A simple example of using Do.s parametric polymorphism to create a generic swap function would look like this:
2137
2138\begin{lstlisting}
2139generic(type T)
2140void swap(T &a, T &b) {
2141        T tmp = a;
2142        a = b;
2143        b = a;
2144}
2145
2146int a, b;
2147swap(a, b);
2148
2149Point p1, p2;
2150swap(p1, p2);
2151\end{lstlisting}
2152
2153Here, instead of specifying types for the parameters a and b, the function has a generic type parameter, type T.
2154This function can be called with any type, and the compiler will handle generating the proper code for that type, using call site inference to determine the appropriate value for T.
2155
2156
2157\subsection{Bounded Quantification}
2158
2159Some generic functions only work (or make sense) for any type that satisfies a given property.
2160For example, here is a function to pick the minimum of two values of some type.
2161\begin{lstlisting}
2162generic (type T | bool ?<?(T, T) )
2163
2164T min(T a, T b) {
2165        return a < b ? a : b;
2166}
2167\end{lstlisting}
2168
2169It 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.
2170The ordering function used here is the less than operator, <.
2171The syntax used to reference the operator is discussed in further detail in Operator Overloading.
2172In \CFA, this assertion on the type of a generic is written as the bound, (type T | bool ?<?(T, T)).
2173The \CFA compiler enforces that minis only called with types for which the less than operator is defined, and reports a compile-time error otherwise.
2174
2175Bounds can also involve multiple types, and multiple requirements, as shown below:
2176\begin{lstlisting}
2177generic (type T, type U | { T foo(T, U); U bar(U); })
2178
2179T baz(T t, U u) {
2180        return foo(t, bar(u));
2181}
2182\end{lstlisting}
2183
2184
2185\subsection{Interfaces}
2186
2187Type bounds as shown above are not very informative, merely requiring that a function exists with the right name and type.
2188Suppose you try to call a polymorphic function and \CFA gives you an error that int combine(int, int) is not defined.
2189Can you define it? What is it supposed to do? Perhaps it should compute the sum, or the bitwise and, or the maximum, or the least common multiple; or perhaps it's an operation that can't be defined for integers.
2190The function signature doesn't say.
2191
2192Interfaces gather together a set of function signatures under a common name, which solves two problems.
2193First, an interface name can be used in type bounds instead of function signatures.
2194This avoids repetition when a bound is used in many functions.
2195Second, interfaces explicitly document the existence of a commonly used set of functionality, making programs easier to understand.
2196\begin{lstlisting}
2197generic (type T)
2198interface Orderable {
2199        bool ?<?(T, T);
2200};
2201
2202generic (type T | Orderable(T))
2203T min(T a, T b) {
2204        return a < b ? a : b;
2205}
2206\end{lstlisting}
2207
2208This definition of the interface Orderable makes the generic function min easier to read and understand.
2209Orderable can also be reused for other generic functions, max for example.
2210Interfaces can also build on top of other interfaces.
2211For example:
2212\begin{lstlisting}
2213generic (type T | Orderable(T)
2214interface FooBarable {
2215        int foo(T, T);
2216        int Bar(T, T);
2217};
2218\end{lstlisting}
2219
2220The FooBarable interface specifies all of the bounds of the Orderable interface, plus the additional bounds specified in its definition.
2221A type does not need to specify that it satisfies any interface, the compiler can figure this out at compile time.
2222For example, there is no need to add some special syntax to show that a type implements the Orderable interface, just define a ?<? operator and it is satisfied.
2223
2224
2225\subsection{Generic Typedefs}
2226
2227Type synonyms can be defined generically using the typedef keyword together with a generic type annotation.
2228These can be used to abbreviate complicated type expressions, especially in generic code.
2229\begin{lstlisting}
2230// typedef the generic function pointers for later use
2231
2232generic(type T)
2233typedef int (*predicate)(T);
2234generic(type Captured, type T)
2235typedef void (*callback)(Captured, T);
2236
2237generic(type T)
2238void find(int length, T *array,
2239        predicate(T) p, callback(void *, T)f) {
2240        int i;
2241        for (i = 0; i < length; i++)
2242        if (p(array[i])) f(NULL, array[i]);
2243}
2244\end{lstlisting}
2245
2246
2247\subsection{Generic Types}
2248
2249Generic types are defined using the same mechanisms as those described above for generic functions.
2250This feature allows users to create types that have one or more fields that use generic parameters as types, similar to a template classes in \CC.
2251For example, to make a generic linked list, a placeholder is created for the type of the elements, so that the specific type of the elements in the list need not be specified when defining the list.
2252In C, something like this would have to be done using void pointers and unsafe casting.
2253As in generic functions, Do.s generic types are different from \CC templates in that they can be fully compiled, while \CC templates are more like macro expansions.
2254This means that a \CFA generic type from a compiled library can be used with any type that satisfies the bounds.
2255
2256The syntax for defining a generic type looks very similar to that of a generic function.
2257Generic types support bounds and interfaces, using the same syntax as generic functions.
2258\begin{lstlisting}
2259generic (type T)
2260struct LinkedListElem {
2261        T elem;
2262        LinkedListElem(T) *next;
2263};
2264
2265LinkedListElem *++?(LinkedListElem **elem) {
2266        return *elem = elem->next;
2267}
2268
2269generic (type T)
2270struct LinkedList {
2271        LinkedListElem(T) *head;
2272        unsigned int size;
2273}
2274
2275generic (type T | bool ?==?(T, T))
2276bool contains(LinkedList(T) *list, T elem) {
2277        for(LinkedListElem *iter = list->head; iter != 0; ++iter) {
2278        if (iter->elem == elem) return true;
2279        }
2280        return false;
2281}
2282\end{lstlisting}
2283
2284
2285\section{Safety}
2286
2287Safety, along with productivity, is a key goal of Do.
2288This section discusses the safety features that have been included in \CFA to help programmers create more stable, reliable, and secure code.
2289
2290
2291\subsection{Exceptions}
2292
2293\CFA introduces support for exceptions as an easier way to recover from exceptional conditions that may be detected within a block of code.
2294In C, developers can use error codes and special return values to report to a caller that an error occurred in a function.
2295The major problem with error codes is that they can be easily ignored by the caller.
2296Failure to properly check for errors can result in the caller making incorrect assumptions about the current state or about the return value that are very likely to result in errors later on in the program, making the source of the problem more difficult to find when debugging.
2297An unhandled exception on the other hand will cause a crash, revealing the original source of the erroneous state.
2298
2299Exceptions in \CFA allow a different type of control flow.
2300Throwing an exception terminates execution of the current block, invokes the destructors of variables that are local to the block, and propagates the exception to the parent block.
2301The exception is immediately re-thrown from the parent block unless it is caught as described below.
2302\CFA uses keywords similar to \CC for exception handling.
2303An exception is thrown using a throw statement, which accepts one argument.
2304
2305\begin{lstlisting}
2306        ...
2307
2308        throw 13;
2309
2310        ...
2311\end{lstlisting}
2312
2313An exception can be caught using a catch statement, which specifies the type of the exception it can catch.
2314A catch is specified immediately after a guarded block to signify that it can catch an exception from that block.
2315A guarded block is specified using the try keyword, followed by a block of code inside of curly braces.
2316
2317\begin{lstlisting}
2318        ...
2319
2320        try {
2321        throw 13;
2322        }
2323        catch(int e) {
2324        printf(.caught an exception: %d\n., e);
2325        }
2326\end{lstlisting}
2327
2328
2329\subsection{Memory Management}
2330
2331
2332\subsubsection{Manual Memory Management}
2333
2334Using malloc and free to dynamically allocate memory exposes several potential, and common, errors.
2335First, malloc breaks type safety because it returns a pointer to void.
2336There is no relationship between the type that the returned pointer is cast to, and the amount of memory allocated.
2337This problem is solved with a type-safe malloc.
2338Do.s type-safe malloc does not take any arguments for size.
2339Instead, it infers the type based on the return value, and then allocates space for the inferred type.
2340
2341\begin{lstlisting}
2342float *f = malloc(); // allocates the size of a float
2343
2344struct S {
2345        int i, j, k;
2346};
2347
2348struct S *s = malloc(); // allocates the size of a struct S
2349\end{lstlisting}
2350
2351In addition to the improved malloc, \CFA also provides a technique for combining allocation and initialization into one step, using the new function.
2352For all constructors defined for a given type (see Operator Overloading), a corresponding call to new can be used to allocate and construct that type.
2353
2354\begin{lstlisting}
2355type Complex = struct {
2356        float real;
2357        float imag;
2358};
2359
2360// default constructor
2361
2362void ?{}(Complex &c) {
2363        c.real = 0.0;
2364        c.imag = 0.0;
2365}
2366
2367
2368
2369// 2 parameter constructor
2370
2371void ?{}(Complex &c, float real, float imag) {
2372        c.real = real;
2373        c.imag = imag;
2374}
2375
2376
2377int main() {
2378        Complex c1; // No constructor is called
2379        Complex c2{}; // Default constructor called
2380        Complex c3{1.0, -1.0}; // 2 parameter constructor is called
2381
2382        Complex *p1 = malloc(); // allocate
2383        Complex *p2 = new(); // allocate + default constructor
2384        Complex *p3 = new(0.5, 1.0); // allocate + 2 param constructor
2385}
2386
2387\end{lstlisting}
2388
2389
2390\subsubsection{Automatic Memory Management}
2391
2392\CFA may also support automatic memory management to further improve safety.
2393If the compiler can insert all of the code needed to manage dynamically allocated memory (automatic reference counting), then developers can avoid problems with dangling pointers, double frees, memory leaks, etc.
2394This feature requires further investigation.
2395\CFA will not have a garbage collector, but might use some kind of region-based memory management.
2396
2397
2398\subsection{Unsafe C Constructs}
2399
2400C programmers are able to access all of the low-level tricks that are sometimes needed for close-to-the-hardware programming.
2401Some of these practices however are often error-prone and difficult to read and maintain.
2402Since \CFA is designed to be safer than C, such constructs are disallowed in \CFA code.
2403If a programmer wants to use one of these unsafe C constructs, the unsafe code must be contained in a C linkage block (see Interoperability), which will be compiled like C code.
2404This block means that the user is telling the tools, .I know this is unsafe, but I.m going to do it anyway..
2405
2406The exact set of unsafe C constructs that will be disallowed in \CFA has not yet been decided, but is sure to include pointer arithmetic, pointer casting, etc.
2407Once the full set is decided, the rules will be listed here.
2408
2409
2410\section{Syntactic Anomalies}
2411
2412The number 0 and 1 are treated specially in \CFA, and can be redefined as variables.
2413One syntactic anomaly is when a field in an structure is names 0 or 1:
2414\begin{lstlisting}
2415struct S {
2416        int 0, 1;
2417} s;
2418\end{lstlisting}
2419The problem occurs in accesing these fields using the selection operation ``\lstinline@.@'':
2420\begin{lstlisting}
2421s.0 = 0;        // ambiguity with floating constant .0
2422s.1 = 1;        // ambiguity with floating constant .1
2423\end{lstlisting}
2424To make this work, a space is required after the field selection:
2425\begin{lstlisting}
2426`s.@\textvisiblespace@0` = 0;
2427`s.@\textvisiblespace@1` = 1;
2428\end{lstlisting}
2429While this sytact is awkward, it is unlikely many programers will name fields of a structure 0 or 1.
2430Like the \CC lexical problem with closing template-syntax, e.g, \lstinline@Foo<Bar<int`>>`@, this issue can be solved with a more powerful lexer/parser.
2431
2432There are several ambiguous cases with operator identifiers, e.g., \lstinline@int *?*?()@, where the string \lstinline@*?*?@ can be lexed as \lstinline@*@/\lstinline@?*?@ or \lstinline@*?@/\lstinline@*?@.
2433Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., \lstinline@*i@, users will be annoyed if they cannot do this with respect to operator identifiers.
2434Even with this special hack, there are 5 general cases that cannot be handled.
2435The first case is for the function-call identifier \lstinline@?()@:
2436\begin{lstlisting}
2437int *@\textvisiblespace@?()();  // declaration: space required after '*'
2438*@\textvisiblespace@?()();              // expression: space required after '*'
2439\end{lstlisting}
2440Without the space, the string \lstinline@*?()@ is ambiguous without N character look ahead;
2441it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument/parameter list.
2442
2443The 4 remaining cases occur in expressions:
2444\begin{lstlisting}
2445i++@\textvisiblespace@?i:0;             // space required before '?'
2446i--@\textvisiblespace@?i:0;             // space required before '?'
2447i@\textvisiblespace@?++i:0;             // space required after '?'
2448i@\textvisiblespace@?--i:0;             // space required after '?'
2449\end{lstlisting}
2450In the first two cases, the string \lstinline@i++?@ is ambiguous, where this string can be lexed as \lstinline@i@ / \lstinline@++?@ or \lstinline@i++@ / \lstinline@?@;
2451it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
2452In the second two cases, the string \lstinline@?++x@ is ambiguous, where this string can be lexed as \lstinline@?++@ / \lstinline@x@ or \lstinline@?@ / y\lstinline@++x@;
2453it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
2454
2455
2456\section{Concurrency}
2457
2458Today's processors for nearly all use cases, ranging from embedded systems to large cloud computing servers, are composed of multiple cores, often heterogeneous.
2459As machines grow in complexity, it becomes more difficult for a program to make the most use of the hardware available.
2460\CFA includes built-in concurrency features to enable high performance and improve programmer productivity on these multi-/many-core machines.
2461
2462Concurrency support in \CFA is implemented on top of a highly efficient runtime system of light-weight, M:N, user level threads.
2463The model integrates concurrency features into the language by making the structure type the core unit of concurrency.
2464All communication occurs through method calls, where data is sent via method arguments, and received via the return value.
2465This enables a very familiar interface to all programmers, even those with no parallel programming experience.
2466It also allows the compiler to do static type checking of all communication, a very important safety feature.
2467This controlled communication with type safety has some similarities with channels in Go, and can actually implement
2468channels exactly, as well as create additional communication patterns that channels cannot.
2469Mutex objects, monitors, are used to contain mutual exclusion within an object and synchronization across concurrent threads.
2470
2471Three new keywords are added to support these features:
2472
2473monitor creates a structure with implicit locking when accessing fields
2474
2475mutex implies use of a monitor requiring the implicit locking
2476
2477task creates a type with implicit locking, separate stack, and a thread
2478
2479
2480\subsection{Monitors}
2481
2482A monitor is a structure in \CFA which includes implicit locking of its fields.
2483Users of a monitor interact with it just like any structure, but the compiler handles code as needed to ensure mutual exclusion.
2484An example of the definition of a monitor is shown here:
2485\begin{lstlisting}
2486type Account = monitor {
2487        const unsigned long number; // account number
2488        float balance; // account balance
2489};
2490\end{lstlisting}
2491
2492Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor;
2493it is always passed by reference.
2494Users can specify to the compiler whether or not a function will require mutual exclusion of the monitor using the mutex modifier on the parameter.
2495When mutex is specified, the compiler inserts locking before executing the body of the function, and unlocking after the body.
2496This means that a function requiring mutual exclusion could block if the lock is already held by another thread.
2497Blocking on a monitor lock does not block the kernel thread, it simply blocks the user thread, which yields its kernel thread while waiting to obtain the lock.
2498If multiple mutex parameters are specified, they will be locked in parameter order (i.e. first parameter is locked first) and unlocked in the
2499reverse order.
2500\begin{lstlisting}
2501// This function accesses a constant field, it does not require
2502// mutual exclusion
2503
2504export unsigned long getAccountNumber(Account &a) {
2505        return a.number;
2506}
2507
2508// This function accesses and modifies a shared field; it
2509// requires mutual exclusion
2510
2511export float withdrawal(mutex Account &a, float amount) {
2512        a.balance -= amount;
2513        return a.balance;
2514}
2515\end{lstlisting}
2516
2517Often, one function using a monitor will call another function using that same monitor.
2518If both require mutual exclusion, then the thread would be waiting for itself to release the lock when it calls the inner function.
2519This situation is resolved by allowing recursive entry (reentrant locks), meaning that if the lock is already held by the caller, it can be locked again.
2520It will still be unlocked the same number of times.
2521An example of this situation is shown below:
2522
2523\begin{lstlisting}
2524// deleting a job from a worker requires mutual exclusion
2525
2526void deleteJob(mutex Worker &w, Job &j) {
2527        ...
2528}
2529
2530// transferring requires mutual exclusion and calls deleteJob
2531
2532void transferJob(mutex Worker &from, Worker &to) {
2533        ...
2534        deleteJob(j);
2535        ...
2536}
2537\end{lstlisting}
2538
2539
2540\subsection{Tasks}
2541
2542\CFA also provides a simple mechanism for creating and utilizing user level threads.
2543A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
2544Similar to a monitor, a task is defined like a structure:
2545\begin{lstlisting}
2546type Adder = task {
2547        int *row;
2548        int size;
2549        int &subtotal;
2550}
2551\end{lstlisting}
2552
2553A task may define a constructor, which will be called upon allocation and run on the caller.s thread.
2554A destructor may also be defined, which is called at de-allocation (when a dynamic object is deleted or when a local object goes out of scope).
2555After a task is allocated and initialized, its thread is spawned implicitly and begins executing in its function call method.
2556All tasks must define this function call method, with a void return value and no additional parameters, or the compiler will report an error.
2557Below are example functions for the above Adder task, and its usage to sum up a matrix on multiple threads.
2558(Note that this example is designed to display the syntax and functionality, not the best method to solve this problem)
2559\begin{lstlisting}
2560void ?{}(Adder &a, int r[], int s, int &st) { // constructor
2561        a.row = r;
2562        a.size = s;
2563        a.subtotal = st;
2564}
2565
2566// implicitly spawn thread and begin execution here
2567
2568void ?()(Adder &a) {
2569        int c;
2570        subtotal = 0;
2571        for (c=0; c<a.size; ++c) {
2572        subtotal += row[c];
2573        }
2574}
2575
2576int main() {
2577        const int rows = 100, cols = 1000000;
2578        int matrix[rows][cols];
2579        int subtotals[rows];
2580        int total = 0;
2581        int r;
2582
2583        { // create a new scope here for our adders
2584        Adder adders[rows];
2585        // read in the matrix
2586        ...
2587        for (r=0; r<rows; ++r) {
2588        // tasks are initialized on this thread
2589        Adders[r] = {matrix[r], cols, subtotals[r]};
2590        Adders[r](); // spawn thread and begin execution
2591        }
2592        } // adders go out of scope; block here until they all finish
2593        total += subtotals[r];
2594        printf(.total is %d\n., total);
2595}
2596\end{lstlisting}
2597
2598
2599\subsection{Cooperative Scheduling}
2600
2601Tasks in \CFA are cooperatively scheduled, meaning that a task will not be interrupted by another task, except at specific yield points.
2602In Listing 31, there are no yield points, so each task runs to completion with no interruptions.
2603Places where a task could yield include waiting for a lock (explicitly or implicitly), waiting for I/O, or waiting for a specific function (or one of a set of functions) to be called.
2604This last option is introduced with the yield function. yield is used to indicate that this task should yield its thread until the specified function is called.
2605For example, the code below defines a monitor that maintains a generic list.
2606When a task tries to pop from the list, but it is empty, the task should yield until another task puts something into the list, with the push function.
2607Similarly, 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.
2608
2609\begin{lstlisting}
2610// type T is used as a generic type for all definitions inside
2611// the curly brackets
2612
2613generic(type T) {
2614        type Channel = monitor {
2615        List(T) list; // list is a simple generic list type
2616        };
2617
2618        T pop(mutex &Channel(T) ch) {
2619        if (ch.list.empty()) {
2620        // yield until push is called for this channel
2621        yield(push);
2622        }
2623        return ch.list.pop();
2624        }
2625
2626        void push(mutex &Channel(T)ch, T val) {
2627        if (ch.list.full()) {
2628        // yield until pop is called for this channel
2629        yield(pop);
2630        }
2631        ch.list.push(val);
2632        }
2633}
2634\end{lstlisting}
2635
2636A task can also yield indefinitely by calling yield with no arguments.
2637This will tell the scheduler to yield this task until it is resumed by some other task.
2638A task can resume another task by using its functional call operator.
2639The code below shows a simple ping-pong example, where two tasks yield back and forth to each other using these methods.
2640
2641\begin{lstlisting}
2642type Ping = task {
2643        Pong *partner;
2644};
2645
2646void ?{}(Ping &p, Pong *partner = 0) {
2647        p.partner = partner;
2648}
2649
2650void ?()(Ping &p) {
2651        for(;;) { // loop forever
2652        printf(.ping\n.);
2653        partner(); // resumes the partner task
2654        yield(); // yields this task
2655        }
2656}
2657
2658type Pong = task {
2659        Ping *partner;
2660};
2661
2662void ?{}(Pong &p, Ping *partner = 0) {
2663        p.partner = partner;
2664}
2665
2666void ?()(Pong &p) {
2667        for(;;) { // loop forever
2668        yield(); // yields this task
2669        printf(.pong/n.);
2670        partner(); // resumes the partner task
2671        }
2672}
2673
2674void main() {
2675        Ping ping; // allocate ping
2676        Pong pong{ping}; // allocate, initialize, and start pong
2677        Ping{pong}; // initialize and start ping
2678}
2679\end{lstlisting}
2680
2681The same functionality can be accomplished by providing functions to be called by the partner task.
2682\begin{lstlisting}
2683type Pingpong = task {
2684        String msg;
2685        Pingpong *partner;
2686};
2687
2688void ?{}(Pingpong &p, String msg, Pingpong *partner = 0) {
2689        p.msg = msg;
2690        p.partner = partner;
2691}
2692
2693void ?()(Pingpong &p) {
2694        for(;;) {
2695        yield(go);
2696        }
2697}
2698
2699void go(Pingpong &p) {
2700        print(.%(p.msg)\n.);
2701        go(p.partner);
2702}
2703
2704void main() {
2705        Pingpong ping = {.ping.};
2706        Pingpong pong = {.pong., ping};
2707        ping.partner = pong;
2708        go(ping);
2709}
2710\end{lstlisting}
2711
2712
2713\section{Modules and Packages }
2714
2715\begin{comment}
2716High-level encapsulation is useful for organizing code into reusable units, and accelerating compilation speed.
2717\CFA provides a convenient mechanism for creating, building and sharing groups of functionality that enhances productivity and improves compile time.
2718
2719There are two levels of encapsulation in \CFA, module and package.
2720A module is a logical grouping of functionality that can be easily pulled into another project, much like a module in Python or a package in Go.
2721A module forms a namespace to limit the visibility and prevent naming conflicts of variables.
2722Furthermore, a module is an independent translation unit, which can be compiled separately to accelerate the compilation speed.
2723
2724A package is a physical grouping of one or more modules that is used for code distribution and version management.
2725Package is also the level of granularity at which dependences are managed.
2726A package is similar to the Crate in Rust.
2727
2728
2729\subsection{No Declarations, No Header Files}
2730
2731In C and \CC, it is necessary to declare or define every global variable, global function, and type before it is used in each file.
2732Header files and a preprocessor are normally used to avoid repeating code.
2733Thus, many variables, functions, and types are described twice, which exposes an opportunity for errors and causes additional maintenance work.
2734Instead of following this model, the \CFA tools can extract all of the same information from the code automatically.
2735This information is then stored in the object files for each module, in a format that can quickly be read by the compiler, and stored at the top of the file, for quick access.
2736In addition to the user productivity improvements, this simple change also improves compile time, by saving the information in a simple machine readable format, instead of making the compiler parse the same information over and over from a header file.
2737This seems like a minor change, but according to (Pike, Go at Google: Language Design in the Service of Software Engineering), this simple change can cause massive reductions in compile time.
2738
2739In \CFA, multiple definitions are not necessary.
2740Within a module, all of the module's global definitions are visible throughout the module.
2741For example, the following code compiles, even though isOdd was not declared before being called:
2742\begin{lstlisting}
2743bool isEven(unsigned int x) {
2744        if (x == 0) return true;
2745        else return !isOdd(x);
2746}
2747
2748bool isOdd(unsigned int x) {
2749        if (x == 1) return true;
2750        else return !isEven(x - 2);
2751}
2752\end{lstlisting}
2753
2754Header files in C are used to expose the declarations from a library, so that they can be used externally.
2755With \CFA, this functionality is replaced with module exports, discussed below.
2756When building a \CFA module which needs to be callable from C code, users can use the tools to generate a header file suitable for including in these C files with all of the needed declarations.
2757
2758In order to interoperate with existing C code, \CFA files can still include header files, the contents of which will be enclosed in a C linkage section to indicate C calling conventions (see Interoperability for more information).
2759
2760
2761\subsection{Modules}
2762
2763A module typically contains a set of related types and methods, with some objects accessible from outside the package, and some limited to use inside the module.
2764These modules can then be easily shared and reused in multiple projects.
2765As modules are intended to be distributed for reuse, they should generally have stable, well-defined interfaces.
2766
2767\CFA adds the following keywords to express the module systems: module, export, import, as.
2768
2769
2770\subsubsection{Module Declaration}
2771
2772The syntax to declare a module is module moduleName;.
2773
2774The module declaration must be at the beginning of a file, and each file can only belong to one module.
2775If there is no module declaration at the beginning of a file, the file belongs to the global module.
2776A module can span several files.
2777By convention, a module and the files belonging to the module have additional mapping relationship which is described in the Do-Lang Tooling documentation.
2778
2779The moduleName follows the same rules of a variable name, except that it can use slash "/" to indicate the module/sub-module relationship.
2780For example, container/vector is a valid module name, where container is the parent module name, and vector is the sub-module under container.
2781
2782Only the interfaces of a module are visible from outside, when the module is imported. export is a type decorator to declare a module interface.
2783A method, a global variable or a type can be declared as a module interface.
2784Types defined in a module and referenced by an exported function or a variable must be exported, too.
2785
2786The following code is a simple module declaration example.
2787\begin{lstlisting}
2788module M;
2789
2790//visible outside module M
2791
2792export int f(int i) { return i + 1; }
2793export double aCounter;
2794
2795//not visible outside module M
2796
2797int g(int i) { return i - 1; }
2798
2799double bCounter;
2800\end{lstlisting}
2801
2802export module moduleName; can be use to re-export all the visible (exported) names in moduleName from the current module.
2803
2804
2805\subsubsection{Module Import}
2806
2807The syntax to import a module is import moduleName; or import moduleName as anotherName;.
2808One package cannot be imported with both of the two types of syntax in one file.
2809A package imported in one file will only be visible in this file.
2810For example, two files, A and B belong to the same module.
2811If file A imports another module, M, the exported names in M are not visible in file B.
2812
2813All of the exported names are visible in the file that imports the module.
2814The exported names can be accessed within a namespace based on the module name in the first syntax (ex moduleName.foo).
2815If moduleName has several elements separated by '/' to describe a sub-module (ex. import container/vector;), the last element in the moduleName is used as the namespace to access the visible names in that module (ex vector.add(...);).
2816The as keyword is used to confine the imported names in a unique namespace (ex. anotherName.foo). anotherName must be a valid identifier (same rules as a variable name) which means it cannot have '/' in it.
2817Conflicts in namespaces will be reported by the compiler.
2818The second method can be used to solve conflicting name problems.
2819The following code snippets show the two situations.
2820
2821\begin{lstlisting}
2822module util/counter;
2823export int f(int i) { return i+1; }
2824
2825import util/counter;
2826
2827int main() {
2828        return counter.f(200); // f() from the package counter
2829}
2830
2831import util/counter as ct;
2832int main() {
2833        return ct.f(200); // f() from the package counter
2834}
2835\end{lstlisting}
2836
2837
2838Additionally, 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.
2839
2840\begin{lstlisting}
2841module M1;
2842export int f(int i) { return i+1;} // visible outside
2843
2844int g(int i) { return i-1;} // not visible outside
2845
2846module M2;
2847int f(int i) { return i * 2; } // not visible outside
2848export int g(int g) { return i / 2; } // visible outside
2849
2850import M1 as .;
2851
2852import M2 as .;
2853
2854
2855int main() {
2856        return f(3) + g(4); //f() from M1 and g() from M2;
2857}
2858\end{lstlisting}
2859
2860
2861\subsubsection{Sub-Module and Module Aggregation}
2862
2863Several modules can be organized in a parent module and sub-modules relationship.
2864The sub-module names are based on hierarchical naming, and use slash, "/", to indicate the relationship.
2865For example, std/vector and std/io are sub-modules of module std.
2866The exported names in a sub-module are NOT visible if the parent module is imported, which means the exported names in the sub-module are
2867not implicitly exported in the parent module.
2868
2869Aggregation is a mechanism to support components and simplified importing.
2870The mechanism is not based on naming but based on manual declaration.
2871For example, the following is the aggregated sequence module.
2872The export {...} is syntactic sugar for many lines of export module aModule;.
2873If an aggregated module is imported, all the included modules in the aggregation are imported.
2874
2875\begin{lstlisting}
2876module std/sequence;
2877
2878export {
2879        module std/vector;
2880        module std/list;
2881        module std/array;
2882        module std/deque;
2883        module std/forward_list;
2884        module std/queue;
2885        module std/stack;
2886};
2887\end{lstlisting}
2888
2889After importing the aggregated module, each individual name is still contained in the original name space.
2890For example, vector.add() and list.add() should be used to reference the add methods if there are add methods in both the vector module and the list module.
2891
2892
2893\subsubsection{Import from Repository}
2894
2895When a module is imported, the tools locate the module in the one of the accessible package paths (defined by command line flag or environment variable).
2896The tools also support retrieving modules of a package from external repositories.
2897See Listing 40: Package directory structure
2898
2899
2900\subsubsection{Package Import}
2901
2902Because packages are the places where the building tool looks for modules, there is no code required in the \CFA source file to import a package.
2903In order to use modules in a package, the programmer needs to guide the building tool to locate the right package by 1) Adding the package's parent path into \$DOPATH;
2904or 2) Adding the package dependence into the current project's Do.prj.
2905More details about locating a module in a package are explained in the next section.
2906
2907
2908\subsubsection{Package Versioning}
2909
2910A package must have a version number.
2911The version number is a string.
2912For example "1.0", "1.a", "A1", and "1ec5fab753eb979d3886a491845b8ae152d58c8f" are all valid version numbers.
2913By convention, a package is stored in a directory named packageName-packageVersion.
2914For example, the util package with version 1.1 is stored in a directory named util-1.1.
2915
2916The project description file can optionally specify the version of the package used in the current project.
2917If not defined, because the version number is a string, and all the different versions for the same package will be sorted in increasing order, the package with the largest version number will be used in the compilation.
2918The builder tool will record the specific package version used in the build in the project's "Do.lock" file to enable fully repeatable builds.
2919
2920
2921\subsection{Module and Package Organization}
2922
2923\CFA has two level of encapsulations, module and package.
2924This section explains the object model of modules, packages and other language concepts.
2925It also explains how programmers should organize their code, and the method used by the build tools to locate packages, and import modules for compilation.
2926
2927
2928\subsubsection{Object Model}
2929
2930There are several concepts in Do.
2931\begin{itemize}
2932\item
2933File: a \CFA source file
2934\item
2935Module: a container to organize a set of related types and methods; It has a module name, and several interfaces visible from outside
2936\item
2937Package: a container to organize modules for distribution; It has attributes like name, author,
2938version, dependences, etc.
2939\item
2940Project: a working set for a \CFA project; It has attributes like name, author, version, dependences, etc.
2941\end{itemize}
2942
2943The following rules summarize the object model of all the above concepts:
2944\begin{itemize}
2945\item
2946A module contains one or more files
2947\begin{itemize}
2948\item
2949One file can only belong to one module
2950\item
2951A module has its name and interfaces exported
2952\item
2953A file without a module declaration at the beginning belongs to the global module
2954\item
2955\end{itemize}
2956
2957\item
2958A package contains one or more modules
2959\begin{itemize}
2960\item
2961A package has additional meta info described in Do.prj file
2962\item
2963A package may be dependent on other packages.
2964\end{itemize}
2965
2966\item
2967A project contains one or more modules in its source code
2968\begin{itemize}
2969\item
2970A project has additional meta info described in Do.prj file
2971\item
2972A project may be dependent on other packages
2973\item
2974A project can be transformed into a package for distribution
2975\item
2976A project can generate one or more executable binaries
2977\end{itemize}
2978\end{itemize}
2979
2980
2981\subsubsection{Module File Organization}
2982
2983The rules of this section are the conventions to organize module files in one package.
2984
2985The file location of a module in a package must match the module/submodule naming hierarchy.
2986The names separated by slash "/" must match the directory levels.
2987If only one file is used to implement one module, there is no need to put the module implementation file inside a sub-directory.
2988The file can be put inside its parent module's sub-directory with the sub module's name as the file name.
2989
2990Here is an example of a package, util.
2991\begin{lstlisting}
2992+ util
2993Do.prj #package description file
2994        heap.do #Case 1: module heap;
2995        list.do #Case 1: mdoule list;
2996        ring.do #Case 1: module ring;
2997        + string #Case 2
2998        impl1.do #module string;
2999        + std
3000        vector.do
3001        list.do
3002        + array #Case 3
3003        array1.do #module std/array;
3004        array2.do #module std/array;
3005        sequence.do #Case 4, module std/sequence;
3006        test.do #Case 5
3007\end{lstlisting}
3008
3009\begin{itemize}
3010\item
3011Case 1: Each individual file implements a module
3012\item
3013Case 2: Put the implementation of a module under the sub-directory, but there is only one file
3014\item
3015Case 3: Put the implementation of a module under the sub-directory; There are several files to
3016implement one module
3017\item
3018Case 4: One file to express one aggregation
3019\item
3020Case 5: The file does not belong to any module; It is used for testing purpose
3021\end{itemize}
3022
3023The example only uses source code, ".do" files, to show the module file organization.
3024Other module packaging formats, like binary, must also follow the same rules.
3025
3026
3027\subsection{Module File Format}
3028
3029\CFA supports different types of module file formats.
3030
3031\begin{itemize}
3032\item
3033Pure source code format: The files should be organized following the previous section's definition.
3034\item
3035IR format (TBD): The \CFA compiler IR format, similar to the source code format
3036\item
3037Binary format, including ".a" static library or ".so" dynamic linkage library
3038\begin{itemize}
3039\item
3040The file's name must match the right level's module name defined in the previous section
3041\item
3042E.g. "util.so" includes all modules for the package util.
3043\item
3044E.g. "string.so" under the package directory to include files belonging to "module string;"
3045\end{itemize}
3046\item.
3047Archive format
3048\begin{itemize}
3049\item
3050The archive is named as ".dar", and is a zip archive of the source code or the binary for a package
3051\item
3052E.g. "util.dar" is the whole package for util package including the package direction file
3053\end{itemize}
3054\item
3055Hybrid format
3056\begin{itemize}
3057\item
3058A package can be distributed partly in source code, partly in binary format, and/or packaged in the archive format
3059\item
3060The only limitation is that the names of the files must match the module location names defined in previous section
3061\end{itemize}
3062\end{itemize}
3063Package and Module Locating and the \CFA Language Tooling documentation for more details.
3064
3065
3066\subsection{Packages}
3067
3068A package is synonymous with a library in other languages.
3069The intent of the package level encapsulation is to facilitate code distribution, version control, and dependence management.
3070A package is a physical grouping of one or more modules in a directory (an archive file for a directory).
3071The concept of a package is the convention for grouping code, and the contract between the language and the building tool to search for imported modules.
3072
3073
3074\subsubsection{Package Definition}
3075
3076A package is defined by putting a project description file, Do.prj, with one or more modules into a directory.
3077This project description file contains the package's meta data, including package name, author, version, dependences, etc.
3078It should be in the root of the package directory.
3079
3080The modules in the package could be either source code, or compiled binary format.
3081The location of the module files should follow the module name's path.
3082
3083Here is a simple example of the directory structure of a package, core.
3084It contains a module std and several sub-modules under std.
3085\begin{lstlisting}
3086+ core
3087        Do.prj
3088        + std
3089        + io
3090        file.do # module std/io/file;
3091        network.do #module std/io/network;
3092        + container
3093        vector.do #module std/container/vector;
3094        list.do #module std/container/list;
3095\end{lstlisting}
3096
3097
3098\subsubsection{Package Import}
3099
3100Because packages are the places where the building tool looks for modules, there is no code required in the \CFA source file to import a package.
3101In order to use modules in a package, the programmer needs to guide the building tool to locate the right package by 1) Adding the package's parent path into \$DOPATH; or 2) Adding the package dependence into the current project's Do.prj.
3102More details about locating a module in a package are explained in the next section.
3103
3104
3105\subsubsection{Package Versioning}
3106
3107A package must have a version number.
3108The version number is a string.
3109For example "1.0", "1.a", "A1", and "1ec5fab753eb979d3886a491845b8ae152d58c8f" are all valid version numbers.
3110By convention, a package is stored in a directory named packageName-packageVersion.
3111For example, the util package with version 1.1 is stored in a directory named util-1.1.
3112
3113The project description file can optionally specify the version of the package used in the current project.
3114If not defined, because the version number is a string, and all the different versions for the same package will be sorted in increasing order, the package with the largest version number will be used in the compilation.
3115The builder tool will record the specific package version used in the build in the project's "Do.lock" file to enable fully repeatable builds.
3116
3117
3118\subsection{Module and Package Organization}
3119
3120\CFA has two level of encapsulations, module and package.
3121This section explains the object model of modules, packages and other language concepts.
3122It also explains how programmers should organize their code, and the method used by the build tools to locate packages, and import modules for compilation.
3123
3124
3125\subsubsection{Object Model}
3126
3127There are several concepts in Do.
3128\begin{itemize}
3129\item
3130File: a \CFA source file
3131\item
3132Module: a container to organize a set of related types and methods; It has a module name, and several interfaces visible from outside
3133\item
3134Package: a container to organize modules for distribution; It has attributes like name, author, version, dependences, etc.
3135\item
3136Project: a working set for a \CFA project; It has attributes like name, author, version, dependences, etc.
3137\end{itemize}
3138
3139The following rules summarize the object model of all the above concepts:
3140\begin{itemize}
3141\item
3142A module contains one or more files
3143\begin{itemize}
3144\item
3145One file can only belong to one module
3146\item
3147A module has its name and interfaces exported
3148\item
3149A file without a module declaration at the beginning belongs to the global module
3150\end{itemize}
3151\item
3152A package contains one or more modules
3153\begin{itemize}
3154\item
3155A package has additional meta info described in Do.prj file
3156\item
3157A package may be dependent on other packages.
3158\end{itemize}
3159\item
3160A project contains one or more modules in its source code
3161\begin{itemize}
3162\item
3163A project has additional meta info described in Do.prj file
3164\item
3165A project may be dependent on other packages
3166\item
3167A project can be transformed into a package for distribution
3168\item
3169A project can generate one or more executable binaries
3170\end{itemize}
3171\end{itemize}
3172
3173
3174\subsubsection{Module File Organization}
3175
3176The rules of this section are the conventions to organize module files in one package.
3177
3178The file location of a module in a package must match the module/submodule naming hierarchy.
3179The names separated by slash "/" must match the directory levels.
3180If only one file is used to implement one module, there is no need to put the module implementation file inside a sub-directory.
3181The file can be put inside its parent module's sub-directory with the sub module's name as the file name.
3182
3183Here is an example of a package, util.
3184\begin{lstlisting}
3185+ util
3186        Do.prj #package description file
3187        heap.do #Case 1: module heap;
3188        list.do #Case 1: mdoule list;
3189        ring.do #Case 1: module ring;
3190        + string #Case 2
3191        impl1.do #module string;
3192        + std
3193        vector.do
3194        list.do
3195        + array #Case 3
3196        array1.do #module std/array;
3197        array2.do #module std/array;
3198        sequence.do #Case 4, module std/sequence;
3199        test.do #Case 5
3200\end{lstlisting}
3201
3202
3203\begin{itemize}
3204\item
3205Case 1: Each individual file implements a module
3206\item
3207Case 2: Put the implementation of a module under the sub-directory, but there is only one file
3208\item
3209Case 3: Put the implementation of a module under the sub-directory; There are several files to implement one module
3210\item
3211Case 4: One file to express one aggregation
3212\item
3213Case 5: The file does not belong to any module; It is used for testing purpose
3214\end{itemize}
3215
3216The example only uses source code, ".do" files, to show the module file organization.
3217Other module packaging formats, like binary, must also follow the same rules.
3218
3219
3220\subsubsection{Module File Format}
3221
3222\CFA supports different types of module file formats.
3223
3224\begin{itemize}
3225\item
3226Pure source code format: The files should be organized following the previous section's definition.
3227\item
3228IR format (TBD): The \CFA compiler IR format, similar to the source code format
3229\item
3230Binary format, including ".a" static library or ".so" dynamic linkage library
3231\begin{itemize}
3232\item
3233The file's name must match the right level's module name defined in the previous section
3234\item
3235E.g. "util.so" includes all modules for the package util.
3236\item
3237E.g. "string.so" under the package directory to include files belonging to "module string;"
3238\end{itemize}
3239\item
3240Archive format
3241\begin{itemize}
3242\item
3243The archive is named as ".dar", and is a zip archive of the source code or the binary for a package
3244\item
3245E.g. "util.dar" is the whole package for util package including the package direction file
3246\end{itemize}
3247\item
3248Hybrid format
3249\begin{itemize}
3250\item
3251A package can be distributed partly in source code, partly in binary format, and/or packaged in the archive format
3252\item
3253The only limitation is that the names of the files must match the module location names defined in previous section
3254\end{itemize}
3255\end{itemize}
3256
3257
3258\subsection{Package and Module Locating}
3259
3260The high-level build tools provided by \CFA will handle finding a package in your local filesystem or retrieving it from a repository if necessary, building it if necessary, and linking with it.
3261If a programmer prefers, one can directly call the compiler, docc to build the source files and create and link to static libraries.
3262
3263When a source file imports a module, the \CFA build tool and docc compiler will locate the module according to the following order:
3264
3265\begin{enumerate}
3266\item
3267This source file's directory tree, which is typically the project's src directory
3268\item
3269All of the dependent packages (in a directory or in an archive file) under the current \CFA project's pkg directory
3270\item
3271The dependent packages (in a directory or in an archive file) inside the paths defined in the DOPATH environment variable
3272\item
3273The dependent packages (in a directory or in an archive file) inside the global \CFA SDK installation's pkg directory
3274\item
3275If one dependent package is still not found, the builder tool will automatically retrieve it from the repository defined in the SDK installation's configuration, and store it in the SDK's pkg directory
3276\end{enumerate}
3277
3278The module found first in a package will shadow the modules with the same name in the later packages in the search sequence.
3279
3280
3281\subsubsection{Dependent Package}
3282
3283Dependent packages are those packages containing modules that the current project's source code will import from.
3284Dependent packages are defined implicitly or explicitly in one \CFA project.
3285All of the packages under the current project's pkg directory are implicitly dependent packages.
3286For others, the dependent packages must be defined in the project's Do.prj file.
3287
3288
3289\subsubsection{Package and Module Locating Example}
3290
3291\begin{lstlisting}
3292# A project's source code tree
3293
3294--------------------------------------
3295
3296+ testProject
3297        Do.prj
3298        + src
3299        main.do
3300        + pkg
3301        + security-1.1
3302        Do.prj
3303        security.do #module security
3304
3305--------------------------------------
3306
3307# Do.prj
3308
3309--------------------------------------
3310
3311[dependences]
3312std
3313util = "0.2"
3314
3315--------------------------------------
3316
3317# main.do
3318
3319---------------------------------------
3320
3321import security;
3322import std/vector;
3323import container;
3324
3325----------------------------------------
3326\end{lstlisting}
3327
3328
3329\begin{lstlisting}
3330# pkg directory's source code tree
3331
3332-----------------------------------------
3333
3334+ pkg
3335        + std-1.0
3336        Do.prj
3337        vector.do #module std/vector;
3338        queue.do #module std/queue;
3339        + std-1.1
3340        Do.prj
3341        vector.do #module std/vector;
3342        queue.do #module std/queue;
3343        list.do #module std/list;
3344        + util-0.1
3345        Do.prj
3346        container.do #module container;
3347        + security-1.0
3348        security.do #module security;
3349------------------------------------------
3350\end{lstlisting}
3351
3352
3353During the compiling of main.do file import security;
3354The security module appears in both the local security-1.1 package, and the global security-1.0 package.
3355According to the locating sequence, the local security module in security-1.1 will be used.
3356And because the security-1.1 package is under local's pkg directory.
3357No dependence description is required in the project Do.prj file.
3358
3359import std/vector;
3360
3361The std/vector package appears in two different versions' packages in the global path and the project dependence doesn't specify the version. std-1.1 is used in this case.
3362
3363import container;
3364
3365The Do.prj specifies the version 0.2 should be used to locate container module from util package but only version 0.1 is available in the local file system.
3366The builder tool then will try to retrieve it from the web and store it in the global pkg directory.
3367After that, the container module from the newly downloaded package will be used in the compilation.
3368\end{comment}
3369
3370
3371\section{Comparison with Other Languages}
3372
3373\CFA is one of many languages that attempts to improve upon C.
3374In developing \CFA, many other languages were consulted for ideas, constructs, and syntax.
3375Therefore, it is important to show how these languages each compare with Do.
3376In this section, \CFA is compared with what the writers of this document consider to be the closest competitors of Do: \CC, Go, Rust, and D.
3377
3378
3379\subsection{Comparing Key Features of \CFA}
3380
3381
3382\subsubsection{Constructors and Destructors}
3383
3384\lstset{basicstyle=\sf\relsize{-2}}
3385
3386\begin{flushleft}
3387\begin{tabular}{@{}l|l|l|l@{}}
3388\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
3389\hline
3390\begin{lstlisting}
3391struct Line {
3392        float length;
3393}
3394// default constructor
3395void ?{}( Line * l ) {
3396        sout | "default" | endl;
3397        l.length = 0.0;
3398}
3399
3400
3401// constructor with length
3402void ?{}( Line * l, float length ) {
3403        sout | "length" | length | endl;
3404
3405        l.length = length;
3406}
3407
3408// destructor
3409void ^?(Line &l) {
3410        sout | "destroyed" | endl;
3411        l.length = 0.0;
3412}
3413
3414// usage
3415Line line1;
3416Line line2{ 3.4 };
3417\end{lstlisting}
3418&
3419\begin{lstlisting}[language=C++]
3420class Line {
3421        float length;
3422
3423        // default constructor
3424        Line() {
3425                cout << "default" << endl;
3426                length = 0.0;
3427        }
3428
3429
3430        // constructor with length
3431        Line( float l ) {
3432                cout << "length " << length
3433                         << endl;
3434                length = l;
3435        }
3436
3437        // destructor
3438        ~Line() {
3439                cout << "destroyed" << endl;
3440                length = 0.0;
3441        }
3442}
3443// usage
3444Line line1;
3445Line line2( 3.4 );
3446\end{lstlisting}
3447&
3448\begin{lstlisting}[language=Golang]
3449type Line struct {
3450        length float32
3451}
3452// default constructor
3453func makeLine() Line {
3454        fmt.PrintLn( "default" )
3455        return Line{0.0}
3456}
3457
3458
3459// constructor with length
3460func makeLine( length float32 ) Line {
3461        fmt.Printf( "length %v", length )
3462
3463        return Line{length}
3464}
3465
3466// no destructor
3467
3468
3469
3470
3471
3472// usage
3473line1 := makeLine()
3474line2 := makeLine( 3.4 )
3475\end{lstlisting}
3476&
3477\begin{lstlisting}
3478struct Line {
3479        length: f32
3480}
3481// default constructor
3482impl Default for Line {
3483        fn default () -> Line {
3484                println!( "default" );
3485                Line{ length: 0.0 }
3486        }
3487}
3488// constructor with length
3489impl Line {
3490        fn make( len: f32 ) -> Line {
3491                println!( "length: {}", len );
3492                Line{ length: len }
3493        }
3494}
3495// destructor
3496impl Drop for Line {
3497        fn drop( &mut self ) {
3498                self.length = 0.0
3499        }
3500}
3501// usage
3502let line1:Line = Default::default();
3503Line line2( 3.4 );
3504\end{lstlisting}
3505\end{tabular}
3506\end{flushleft}
3507
3508
3509\subsubsection{Operator Overloading}
3510
3511\begin{flushleft}
3512\begin{tabular}{@{}l|l|l|l@{}}
3513\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
3514\hline
3515\begin{lstlisting}
3516struct Cpx {
3517        double re, im;
3518};
3519// overload addition operator
3520Cpx ?+?( Cpx l, const Cpx r ) {
3521        return (Cpx){l.re+l.im, l.im+r.im};
3522}
3523Cpx a, b, c;
3524c = a + b;
3525\end{lstlisting}
3526&
3527\begin{lstlisting}
3528struct Cpx {
3529        double re, im;
3530};
3531// overload addition operator
3532Cpx operator+( Cpx l, const Cpx r ) {
3533        return (Cpx){l.re+l.im, l.im+r.im};
3534}
3535Cpx a, b, c;
3536c = a + b;
3537\end{lstlisting}
3538&
3539\begin{lstlisting}
3540// no operator overloading
3541
3542
3543
3544
3545
3546
3547
3548\end{lstlisting}
3549&
3550\begin{lstlisting}
3551struct Cpx {
3552        re: f32,
3553        im: f32
3554}
3555// overload addition operator
3556impl Add for Cpx {
3557        type Output = Cpx
3558        fn add(self, r: Cpx) -> Cpx {
3559                let mut res = Cpx{re: 0.0, im: 0.0};
3560                res.re = self.re + r.re;
3561                res.im = self.im + r.im;
3562                return res
3563        }
3564}
3565let (a, b, mut c) = ...;
3566c = a + b
3567\end{lstlisting}
3568\end{tabular}
3569\end{flushleft}
3570
3571
3572\subsubsection{Calling C Functions}
3573
3574\begin{flushleft}
3575\begin{tabular}{@{}l|l|l@{}}
3576\multicolumn{1}{c|}{\textbf{\CFA/\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}   \\
3577\hline
3578\begin{lstlisting}[boxpos=t]
3579extern "C" {
3580#include <sys/types.h>
3581#include <sys/stat.h>
3582#include <unistd.h>
3583}
3584size_t fileSize( const char *path ) {
3585        struct stat s;
3586        stat(path, &s);
3587        return s.st_size;
3588}
3589\end{lstlisting}
3590&
3591\begin{lstlisting}[boxpos=t]
3592/*
3593#cgo
3594#include <sys/types.h>
3595#include <sys/stat.h>
3596#include <unistd.h>
3597*/
3598import "C"
3599import "unsafe"
3600
3601func fileSize(path string) C.size_t {
3602        var buf C.struct_stat
3603        c_string := C.CString(path)
3604        C.stat(p, &buf)
3605        C.free(unsafe.Pointer(c_string))
3606        return buf._st_size
3607}
3608\end{lstlisting}
3609&
3610\begin{lstlisting}[boxpos=t]
3611use libc::{c_int, size_t};
3612// translated from sys/stat.h
3613#[repr(C)]
3614struct stat_t {
3615        ...
3616        st_size: size_t,
3617        ...
3618}
3619#[link(name = "libc")]
3620extern {
3621        fn stat(path: *const u8,
3622        buf: *mut stat_t) -> c_int;
3623}
3624fn fileSize(path: *const u8) -> size_t
3625{
3626        unsafe {
3627                let mut buf: stat_t = uninit();
3628                stat(path, &mut buf);
3629                buf.st_size
3630        }
3631}
3632\end{lstlisting}
3633\end{tabular}
3634\end{flushleft}
3635
3636
3637\subsubsection{Generic Functions}
3638
3639\begin{flushleft}
3640\begin{tabular}{@{}l|l|l|l@{}}
3641\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
3642\hline
3643\begin{lstlisting}
3644generic(type T, type N |
3645        { int ?<?(N, N); })
3646T *maximize(N (*f)(const T&),
3647        int n, T *a) {
3648        T *bestX = NULL;
3649        N bestN;
3650        for (int i = 0; i < n; i++) {
3651        N curN = f(a[i]);
3652        if (bestX == NULL ||
3653        curN > bestN) {
3654        bestX = &a[i]; bestN = curN;
3655        }
3656        }
3657        return bestX;
3658}
3659
3660string *longest(int n, string *p)
3661{
3662        return maximize(length, n, p);
3663}
3664\end{lstlisting}
3665&
3666\begin{lstlisting}
3667template<typename T, typename F>
3668T *maximize(const F &f,
3669        int n, T *a) {
3670        typedef decltype(f(a[0])) N;
3671        T *bestX = NULL;
3672        N bestN;
3673        for (int i = 0; i < n; i++) {
3674        N curN = f(a[i]);
3675        if (bestX == NULL || curN > bestN)
3676        {
3677        bestX = &a[i]; bestN = curN;
3678        }
3679        }
3680        return bestX;
3681}
3682
3683string *longest(int n, string *p) {
3684        return maximize(
3685        [](const string &s) {
3686        return s.length();
3687        }, n, p);
3688}
3689\end{lstlisting}
3690&
3691\begin{lstlisting}
3692// Go does not support generics!
3693func maximize(
3694        gt func(interface{}, interface{}) bool,
3695        f func(interface{}) interface{},
3696        a []interface{}) interface{} {
3697        var bestX interface{} = nil
3698        var bestN interface{} = nil
3699        for _, x := range a {
3700        curN := f(x)
3701        if bestX == nil || gt(curN, bestN)
3702        {
3703        bestN = curN
3704        bestX = x
3705        }
3706        }
3707        return bestX
3708}
3709
3710func longest(
3711        a []interface{}) interface{} {
3712        return maximize(
3713        func(a, b interface{}) bool {
3714        return a.(int) > b.(int) },
3715        func(s interface{}) interface{} {
3716        return len(s.(string)) },
3717        a).(string)
3718}
3719\end{lstlisting}
3720&
3721\begin{lstlisting}
3722use std::cmp::Ordering;
3723
3724fn maximize<N: Ord + Copy, T, F:
3725Fn(&T) -> N>(f: F, a: &Vec<T>) ->
3726Option<&T> {
3727        let mut best_x: Option<&T> = None;
3728        let mut best_n: Option<N> = None;
3729        for x in a {
3730        let n = f(x);
3731        if (match best_n { None => true,
3732        Some(bn) =>
3733        n.cmp(&bn) == Ordering::Greater })
3734        {
3735        best_x = Some(x);
3736        best_n = Some(n);
3737        }
3738        }
3739        return best_x
3740}
3741
3742fn longest(a: &Vec<String>) ->
3743        Option<&String> {
3744        return
3745        maximize(|x: &String| x.len(), a)
3746}
3747\end{lstlisting}
3748\end{tabular}
3749\end{flushleft}
3750
3751
3752\begin{comment}
3753\subsubsection{Modules/Packages}
3754
3755\begin{lstlisting}
3756\CFA
3757\CC
3758
3759
3760module example/M;
3761
3762export int inc(int val) {
3763        return val + 1;
3764}
3765
3766
3767
3768
3769--------------------------------------
3770//Use the module in another file
3771import example/M;
3772int main() {
3773        print(M.inc(100));
3774        return 0;
3775}
3776// Using \CC17 module proposal
3777
3778module example.M;
3779
3780export {
3781        int inc(int val);
3782}
3783
3784int inc(inv val) {
3785        return val + 1;
3786}
3787--------------------------------------
3788// Use the module in another file
3789import example.M;
3790int main() {
3791        cout << inc(100) << endl;
3792        return 0;
3793}
3794
3795Go
3796Rust
3797package example/M;
3798
3799func Inc(val int32) int32 {
3800        // Capitalization indicates exported
3801        return val + 100
3802}
3803
3804
3805--------------------------------------
3806//Use the package in another file
3807package main
3808import .fmt.
3809import "example/M"
3810
3811func main() int32 {
3812        fmt.Printf(.%v., M.Inc(100))
3813}
3814pub mod example {
3815        pub mod M {
3816        pub inc(val i32) -> i32 {
3817        return val + 100;
3818        }
3819        }
3820}
3821
3822--------------------------------------
3823//Use the module in another file
3824use example::M;
3825
3826
3827
3828fn main() {
3829        println!(.{}., M::inc(100));
3830}
3831\end{lstlisting}
3832\end{comment}
3833
3834
3835\subsubsection{Parallel Tasks}
3836
3837\begin{flushleft}
3838\begin{tabular}{@{}l|l|l|l@{}}
3839\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
3840\hline
3841\begin{lstlisting}
3842task Nonzero {
3843        int *data;
3844        int start;
3845        int end;
3846        int* res;
3847};
3848
3849void ?{}(Nonzero &a, int d[], int s,
3850        int e, int* subres) {
3851        // constructor
3852        a.data = d;
3853        a.start = s;
3854        a.end = e;
3855        a.res = subres;
3856}
3857
3858// implicitly spawn thread here
3859void ?()(NonzeroCounter &a) {
3860        int i;
3861        int nonzero = 0;
3862        for (i=start; c<end; ++i) {
3863        if(a.data[i]!=0){ nonzero++;}
3864        }
3865        *a.res = nonzero;
3866}
3867
3868int main() {
3869        int sz = ...
3870        int data[sz] = ...;
3871        int r1 = 0, r2=0;
3872        int res;
3873        { // create a scope for Nonzero
3874        Nonzero n1{data, 0, sz/2, &n1};
3875        Nonzero n2{data, sz/2, sz, &n2};
3876        n1();//spawn
3877        n2();//spawn
3878        }
3879        res = r1+r2;
3880        return res;
3881}
3882\end{lstlisting}
3883&
3884\begin{lstlisting}
3885#include <thread>
3886#include <mutex>
3887
3888std::mutex m;
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901void task(const vector<int>&v,
3902        int* res, size_t s,
3903        size_t e) {
3904        int non_zero = 0;
3905        for(size_t i = s; i < e; ++i){
3906        if(v[i]!=0) { non_zero++;}
3907        }
3908        std::unique_lock<mutex> lck {m};
3909        *res += non_zero;
3910}
3911
3912int main() {
3913        vector<int> data = ...; //data
3914        int res = 0;
3915        std::thread t1 {task, ref(data),
3916        &res, 0,
3917        data.size()/2};
3918        std::thread t2 {task, ref(data),
3919        &res, data.size()/2,
3920        data.size()};
3921        t1.join();
3922        t2.join();
3923        return res;
3924}
3925\end{lstlisting}
3926&
3927\begin{lstlisting}
3928package main
3929
3930import "fmt"
3931
3932func nonzero(data []int, c chan int) {
3933        nz := 0
3934        for _, v:=range data {
3935        if(v!=0) { nz := nz+1 }
3936        }
3937        c <- nz
3938}
3939
3940func main() {
3941        sz := ...
3942        data := make([]int, sz)
3943        ... // data init
3944        go nonzero(data[:len(data)/2], c)
3945        go nonzero(data[len(data)/2:], c)
3946        n1, n2 := <-c, <-c
3947        res := n1 + n2
3948        fmt.Println(res)
3949}
3950\end{lstlisting}
3951&
3952\begin{lstlisting}
3953use std::thread;
3954use std::sync:mpsc::channel;
3955
3956fn main() {
3957        let sz = ...;
3958        let mut data:Vec<i32> =
3959        Vec::with_capacity(sz as usize);
3960        ... //init data
3961        let (tx, rx) = channel();
3962        for i in 0..1 {
3963        let tx = tx.clone();
3964        let data = data.clone()
3965        thread::spawn(move|| {
3966        let mut nz := 0;
3967        let mut s = 0;
3968        let mut e = sz / 2;
3969        if i == 1 {
3970        s = sz/2;
3971        e = data.len();
3972        }
3973        for i in s..(e - 1) {
3974        if data[i] != 0 (
3975        nz = nz + 1
3976        }
3977        }
3978        tx.send(nz).unwrap();
3979        });
3980        }
3981        let res = rx.recv().unwrap() +
3982        rx.recv().unwrap();
3983        println!(.{}., res);
3984}
3985\end{lstlisting}
3986\end{tabular}
3987\end{flushleft}
3988
3989\lstset{basicstyle=\sf\relsize{-1}}
3990
3991
3992\subsection{Summary of Language Comparison}
3993
3994
3995\subsubsection{\CC}
3996
3997\CC is a general-purpose programming language.
3998It has imperative, object-oriented and generic programming features, while also providing facilities for low-level memory manipulation. (Wikipedia)
3999
4000The primary focus of \CC seems to be adding object-oriented programming to C, and this is the primary difference between \CC and Do.
4001\CC uses classes to encapsulate data and the functions that operate on that data, and to hide the internal representation of the data.
4002\CFA uses modules instead to perform these same tasks.
4003Classes in \CC also enable inheritance among types.
4004Instead of inheritance, \CFA embraces composition and interfaces to achieve the same goals with more flexibility.
4005There are many studies and articles comparing inheritance and composition (or is-a versus has-a relationships), so we will not go into more detail here (Venners, 1998) (Pike, Go at Google: Language Design in the Service of Software Engineering , 2012).
4006
4007Overloading in \CFA is very similar to overloading in \CC, with the exception of the additional use, in \CFA, of the return type to differentiate between overloaded functions.
4008References and exceptions in \CFA are heavily based on the same features from \CC.
4009The mechanism for interoperating with C code in \CFA is also borrowed from \CC.
4010
4011Both \CFA and \CC provide generics, and the syntax is quite similar.
4012The key difference between the two, is that in \CC templates are expanded at compile time for each type for which the template is instantiated, while in \CFA, function pointers are used to make the generic fully compilable.
4013This means that a generic function can be defined in a compiled library, and still be used as expected from source.
4014
4015
4016\subsubsection{Go}
4017
4018Go, also commonly referred to as golang, is a programming language developed at Google in 2007 [.].
4019It is a statically typed language with syntax loosely derived from that of C, adding garbage collection, type
4020safety, some structural typing capabilities, additional built-in types such as variable-length arrays and key-value maps, and a large standard library. (Wikipedia)
4021
4022Go and \CFA differ significantly in syntax and implementation, but the underlying core concepts of the two languages are aligned.
4023Both Go and \CFA use composition and interfaces as opposed to inheritance to enable encapsulation and abstraction.
4024Both languages (along with their tooling ecosystem) provide a simple packaging mechanism for building units of code for easy sharing and reuse.
4025Both languages also include built-in light weight, user level threading concurrency features that attempt to simplify the effort and thought process required for writing parallel programs while maintaining high performance.
4026
4027Go has a significant runtime which handles the scheduling of its light weight threads, and performs garbage collection, among other tasks.
4028\CFA uses a cooperative scheduling algorithm for its tasks, and uses automatic reference counting to enable advanced memory management without garbage collection.
4029This results in Go requiring significant overhead to interface with C libraries while \CFA has no overhead.
4030
4031
4032\subsubsection{Rust}
4033
4034Rust is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.
4035It is designed to be a "safe, concurrent, practical language", supporting pure-functional, concurrent-actor[dubious . discuss][citation needed], imperative-procedural, and object-oriented styles.
4036
4037The primary focus of Rust is in safety, especially in concurrent programs.
4038To enforce a high level of safety, Rust has added ownership as a core feature of the language to guarantee memory safety.
4039This safety comes at the cost of a difficult learning curve, a change in the thought model of the program, and often some runtime overhead.
4040
4041Aside from those key differences, Rust and \CFA also have several similarities.
4042Both languages support no overhead interoperability with C and have minimal runtimes.
4043Both languages support inheritance and polymorphism through the use of interfaces (traits).
4044
4045
4046\subsubsection{D}
4047
4048The D programming language is an object-oriented, imperative, multi-paradigm system programming
4049language created by Walter Bright of Digital Mars and released in 2001. [.]
4050Though it originated as a re-engineering of \CC, D is a distinct language, having redesigned some core \CC features while also taking inspiration from other languages, notably Java, Python, Ruby, C\#, and Eiffel.
4051
4052D and \CFA both start with C and add productivity features.
4053The obvious difference is that D uses classes and inheritance while \CFA uses composition and interfaces.
4054D is closer to \CFA than \CC since it is limited to single inheritance and also supports interfaces.
4055Like \CC, and unlike \CFA, D uses garbage collection and has compile-time expanded templates.
4056D does not have any built-in concurrency constructs in the
4057language, though it does have a standard library for concurrency which includes the low-level primitives for concurrency.
4058
4059
4060\appendix
4061
4062
4063\section{I/O Library}
4064\label{s:IOLibrary}
4065\index{input/output library}
4066
4067The goal for \CFA I/O is to make I/O as simple as possible for the general case, while fully supporting polmorphism and user defined types in a consistent way.
4068The general case is printing out a sequence of variables separated by whitespace.
4069\begin{quote2}
4070\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
4071\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{\CC}}      \\
4072\begin{lstlisting}
4073int x = 0, y = 1, z = 2;
4074`sout` `|` x `|` y `|` z `| endl`;
4075\end{lstlisting}
4076&
4077\begin{lstlisting}
4078
4079cout << x << " " << y << " " << z << endl;
4080\end{lstlisting}
4081\end{tabular}
4082\end{quote2}
4083The \CFA form is half as many characters, and is similar to Python I/O with respect to implicit separators.
4084
4085The logical-or operator is used because it is the lowest-priority overloadable operator, other than assignment.
4086Therefore, fewer output expressions require parenthesis.
4087\begin{quote2}
4088\begin{tabular}{@{}ll@{}}
4089\textbf{\CFA:}
4090&
4091\begin{lstlisting}
4092sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
4093\end{lstlisting}
4094\\
4095\textbf{\CC:}
4096&
4097\begin{lstlisting}
4098cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
4099\end{lstlisting}
4100\end{tabular}
4101\end{quote2}
4102Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, although data flows in the opposite direction.
4103
4104The implicit seperator\index{I/O separator} character (space/blank) is a separator not a terminator.
4105The rules for implicitly adding the separator are:
4106\begin{enumerate}
4107\item
4108A seperator does not appear at the start or end of a line.
4109\begin{lstlisting}[belowskip=0pt]
4110sout 1 | 2 | 3 | endl;
4111\end{lstlisting}
4112\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
41131 2 3
4114\end{lstlisting}
4115\item
4116A seperator does not appear before or after a character literal or variable.
4117\begin{lstlisting}
4118sout | '1' | '2' | '3' | endl;
4119123
4120\end{lstlisting}
4121\item
4122A seperator does not appear before or after a null (empty) C string
4123\begin{lstlisting}
4124sout | 1 | "" | 2 | "" | 3 | endl;
4125123
4126\end{lstlisting}
4127which is a local mechanism to disable insertion of the separator character.
4128\item
4129A seperator does not appear before a C string starting with the \Index{extended ASCII}\index{ASCII} characters: \lstinline[mathescape=off]@([{$£¥¿«@
4130%$
4131\begin{lstlisting}[mathescape=off]
4132sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¿" | 7 | "x «" | 8 | endl;
4133\end{lstlisting}
4134%$
4135\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
4136x (1 x [2 x {3 x $4 x £5 x ¥6 x ¿7 x «8
4137\end{lstlisting}
4138%$
4139\item
4140A seperator does not appear after a C string ending with the extended ASCII characters: \lstinline@,.:;!?)]}%¢»@
4141\begin{lstlisting}[belowskip=0pt]
4142sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"
4143         | 10 | "% x" | 11 | L"¢ x" | 12 | L"» x" | endl;
4144\end{lstlisting}
4145\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
41461, x 2. x 3: x 4; x 5! x 6? x 7) x 8] x 9} x 10% x 11¢ 12»
4147\end{lstlisting}
4148\item
4149A seperator does not appear before or after a C string begining/ending with the characters: \lstinline@\f\n\r\t\v\`'"@
4150\begin{lstlisting}[belowskip=0pt]
4151sout | "x '" | 1 | "' x \`" | 2 | "\` x \"" | 3 | "\" x" | endl;
4152\end{lstlisting}
4153\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
4154x '1' x \`2\` x "3" x
4155\end{lstlisting}
4156\begin{lstlisting}[showtabs=true,aboveskip=0pt]
4157sout | "x\t" | 1 | "\tx" | endl;
4158x       1       x
4159\end{lstlisting}
4160\end{enumerate}
4161The following \CC-style \Index{manipulator}s allow further control over implicit seperation.
4162\begin{lstlisting}[mathescape=off,belowskip=0pt]
4163sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
4164\end{lstlisting}
4165\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
4166 1 2 3
4167\end{lstlisting}
4168\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
4169sout | 1 | sepOff | 2 | 3 | endl;                       // turn off implicit separator temporarily
4170\end{lstlisting}
4171\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
417212 3
4173\end{lstlisting}
4174\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
4175sout | sepDisable | 1 | 2 | 3 | endl;           // turn off implicit separation, affects all subsequent prints
4176\end{lstlisting}
4177\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
4178123
4179\end{lstlisting}
4180\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
4181sout | 1 | sepOn | 2 | 3 | endl;                        // turn on implicit separator temporarily
4182\end{lstlisting}
4183\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
41841 23
4185\end{lstlisting}
4186\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
4187sout | sepEnable | 1 | 2 | 3 | endl;            // turn on implicit separation, affects all subsequent prints
4188\end{lstlisting}
4189\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
41901 2 3
4191\end{lstlisting}
4192\begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
4193sepSet( sout, ", $" );                                          // change separator from " " to ", $"
4194sout | 1 | 2 | 3 | endl;
4195\end{lstlisting}
4196%$
4197\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt]
41981, $2, $3
4199\end{lstlisting}
4200%$
4201\VRef[Figure]{f:ExampleIO} shows an example of input and output I/O in \CFA.
4202
4203\begin{figure}
4204\begin{lstlisting}[mathescape=off]
4205#include <fstream>
4206
4207int main() {
4208        char c;                                                                                                         // basic types
4209        short int si;
4210        unsigned short int usi;
4211        int i;
4212        unsigned int ui;
4213        long int li;
4214        unsigned long int uli;
4215        long long int lli;
4216        unsigned long long int ulli;
4217        float f;
4218        double d;
4219        long double ld;
4220        float _Complex fc;
4221        double _Complex dc;
4222        long double _Complex ldc;
4223        char s1[10], s2[10];
4224
4225        ifstream in;                                                                                            // create / open file
4226        open( &in, "input.data", "r" );
4227
4228        &in | &c                                                                                                        // character
4229                | &si | &usi | &i | &ui | &li | &uli | &lli | &ulli             // integral
4230                | &f | &d | &ld                                                                                 // floating point
4231                | &fc | &dc | &ldc                                                                              // floating-point complex
4232                | cstr( s1 ) | cstr( s2, 10 );                                                  // C string, length unchecked and checked
4233
4234        sout | c | ' ' | endl                                                                           // character
4235                 | si | usi | i | ui | li | uli | lli | ulli | endl             // integral
4236                 | f | d | ld | endl                                                                    // floating point
4237                 | fc | dc | ldc | endl;                                                                // complex
4238        sout | endl;
4239        sout | f | "" | d | "" | ld | endl                                                      // floating point without separator
4240                 | sepDisable | fc | dc | ldc | sepEnable | endl                // complex without separator
4241                 | sepOn | s1 | sepOff | s2 | endl                                              // local separator removal
4242                 | s1 | "" | s2 | endl;                                                                 // C string withou separator
4243        sout | endl;
4244        sepSet( sout, ", $" );                                                                          // change separator, maximum of 15 characters
4245        sout | f | d | ld | endl                                                                        // floating point without separator
4246                 | fc | dc | ldc | endl                                                                 // complex without separator
4247                 | s1 | s2 | endl;
4248}
4249
4250$ cat input.data
4251A 1 2 3 4 5 6 7 8 1.1 1.2 1.3 1.1+2.3 1.1-2.3 1.1-2.3 abc xyz
4252$ a.out
4253A
42541 2 3 4 5 6 7 8
42551.1 1.2 1.3
42561.1+2.3i 1.1-2.3i 1.1-2.3i
4257
42581.11.21.3
42591.1+2.3i1.1-2.3i1.1-2.3i
4260 abcxyz
4261abcxyz
4262
42631.1, $1.2, $1.3
42641.1+2.3i, $1.1-2.3i, $1.1-2.3i
4265abc, $xyz
4266\end{lstlisting}
4267\caption{Example I/O}
4268\label{f:ExampleIO}
4269\end{figure}
4270
4271
4272\section{Standard Library}
4273\label{s:StandardLibrary}
4274
4275The goal of the \CFA standard-library is to wrap many of the existing C library-routines that are explicitly polymorphic into implicitly polymorphic versions.
4276
4277
4278\subsection{malloc}
4279
4280\begin{lstlisting}
4281forall( otype T ) T * malloc( void );
4282forall( otype T ) T * malloc( char fill );
4283forall( otype T ) T * malloc( T * ptr, size_t size );
4284forall( otype T ) T * malloc( T * ptr, size_t size, unsigned char fill );
4285forall( otype T ) T * calloc( size_t size );
4286forall( otype T ) T * realloc( T * ptr, size_t size );
4287forall( otype T ) T * realloc( T * ptr, size_t size, unsigned char fill );
4288
4289forall( otype T ) T * aligned_alloc( size_t alignment );
4290forall( otype T ) T * memalign( size_t alignment );             // deprecated
4291forall( otype T ) int posix_memalign( T ** ptr, size_t alignment );
4292
4293forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
4294forall( otype T ) T * memset( T * ptr );                                // remove when default value available
4295\end{lstlisting}
4296
4297
4298\subsection{ato/strto}
4299
4300\begin{lstlisting}
4301int ato( const char * ptr );
4302unsigned int ato( const char * ptr );
4303long int ato( const char * ptr );
4304unsigned long int ato( const char * ptr );
4305long long int ato( const char * ptr );
4306unsigned long long int ato( const char * ptr );
4307float ato( const char * ptr );
4308double ato( const char * ptr );
4309long double ato( const char * ptr );
4310float _Complex ato( const char * ptr );
4311double _Complex ato( const char * ptr );
4312long double _Complex ato( const char * ptr );
4313
4314int strto( const char * sptr, char ** eptr, int base );
4315unsigned int strto( const char * sptr, char ** eptr, int base );
4316long int strto( const char * sptr, char ** eptr, int base );
4317unsigned long int strto( const char * sptr, char ** eptr, int base );
4318long long int strto( const char * sptr, char ** eptr, int base );
4319unsigned long long int strto( const char * sptr, char ** eptr, int base );
4320float strto( const char * sptr, char ** eptr );
4321double strto( const char * sptr, char ** eptr );
4322long double strto( const char * sptr, char ** eptr );
4323float _Complex strto( const char * sptr, char ** eptr );
4324double _Complex strto( const char * sptr, char ** eptr );
4325long double _Complex strto( const char * sptr, char ** eptr );
4326\end{lstlisting}
4327
4328
4329\subsection{bsearch/qsort}
4330
4331\begin{lstlisting}
4332forall( otype T | { int ?<?( T, T ); } )
4333T * bsearch( const T key, const T * arr, size_t dimension );
4334
4335forall( otype T | { int ?<?( T, T ); } )
4336void qsort( const T * arr, size_t dimension );
4337\end{lstlisting}
4338
4339
4340\subsection{abs}
4341
4342\begin{lstlisting}
4343char abs( char );
4344extern "C" {
4345int abs( int );                         // use default C routine for int
4346} // extern "C"
4347long int abs( long int );
4348long long int abs( long long int );
4349float abs( float );
4350double abs( double );
4351long double abs( long double );
4352float _Complex abs( float _Complex );
4353double _Complex abs( double _Complex );
4354long double _Complex abs( long double _Complex );
4355\end{lstlisting}
4356
4357
4358\subsection{floor/ceil}
4359
4360\begin{lstlisting}
4361float floor( float );
4362extern "C" {
4363double floor( double );         // use C routine for double
4364} // extern "C"
4365long double floor( long double );
4366
4367float ceil( float );
4368extern "C" {
4369double ceil( double );          // use C routine for double
4370} // extern "C"
4371long double ceil( long double );
4372\end{lstlisting}
4373
4374
4375\subsection{random}
4376
4377\begin{lstlisting}
4378void rand48seed( long int s );
4379char rand48();
4380int rand48();
4381unsigned int rand48();
4382long int rand48();
4383unsigned long int rand48();
4384float rand48();
4385double rand48();
4386float _Complex rand48();
4387double _Complex rand48();
4388long double _Complex rand48();
4389\end{lstlisting}
4390
4391
4392\subsection{min/max/swap}
4393
4394\begin{lstlisting}
4395forall( otype T | { int ?<?( T, T ); } )
4396T min( const T t1, const T t2 );
4397
4398forall( otype T | { int ?>?( T, T ); } )
4399T max( const T t1, const T t2 );
4400
4401forall( otype T )
4402void swap( T * t1, T * t2 );
4403\end{lstlisting}
4404
4405
4406\section{Rational Numbers}
4407\label{s:RationalNumbers}
4408
4409Rational numbers are numbers written as a ratio, i.e., as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.
4410When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
4411
4412\begin{lstlisting}
4413// implementation
4414struct Rational {
4415        long int numerator, denominator;                                        // invariant: denominator > 0
4416}; // Rational
4417
4418// constants
4419extern struct Rational 0;
4420extern struct Rational 1;
4421
4422// constructors
4423Rational rational();
4424Rational rational( long int n );
4425Rational rational( long int n, long int d );
4426
4427// getter/setter for numerator/denominator
4428long int numerator( Rational r );
4429long int numerator( Rational r, long int n );
4430long int denominator( Rational r );
4431long int denominator( Rational r, long int d );
4432
4433// comparison
4434int ?==?( Rational l, Rational r );
4435int ?!=?( Rational l, Rational r );
4436int ?<?( Rational l, Rational r );
4437int ?<=?( Rational l, Rational r );
4438int ?>?( Rational l, Rational r );
4439int ?>=?( Rational l, Rational r );
4440
4441// arithmetic
4442Rational -?( Rational r );
4443Rational ?+?( Rational l, Rational r );
4444Rational ?-?( Rational l, Rational r );
4445Rational ?*?( Rational l, Rational r );
4446Rational ?/?( Rational l, Rational r );
4447
4448// conversion
4449double widen( Rational r );
4450Rational narrow( double f, long int md );
4451
4452// I/O
4453forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * );
4454forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational );
4455\end{lstlisting}
4456
4457
4458\bibliographystyle{plain}
4459\bibliography{cfa}
4460
4461
4462\addcontentsline{toc}{section}{\indexname} % add index name to table of contents
4463\begin{theindex}
4464Italic page numbers give the location of the main entry for the referenced term.
4465Plain page numbers denote uses of the indexed term.
4466Entries for grammar non-terminals are italicized.
4467A typewriter font is used for grammar terminals and program identifiers.
4468\indexspace
4469\input{user.ind}
4470\end{theindex}
4471
4472
4473\end{document}
4474
4475% Local Variables: %
4476% tab-width: 4 %
4477% fill-column: 100 %
4478% compile-command: "make" %
4479% End: %
Note: See TracBrowser for help on using the repository browser.