source: doc/user/user.tex @ 554a0db

aaron-thesisarm-ehcleanup-dtorsctordeferred_resndemanglergc_noraiijacob/cs343-translationjenkins-sandboxmemorynew-astnew-ast-unique-exprnew-envno_listpersistent-indexerresolv-newwith_gc
Last change on this file since 554a0db was 9724df0, checked in by Peter A. Buhr <pabuhr@…>, 5 years ago

update latex macros, and user and refrat manuals

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