source: doc/user/user.tex @ 6a48cc9

ADTaaron-thesisarm-ehast-experimentalcleanup-dtorsdeferred_resndemanglerenumforall-pointer-decayjacob/cs343-translationjenkins-sandboxnew-astnew-ast-unique-exprnew-envno_listpersistent-indexerpthread-emulationqualifiedEnumresolv-newwith_gc
Last change on this file since 6a48cc9 was 46e4440e, checked in by Peter A. Buhr <pabuhr@…>, 7 years ago

third attempt at pointer/reference discussion

  • Property mode set to 100644
File size: 241.1 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 : Tue Jun 13 11:50:27 2017
14%% Update Count     : 2403
15%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
16
17% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
18
19\documentclass[twoside,11pt]{article}
20
21%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
22
23% Latex packages used in the document.
24\usepackage[T1]{fontenc}                                % allow Latin1 (extended ASCII) characters
25\usepackage{textcomp}
26\usepackage[latin1]{inputenc}
27% Default underscore is too low and wide. Cannot use lstlisting "literate" as replacing underscore
28% removes it as a variable-name character so keyworks in variables are highlighted
29\DeclareTextCommandDefault{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}
30
31
32\usepackage{fullpage,times,comment}
33\usepackage{epic,eepic}
34\usepackage{upquote}                                                                    % switch curled `'" to straight
35\usepackage{calc}
36\usepackage{xspace}
37\usepackage{varioref}                                                                   % extended references
38\usepackage{listings}                                                                   % format program code
39\usepackage[flushmargin]{footmisc}                                              % support label/reference in footnote
40\usepackage{latexsym}                                   % \Box glyph
41\usepackage{mathptmx}                                   % better math font with "times"
42\usepackage[usenames]{color}
43\usepackage[pagewise]{lineno}
44\renewcommand{\linenumberfont}{\scriptsize\sffamily}
45\input{common}                                          % bespoke macros used in the document
46\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
47\usepackage{breakurl}
48\renewcommand{\UrlFont}{\small\sf}
49
50\setlength{\topmargin}{-0.45in}                                                 % move running title into header
51\setlength{\headsep}{0.25in}
52
53%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
54
55\CFAStyle                                                                                               % use default CFA format-style
56
57% inline code ©...© (copyright symbol) emacs: C-q M-)
58% red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
59% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
60% green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
61% LaTex escape §...§ (section symbol) emacs: C-q M-'
62% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
63% math escape $...$ (dollar symbol)
64
65%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
66
67% Names used in the document.
68\newcommand{\Version}{\input{../../version}}
69\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
70\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
71\newcommand{\R}[1]{\Textbf{#1}}
72\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
73\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
74
75\newsavebox{\LstBox}
76
77%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
78
79\setcounter{secnumdepth}{3}                             % number subsubsections
80\setcounter{tocdepth}{3}                                % subsubsections in table of contents
81\makeindex
82
83%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
84
85\title{\Huge
86\vspace*{1in}
87\CFA (\CFL) User Manual                         \\
88Version 1.0                                                     \\
89\vspace*{0.25in}
90\huge``describe not prescribe''
91\vspace*{1in}
92}% title
93
94\author{
95\huge \CFA Team \medskip \\
96\Large Andrew Beach, Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
97\Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
98}% author
99
100\date{
101DRAFT \\ \today
102}% date
103
104%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
105
106\begin{document}
107\pagestyle{headings}
108% changed after setting pagestyle
109\renewcommand{\sectionmark}[1]{\markboth{\thesection\quad #1}{\thesection\quad #1}}
110\renewcommand{\subsectionmark}[1]{\markboth{\thesubsection\quad #1}{\thesubsection\quad #1}}
111\pagenumbering{roman}
112\linenumbers                                            % comment out to turn off line numbering
113
114\maketitle
115\thispagestyle{empty}
116\vspace*{\fill}
117\noindent
118\copyright\,2016 \CFA Project \\ \\
119\noindent
120This work is licensed under the Creative Commons Attribution 4.0 International License.
121To view a copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.
122\vspace*{1in}
123
124\clearpage
125\thispagestyle{plain}
126\pdfbookmark[1]{Contents}{section}
127\tableofcontents
128
129\clearpage
130\thispagestyle{plain}
131\pagenumbering{arabic}
132
133
134\section{Introduction}
135
136\CFA{}\index{cforall@\CFA}\footnote{Pronounced ``\Index*{C-for-all}'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed as an evolutionary step forward for the C programming language.
137The syntax of the \CFA language builds from C, and should look immediately familiar to C/\Index*[C++]{\CC{}} programmers.
138% Any language feature that is not described here can be assumed to be using the standard \Celeven syntax.
139\CFA adds many modern programming-language features that directly lead to increased \emph{\Index{safety}} and \emph{\Index{productivity}}, while maintaining interoperability with existing C programs and achieving C performance.
140Like C, \CFA is a statically typed, procedural language with a low-overhead runtime, meaning there is no global \Index{garbage-collection}, but \Index{regional garbage-collection}\index{garbage-collection!regional} is possible.
141The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
142
143One 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''.
144Programmers 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.
145A 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.
146There is no notion or requirement for rewriting a legacy C program in \CFA;
147instead, a programmer evolves an existing C program into \CFA by incrementally incorporating \CFA features.
148New programs can be written in \CFA using a combination of C and \CFA features.
149\Index*[C++]{\CC{}} had a similar goal 30 years ago, but currently has the disadvantages of multiple legacy design-choices that cannot be updated and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
150In contrast, \CFA has 30 years of hindsight and a clean starting point.
151
152Like \Index*[C++]{\CC{}}, there may be both an old and new ways to achieve the same effect.
153For example, the following programs compare the \CFA, C, and \CC I/O mechanisms, where the programs output the same result.
154\begin{quote2}
155\begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}}
156\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
157\begin{cfa}
158#include <fstream>§\indexc{fstream}§
159
160int main( void ) {
161        int x = 0, y = 1, z = 2;
162        ®sout | x | y | z | endl;®
163}
164\end{cfa}
165&
166\begin{lstlisting}
167#include <stdio.h>§\indexc{stdio.h}§
168
169int main( void ) {
170        int x = 0, y = 1, z = 2;
171        ®printf( "%d %d %d\n", x, y, z );®
172}
173\end{lstlisting}
174&
175\begin{lstlisting}
176#include <iostream>§\indexc{iostream}§
177using namespace std;
178int main() {
179        int x = 0, y = 1, z = 2;
180        ®cout<<x<<" "<<y<<" "<<z<<endl;®
181}
182\end{lstlisting}
183\end{tabular}
184\end{quote2}
185While the \CFA I/O looks similar to the \Index*[C++]{\CC{}} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}).
186
187This document is a programmer reference-manual for the \CFA programming language.
188The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of each feature.
189The manual does not teach programming, i.e., how to combine the new constructs to build complex programs.
190A reader should already have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented as well as some experience programming in C/\CC.
191Implementers may refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
192Changes to the syntax and additional features are expected to be included in later revisions.
193
194
195\section{Why fix C?}
196
197The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems (especially UNIX systems) to hobby projects.
198This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
199Even with all its problems, C continues to be popular because it allows writing software at virtually any level in a computer system without restriction.
200For system programming, where direct access to hardware and dealing with real-time issues is a requirement, C is usually the language of choice.
201The TIOBE index~\cite{TIOBE} for March 2016 showed the following programming-language popularity: \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC{}} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, where the next 50 languages are less than 3\% each with a long tail.
202As well, for 30 years, C has been the number 1 and 2 most popular programming language:
203\begin{center}
204\setlength{\tabcolsep}{1.5ex}
205\begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
206Ranking & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986          \\
207\hline
208Java    & 1             & 1             & 1             & 3             & 29    & -             & -                     \\
209\hline
210\R{C}   & \R{2} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} & \R{1}         \\
211\hline
212\CC             & 3             & 3             & 3             & 2             & 2             & 2             & 7                     \\
213\end{tabular}
214\end{center}
215Hence, C is still an extremely important programming language, with double the usage of \Index*[C++]{\CC{}}; in many cases, \CC is often used solely as a better C.
216Love it or hate it, C has been an important and influential part of computer science for 40 years and sit appeal is not diminishing.
217Unfortunately, C has too many problems and omissions to make it an acceptable programming language for modern needs.
218
219As stated, the goal of the \CFA project is to engineer modern language features into C in an evolutionary rather than revolutionary way.
220\CC~\cite{C++14,C++} is an example of a similar project;
221however, it largely extended the language, and did not address many existing problems.\footnote{%
222Two 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.}
223\Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
224\Index*{Java}~\cite{Java8}, \Index*{Go}~\cite{Go}, \Index*{Rust}~\cite{Rust} and \Index*{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.
225These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
226As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
227These 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.
228
229The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixing some of the well known C problems and containing many modern language features.
230Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
231as a result, it will fade into disuse.
232Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
233While \Index*[C11]{\Celeven{}} 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.
234While 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.
235
236
237\section{History}
238
239The \CFA project started with \Index*{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.
240(See~\cite{Werther96} for similar work in \Index*[C++]{\CC{}}.)
241A first \CFA implementation of these extensions was by Esteves~\cite{Esteves04}.
242The signature feature of \CFA is parametric-polymorphic functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a ©forall© clause (giving the language its name):
243\begin{lstlisting}
244®forall( otype T )® T identity( T val ) { return val; }
245int forty_two = identity( 42 );                 §\C{// T is bound to int, forty\_two == 42}§
246\end{lstlisting}
247% extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
248\CFA{}\hspace{1pt}'s polymorphism was originally formalized by Ditchfiled~\cite{Ditchfield92}, and first implemented by Bilson~\cite{Bilson03}.
249However, at that time, there was little interesting in extending C, so work did not continue.
250As 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.
251
252
253\section{Interoperability}
254\label{s:Interoperability}
255
256\CFA is designed to integrate directly with existing C programs and libraries.
257The most important feature of \Index{interoperability} is using the same \Index{calling convention}s, so there is no overhead to call existing C routines.
258This feature allows \CFA programmers to take advantage of the existing panoply of C libraries to access thousands of external software features.
259Language developers often state that adequate \Index{library support} takes more work than designing and implementing the language itself.
260Fortunately, \CFA, like \Index*[C++]{\CC{}}, 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.
261Hence, \CFA begins by leveraging the large repository of C libraries with little cost.
262
263\begin{comment}
264A simple example is leveraging the existing type-unsafe (©void *©) C ©bsearch© to binary search a sorted floating-point array:
265\begin{lstlisting}
266void * bsearch( const void * key, const void * base, size_t dim, size_t size,
267                                int (* compar)( const void *, const void * ));
268
269int comp( const void * t1, const void * t2 ) { return *(double *)t1 < *(double *)t2 ? -1 :
270                                *(double *)t2 < *(double *)t1 ? 1 : 0; }
271
272double key = 5.0, vals[10] = { /* 10 sorted floating-point values */ };
273double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
274\end{lstlisting}
275which can be augmented simply with a polymorphic, type-safe, \CFA-overloaded wrappers:
276\begin{lstlisting}
277forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) {
278        int comp( const void * t1, const void * t2 ) { /* as above with double changed to T */ }
279        return (T *)bsearch( &key, arr, size, sizeof(T), comp ); }
280
281forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
282        T * result = bsearch( key, arr, size ); $\C{// call first version}$
283        return result ? result - arr : size; }  $\C{// pointer subtraction includes sizeof(T)}$
284
285double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
286int posn = bsearch( 5.0, vals, 10 );
287\end{lstlisting}
288The nested function ©comp© provides the hidden interface from typed \CFA to untyped (©void *©) C, plus the cast of the result.
289Providing a hidden ©comp© function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
290As well, an alternate kind of return is made available: position versus pointer to found element.
291\CC's type-system cannot disambiguate between the two versions of ©bsearch© because it does not use the return type in overload resolution, nor can \CC separately compile a templated ©bsearch©.
292
293\CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations.
294For example, it is possible to write a type-safe \CFA wrapper ©malloc© based on the C ©malloc©:
295\begin{lstlisting}
296forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
297int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
298double * dp = malloc();
299struct S {...} * sp = malloc();
300\end{lstlisting}
301where the return type supplies the type/size of the allocation, which is impossible in most type systems.
302\end{comment}
303
304However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
305For 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©.
306Whereas, \CFA wraps each of these routines into ones with the common name ©abs©:
307\begin{cfa}
308char abs( char );
309®extern "C" {®
310int abs( int );                                                 §\C{// use default C routine for int}§
311®}® // extern "C"
312long int abs( long int );
313long long int abs( long long int );
314float abs( float );
315double abs( double );
316long double abs( long double );
317float _Complex abs( float _Complex );
318double _Complex abs( double _Complex );
319long double _Complex abs( long double _Complex );
320\end{cfa}
321The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
322Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
323Then overloading polymorphism uses a mechanism called \newterm{name mangling}\index{mangling!name} to create unique names that are different from C names, which are not mangled.
324Hence, 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.
325There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
326This example strongly illustrates a core idea in \CFA: \emph{the power of a name}.
327The name ``©abs©'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
328Hence, knowing the name ©abs© should be sufficient to apply it to any type where it is applicable.
329The time savings and safety of using one name uniformly versus $N$ unique names should not be underestimated.
330
331
332\section[Compiling CFA Program]{Compiling \CFA Program}
333
334The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
335\begin{cfa}
336cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
337\end{cfa}
338\CFA programs having the following ©gcc© flags turned on:
339\begin{description}
340\item
341\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
342The 1999 C standard plus GNU extensions.
343\item
344{\lstset{deletekeywords={inline}}
345\Indexc{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{©-fgnu89-inline©}}
346Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
347}%
348\end{description}
349The following new \CFA options are available:
350\begin{description}
351\item
352\Indexc{-CFA}\index{compilation option!-CFA@©-CFA©}
353Only 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.
354The generated code started with the standard \CFA prelude.
355
356\item
357\Indexc{-debug}\index{compilation option!-debug@©-debug©}
358The program is linked with the debugging version of the runtime system.
359The debug version performs runtime checks to help during the debugging phase of a \CFA program, but substantially slows the execution of the program.
360The runtime checks should only be removed after the program is completely debugged.
361\textbf{This option is the default.}
362
363\item
364\Indexc{-nodebug}\index{compilation option!-nodebug@©-nodebug©}
365The program is linked with the non-debugging version of the runtime system, so the execution of the program is faster.
366\Emph{However, no runtime checks or ©assert©s are performed so errors usually result in abnormal program termination.}
367
368\item
369\Indexc{-help}\index{compilation option!-help@©-help©}
370Information about the set of \CFA compilation flags is printed.
371
372\item
373\Indexc{-nohelp}\index{compilation option!-nohelp@©-nohelp©}
374Information about the set of \CFA compilation flags is not printed.
375\textbf{This option is the default.}
376
377\item
378\Indexc{-quiet}\index{compilation option!-quiet@©-quiet©}
379The \CFA compilation message is not printed at the beginning of a compilation.
380
381\item
382\Indexc{-noquiet}\index{compilation option!-noquiet@©-noquiet©}
383The \CFA compilation message is printed at the beginning of a compilation.
384\textbf{This option is the default.}
385
386\item
387\Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©}
388Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
389\textbf{This option is \emph{not} the default.}
390\end{description}
391
392The following preprocessor variables are available:
393\begin{description}
394\item
395\Indexc{__CFA_MAJOR__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
396is available during preprocessing and its value is the major \Index{version number} of \CFA.\footnote{
397The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
398Hence, the need to have three variables for the major, minor and patch version number.}
399
400\item
401\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
402is available during preprocessing and its value is the minor \Index{version number} of \CFA.
403
404\item
405\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH____CFA_PATCH__©}
406is available during preprocessing and its value is the patch \Index{level number} of \CFA.
407
408\item
409\Indexc{__CFA__}\index{preprocessor variables!__CFA____CFA__©},
410\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL____CFORALL__©} and
411\Indexc{__cforall}\index{preprocessor variables!__cforall@©__cforall©}
412are always available during preprocessing and have no value.
413\end{description}
414These preprocessor variables allow conditional compilation of programs that must work differently in these situations.
415For example, to toggle between C and \CFA extensions, using the following:
416\begin{cfa}
417#ifndef __CFORALL__
418#include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
419#else
420#include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
421#endif
422\end{cfa}
423which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
424
425
426\section{Constants Underscores}
427
428Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
429\begin{cfa}
430_®147®_®483®_®648;                                    §\C{// decimal constant}§
43156®_®ul;                                                                §\C{// decimal unsigned long constant}§
432_®377;                                                                §\C{// octal constant}§
4330x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
4340x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
4353.141®_®592®_®654;                                              §\C{// floating point constant}§
43610®_®e®_®+1®_®00;                                               §\C{// floating point constant}§
4370x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating point}§
4380x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating point long constant}§
439_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
440\end{cfa}
441The rules for placement of underscores is as follows:
442\begin{enumerate}
443\item
444A sequence of underscores is disallowed, \eg ©12__34© is invalid.
445\item
446Underscores may only appear within a sequence of digits (regardless of the digit radix).
447In other words, an underscore cannot start or end a sequence of digits, \eg ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).
448\item
449A numeric prefix may end with an underscore;
450a numeric infix may begin and/or end with an underscore;
451a numeric suffix may begin with an underscore.
452For example, the octal ©0© or hexadecimal ©0x© prefix may end with an underscore ©0_377© or ©0x_ff©;
453the exponent infix ©E© may start or end with an underscore ©1.0_E10©, ©1.0E_10© or ©1.0_E_10©;
454the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
455\end{enumerate}
456It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
457This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
458
459
460\section{Backquote Identifiers}
461\label{s:BackquoteIdentifiers}
462
463\CFA accommodates keyword clashes with existing C variable-names by syntactic transformations using the \CFA backquote escape-mechanism:
464\begin{cfa}
465int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
466double ®`®forall®`® = 3.5;
467\end{cfa}
468Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
469\VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©:
470
471\begin{figure}
472\begin{cfa}
473// include file uses the CFA keyword "otype".
474#if ! defined( otype )                  §\C{// nesting ?}§
475#define otype ®`®otype®`®               §\C{// make keyword an identifier}§
476#define __CFA_BFD_H__
477#endif // ! otype
478
479#include_next <bfd.h>                   §\C{// must have internal check for multiple expansion}§
480
481#if defined( otype ) && defined( __CFA_BFD_H__ )        §\C{// reset only if set}§
482#undef otype
483#undef __CFA_BFD_H__
484#endif // otype && __CFA_BFD_H__
485\end{cfa}
486\caption{Interposition of Header File}
487\label{f:InterpositionHeaderFile}
488\end{figure}
489
490
491\section{Declarations}
492\label{s:Declarations}
493
494C declaration syntax is notoriously confusing and error prone.
495For example, many C programmers are confused by a declaration as simple as:
496\begin{quote2}
497\begin{tabular}{@{}ll@{}}
498\begin{cfa}
499int * x[5]
500\end{cfa}
501&
502\raisebox{-0.75\totalheight}{\input{Cdecl}}
503\end{tabular}
504\end{quote2}
505Is this an array of 5 pointers to integers or a \Index{pointer} to an array of 5 integers?
506The fact this declaration is unclear to many C programmers means there are \Index{productivity} and \Index{safety} issues even for basic programs.
507Another 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.
508For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
509\begin{cfa}
510int ®(*®f®())[®5®]® {...};                              §\C{definition}§
511 ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
512\end{cfa}
513Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
514While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
515
516\CFA provides its own type, variable and routine declarations, using a different syntax.
517The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
518In the following example, \R{red} is the base type and \B{blue} is qualifiers.
519The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
520\begin{quote2}
521\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
522\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
523\begin{cfa}
524ß[5] *ß ®int® x1;
525ß* [5]ß ®int® x2;
526ß[* [5] int]ß f®( int p )®;
527\end{cfa}
528&
529\begin{cfa}
530®int® ß*ß x1 ß[5]ß;
531®int® ß(*ßx2ß)[5]ß;
532ßint (*ßf®( int p )®ß)[5]ß;
533\end{cfa}
534\end{tabular}
535\end{quote2}
536The only exception is \Index{bit field} specification, which always appear to the right of the base type.
537% 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.
538However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
539For instance, variables ©x© and ©y© of type \Index{pointer} to integer are defined in \CFA as follows:
540\begin{quote2}
541\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
542\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
543\begin{cfa}
544®*® int x, y;
545\end{cfa}
546&
547\begin{cfa}
548int ®*®x, ®*®y;
549\end{cfa}
550\end{tabular}
551\end{quote2}
552The downside of this semantics is the need to separate regular and \Index{pointer} declarations:
553\begin{quote2}
554\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
555\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
556\begin{cfa}
557®*® int x;
558int y;
559\end{cfa}
560&
561\begin{cfa}
562int ®*®x, y;
563
564\end{cfa}
565\end{tabular}
566\end{quote2}
567which is \Index{prescribing} a safety benefit.
568Other examples are:
569\begin{quote2}
570\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
571\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
572\begin{cfa}
573[ 5 ] int z;
574[ 5 ] * char w;
575* [ 5 ] double v;
576struct s {
577        int f0:3;
578        * int f1;
579        [ 5 ] * int f2;
580};
581\end{cfa}
582&
583\begin{cfa}
584int z[ 5 ];
585char * w[ 5 ];
586double (* v)[ 5 ];
587struct s {
588        int f0:3;
589        int * f1;
590        int * f2[ 5 ]
591};
592\end{cfa}
593&
594\begin{cfa}
595// array of 5 integers
596// array of 5 pointers to char
597// pointer to array of 5 doubles
598
599// common bit field syntax
600
601
602
603\end{cfa}
604\end{tabular}
605\end{quote2}
606
607All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
608\begin{quote2}
609\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
610\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\
611\begin{cfa}
612const * const int x;
613const * [ 5 ] const int y;
614\end{cfa}
615&
616\begin{cfa}
617int const * const x;
618const int (* const y)[ 5 ]
619\end{cfa}
620&
621\begin{cfa}
622// const pointer to const integer
623// const pointer to array of 5 const integers
624\end{cfa}
625\end{tabular}
626\end{quote2}
627All declaration qualifiers, \eg ©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}
628The 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}} \eg:
629\begin{quote2}
630\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
631\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
632\begin{cfa}
633extern [ 5 ] int x;
634static * const int y;
635\end{cfa}
636&
637\begin{cfa}
638int extern x[ 5 ];
639const int static * y;
640\end{cfa}
641&
642\begin{cfa}
643// externally visible array of 5 integers
644// internally visible pointer to constant int
645\end{cfa}
646\end{tabular}
647\end{quote2}
648
649The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
650\begin{quote2}
651\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
652\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
653\begin{cfa}
654y = (®* int®)x;
655i = sizeof(®[ 5 ] * int®);
656\end{cfa}
657&
658\begin{cfa}
659y = (®int *®)x;
660i = sizeof(®int * [ 5 ]®);
661\end{cfa}
662\end{tabular}
663\end{quote2}
664
665Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
666Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
667Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
668
669
670\section{Pointer/Reference}
671
672C provides a \newterm{pointer type};
673\CFA adds a \newterm{reference type}.
674These types may be derived from an object or routine type, called the \newterm{referenced type}.
675Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices.
676An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{
677One way to conceptualize the null pointer is that no variable is placed at this address, so the null-pointer address can be used to denote an uninitialized pointer/reference object;
678\ie the null pointer is guaranteed to compare unequal to a pointer to any object or routine.}
679An address is \newterm{sound}, if it points to a valid memory location in scope, \ie within the program's execution-environment and has not been freed.
680Dereferencing an \newterm{unsound} address, including the null pointer, is \Index{undefined}, often resulting in a \Index{memory fault}.
681
682A program \newterm{object} is a region of data storage in the execution environment, the contents of which can represent values.
683In most cases, objects are located in memory at an address, and the variable name for an object is an implicit address to the object generated by the compiler and automatically dereferenced, as in:
684\begin{quote2}
685\begin{tabular}{@{}ll@{\hspace{2em}}l@{}}
686\begin{cfa}
687int x;
688x = 3;
689int y;
690y = x;
691\end{cfa}
692&
693\raisebox{-0.45\totalheight}{\input{pointer1}}
694&
695\begin{cfa}
696int * ®const® x = (int *)100
697*x = 3;                 // implicit dereference
698int * ®const® y = (int *)104;
699*y = *x;                // implicit dereference
700\end{cfa}
701\end{tabular}
702\end{quote2}
703where the right example is how the compiler logically interprets the variables in the left example.
704Since a variable name only points to one address during its lifetime, it is an \Index{immutable} \Index{pointer};
705hence, the implicit type of pointer variables ©x© and ©y© are constant pointers in the compiler interpretation.
706In general, variable addresses are stored in instructions instead of loaded from memory, and hence may not occupy storage.
707These approaches are contrasted in the following:
708\begin{quote2}
709\begin{tabular}{@{}l|l@{}}
710\multicolumn{1}{c|}{explicit variable address} & \multicolumn{1}{c}{implicit variable address} \\
711\hline
712\begin{cfa}
713lda             r1,100                  // load address of x
714ld               r2,(r1)                  // load value of x
715lda             r3,104                  // load address of y
716st               r2,(r3)                  // store x into y
717\end{cfa}
718&
719\begin{cfa}
720
721ld              r2,(100)                // load value of x
722
723st              r2,(104)                // store x into y
724\end{cfa}
725\end{tabular}
726\end{quote2}
727Finally, the immutable nature of a variable's address and the fact that there is no storage for the variable pointer means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible.
728Therefore, the expression ©x = y© has only one meaning, ©*x = *y©, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of \Index{instruction decoding}.
729
730A \Index{pointer}/\Index{reference} object is a generalization of an object variable-name, \ie a mutable address that can point to more than one memory location during its lifetime.
731(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage if the literal is embedded directly into instructions.)
732Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
733\begin{quote2}
734\begin{tabular}{@{}l@{\hspace{2em}}l@{}}
735\begin{cfa}
736int x, y, ®*® p1, ®*® p2, ®**® p3;
737p1 = ®&®x;               // p1 points to x
738p2 = p1;                 // p2 points to x
739p1 = ®&®y;               // p1 points to y
740p3 = &p2;               // p3 points to p2
741\end{cfa}
742&
743\raisebox{-0.5\totalheight}{\input{pointer2.pstex_t}}
744\end{tabular}
745\end{quote2}
746
747Notice, an address has a \Index{duality}\index{address!duality}: a location in memory or the value at that location.
748In many cases, a compiler might be able to infer the best meaning for these two cases.
749For example, \Index*{Algol68}~\cite{Algol68} infers pointer dereferencing to select the best meaning for each pointer usage
750\begin{cfa}
751p2 = p1 + x;                                    §\C{// compiler infers *p2 = *p1 + x;}§
752\end{cfa}
753Algol68 infers the following dereferencing ©*p2 = *p1 + x©, because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
754Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices.
755
756Rather than inferring dereference, most programming languages pick one implicit dereferencing semantics, and the programmer explicitly indicates the other to resolve address-duality.
757In C, objects of pointer type always manipulate the pointer object's address:
758\begin{cfa}
759p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
760p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
761\end{cfa}
762even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
763\begin{cfa}
764p1 = p2;                                                §\C{// pointer address assignment}§
765®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
766\end{cfa}
767The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
768
769However, in most other situations, the pointed-to value is requested more often than the pointer address.
770\begin{cfa}
771*p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
772\end{cfa}
773In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed.
774It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic:
775\begin{cfa}
776p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15);
777\end{cfa}
778
779To support this common case, a reference type is introduced in \CFA, denoted by ©&©, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing (similar but not the same as \CC \Index{reference type}s).
780\begin{cfa}
781int x, y, ®&® r1, ®&® r2, ®&&® r3;
782®&®r1 = &x;                                             §\C{// r1 points to x}§
783®&®r2 = &r1;                                    §\C{// r2 points to x}§
784®&®r1 = &y;                                             §\C{// r1 points to y}§
785®&&®r3 = ®&®&r2;                                §\C{// r3 points to r2}§
786r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
787\end{cfa}
788Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
789Hence, a reference behaves like the variable name for the current variable it is pointing-to.
790One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in a declaration, so the previous example becomes:
791\begin{cfa}
792®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
793\end{cfa}
794When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.
795However, in C, the cancellation always yields a value (\Index{rvalue}).\footnote{
796The unary ©&© operator yields the address of its operand.
797If the operand has type ``type'', the result has type ``pointer to type''.
798If the operand is the result of a unary ©*© operator, neither that operator nor the ©&© operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}}
799For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
800\begin{cfa}
801(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
802\end{cfa}
803Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
804\begin{cfa}
805(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
806\end{cfa}
807Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
808
809Fundamentally, pointer and reference objects are functionally interchangeable because both contain addresses.
810\begin{cfa}
811int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
812                 &r1 = x,    &&r2 = r1,   &&&r3 = r2;
813***p3 = 3;                                              §\C{// change x}§
814r3 = 3;                                                 §\C{// change x, ***r3}§
815**p3 = ...;                                             §\C{// change p1}§
816&r3 = ...;                                              §\C{// change r1, (\&*)**r3, 1 cancellation}§
817*p3 = ...;                                              §\C{// change p2}§
818&&r3 = ...;                                             §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
819&&&r3 = p3;                                             §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
820\end{cfa}
821Furthermore, both types are equally performant, as the same amount of dereferencing occurs for both types.
822Therefore, the choice between them is based solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of implicit dereferencing aid from the compiler.
823
824As for a pointer type, a reference type may have qualifiers:
825\begin{cfa}
826const int cx = 5;                                       §\C{// cannot change cx;}§
827const int & cr = cx;                            §\C{// cannot change what cr points to}§
828®&®cr = &cx;                                            §\C{// can change cr}§
829cr = 7;                                                         §\C{// error, cannot change cx}§
830int & const rc = x;                                     §\C{// must be initialized}§
831®&®rc = &x;                                                     §\C{// error, cannot change rc}§
832const int & const crc = cx;                     §\C{// must be initialized}§
833crc = 7;                                                        §\C{// error, cannot change cx}§
834®&®crc = &cx;                                           §\C{// error, cannot change crc}§
835\end{cfa}
836Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
837\begin{cfa}
838int & const cr = *0;                            §\C{// where 0 is the int * zero}§
839\end{cfa}
840Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
841\begin{cfa}
842int & const cr = *malloc();
843cr = 5;
844free( &cr );
845cr = 7;                                                         §\C{// unsound pointer dereference}§
846\end{cfa}
847
848The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
849The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
850\CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
851\begin{quote2}
852\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
853\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
854\begin{cfa}
855®const® * ®const® * const int ccp;
856®const® & ®const® & const int ccr;
857\end{cfa}
858&
859\begin{cfa}
860const int * ®const® * ®const® ccp;
861
862\end{cfa}
863\end{tabular}
864\end{quote2}
865where the \CFA declaration is read left-to-right.
866
867Finally, like pointers, references are usable and composable with other type operators and generators.
868\begin{cfa}
869int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
870&ar[1] = &w;                                            §\C{// change reference array element}§
871typeof( ar[1] ) p;                                      §\C{// (gcc) is int, i.e., the type of referenced object}§
872typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, i.e., the type of reference}§
873sizeof( ar[1] ) == sizeof( int );       §\C{// is true, i.e., the size of referenced object}§
874sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, i.e., the size of a reference}§
875\end{cfa}
876
877In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
878Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
879The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referant object.}
880\Index*{Java}'s reference types to objects (all Java objects are on the heap) are like C pointers, which always manipulate the address, and there is no (bit-wise) object assignment, so objects are explicitly cloned by shallow or deep copying, which eliminates half of the address duality.
881
882
883\subsection{Address-of Semantics}
884
885In C, ©&E© is an rvalue for any expression ©E©.
886\CFA extends the ©&© (address-of) operator as follows:
887\begin{itemize}
888\item
889if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) than ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
890
891\item
892if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
893\end{itemize}
894The following example shows the first rule applied to different \Index{rvalue} contexts:
895\begin{cfa}
896int x, * px, ** ppx, *** pppx, **** ppppx;
897int & rx = x, && rrx = rx, &&& rrrx = rrx ;
898x = rrrx;               // rrrx is an lvalue with type int &&& (equivalent to x)
899px = &rrrx;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (&x)
900ppx = &&rrrx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (&rx)
901pppx = &&&rrrx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (&rrx)
902ppppx = &&&&rrrx; // starting from &&&rrrx, &&&&rrrx is an rvalue with type int **** (&rrrx)
903\end{cfa}
904The following example shows the second rule applied to different \Index{lvalue} contexts:
905\begin{cfa}
906int x, * px, ** ppx, *** pppx;
907int & rx = x, && rrx = rx, &&& rrrx = rrx ;
908rrrx = 2;               // rrrx is an lvalue with type int &&& (equivalent to x)
909&rrrx = px;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (rx)
910&&rrrx = ppx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (rrx)
911&&&rrrx = pppx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (rrrx)
912\end{cfa}
913
914
915\subsection{Conversions}
916
917C provides a basic implicit conversion to simplify variable usage:
918\begin{enumerate}
919\setcounter{enumi}{-1}
920\item
921lvalue to rvalue conversion: ©cv T© converts to ©T©, which allows implicit variable dereferencing.
922\begin{cfa}
923int x;
924x + 1;                  // lvalue variable (int) converts to rvalue for expression
925\end{cfa}
926An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
927\end{enumerate}
928\CFA provides three new implicit conversion for reference types to simplify reference usage.
929\begin{enumerate}
930\item
931reference to rvalue conversion: ©cv T &© converts to ©T©, which allows implicit reference dereferencing.
932\begin{cfa}
933int x, &r = x, f( int p );
934x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
935\end{cfa}
936An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
937
938\item
939lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
940\begin{cfa}
941int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
942f( ®x® );               // lvalue variable (int) convert to reference (int &)
943\end{cfa}
944Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
945Conversion can expand a type, where ©cv1© $>$ ©cv2©, \eg passing a ©const volatile int© to an ©int &©, which has high cost (\Index{warning});
946furthermore, if ©cv1© has ©const© but not ©cv2©, a temporary variable is created to preserve the immutable lvalue.
947
948\item
949rvalue to reference conversion: ©T© converts to ©cv T &©, which allows binding references to temporaries.
950\begin{cfa}
951int x, & f( int & p );
952f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
953®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
954\end{cfa}
955In both case, modifications to the temporary are inaccessible (\Index{warning}).
956Conversion expands the temporary-type with ©cv©, which is low cost since the temporary is inaccessible.
957\end{enumerate}
958
959
960\subsection{Initialization}
961
962\Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object.
963There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding.
964Because the object being initialized has no value, there is only one meaningful semantics with respect to address duality: it must mean address as there is no pointed-to value.
965In contrast, the left-hand side of assignment has an address that has a duality.
966Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
967\begin{cfa}
968int * p = &x;                                           §\C{// assign address of x}§
969®int * p = x;®                                          §\C{// assign value of x}§
970int & r = x;                                            §\C{// must have address of x}§
971\end{cfa}
972Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of ©x© into a pointer is meaningful (again, a warning is usually given).
973Therefore, for safety, this context requires an address, so it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
974Note, this is strictly a convenience and safety feature for a programmer.
975Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match due to the implicit dereference.
976Unfortunately, C allows ©p© to be assigned with ©&x© (address) or ©x© (value), but most compilers warn about the latter assignment as being potentially incorrect.
977Similarly, when a reference type is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason.
978\begin{cfa}
979int & f( int & r );                                     §\C{// reference parameter and return}§
980z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
981\end{cfa}
982Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
983Since operator routine ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references.
984\begin{cfa}
985int temp1 = f( x ), temp2 = f( y );
986z = temp1 + temp2;
987\end{cfa}
988This \Index{implicit referencing} is crucial for reducing the syntactic burden for programmers when using references;
989otherwise references have the same syntactic  burden as pointers in these contexts.
990
991When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
992\begin{cfa}
993void f( ®const® int & cr );
994void g( ®const® int * cp );
995f( 3 );                   g( ®&®3 );
996f( x + y );             g( ®&®(x + y) );
997\end{cfa}
998Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
999The ©&© before the constant/expression for the pointer-type parameter (©g©) is a \CFA extension necessary to type match and is a common requirement before a variable in C (\eg ©scanf©).
1000Importantly, ©&3© may not be equal to ©&3©, where the references occur across calls because the temporaries maybe different on each call.
1001
1002\CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.\footnote{
1003If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.}
1004\begin{cfa}
1005void f( int & r );
1006void g( int * p );
1007f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
1008f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
1009\end{cfa}
1010Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
1011This conversion attempts to address the \newterm{const hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.}
1012The implicit conversion allows seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
1013
1014%\CFA attempts to handle pointers and references in a uniform, symmetric manner.
1015Finally, C handles \Index{routine object}s in an inconsistent way.
1016A routine object is both a pointer and a reference (\Index{particle and wave}).
1017\begin{cfa}
1018void f( int i );
1019void (*fp)( int );                                      §\C{// routine pointer}§
1020fp = f;                                                         §\C{// reference initialization}§
1021fp = &f;                                                        §\C{// pointer initialization}§
1022fp = *f;                                                        §\C{// reference initialization}§
1023fp(3);                                                          §\C{// reference invocation}§
1024(*fp)(3);                                                       §\C{// pointer invocation}§
1025\end{cfa}
1026While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (©f©, ©&f©, ©*f©) without regard for type.
1027Instead, a routine object should be referenced by a ©const© reference:
1028\begin{cfa}
1029®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
1030fr = ...                                                        §\C{// error, cannot change code}§
1031&fr = ...;                                                      §\C{// changing routine reference}§
1032fr( 3 );                                                        §\C{// reference call to f}§
1033(*fr)(3);                                                       §\C{// error, incorrect type}§
1034\end{cfa}
1035because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
1036Dynamic code rewriting is possible but only in special circumstances.}
1037\CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them.
1038
1039
1040
1041\begin{comment}
1042\section{References}
1043
1044By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks.
1045In structures, a reference can replace a pointer to an object that should always have a valid value.
1046When a structure contains a reference, all of its constructors must initialize the reference and all instances of this structure must initialize it upon definition.
1047
1048The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
1049Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
1050When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
1051The ©&© 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.
1052
1053
1054From: Richard Bilson <rcbilson@gmail.com>
1055Date: Wed, 13 Jul 2016 01:58:58 +0000
1056Subject: Re: pointers / references
1057To: "Peter A. Buhr" <pabuhr@plg2.cs.uwaterloo.ca>
1058
1059As a general comment I would say that I found the section confusing, as you move back and forth
1060between various real and imagined programming languages. If it were me I would rewrite into two
1061subsections, one that specifies precisely the syntax and semantics of reference variables and
1062another that provides the rationale.
1063
1064I don't see any obvious problems with the syntax or semantics so far as I understand them. It's not
1065obvious that the description you're giving is complete, but I'm sure you'll find the special cases
1066as you do the implementation.
1067
1068My big gripes are mostly that you're not being as precise as you need to be in your terminology, and
1069that you say a few things that aren't actually true even though I generally know what you mean.
1070
107120 C provides a pointer type; CFA adds a reference type. Both types contain an address, which is normally a
107221 location in memory.
1073
1074An address is not a location in memory; an address refers to a location in memory. Furthermore it
1075seems weird to me to say that a type "contains" an address; rather, objects of that type do.
1076
107721 Special addresses are used to denote certain states or access co-processor memory. By
107822 convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value
107923 or other special states.
1080
1081This isn't standard C at all. There has to be one null pointer representation, but it doesn't have
1082to be a literal zero representation and there doesn't have to be more than one such representation.
1083
108423 Often dereferencing a special state causes a memory fault, so checking is necessary
108524 during execution.
1086
1087I don't see the connection between the two clauses here. I feel like if a bad pointer will not cause
1088a memory fault then I need to do more checking, not less.
1089
109024 If the programming language assigns addresses, a program's execution is sound, \ie all
109125 addresses are to valid memory locations.
1092
1093You haven't said what it means to "assign" an address, but if I use my intuitive understanding of
1094the term I don't see how this can be true unless you're assuming automatic storage management.
1095
10961 Program variables are implicit pointers to memory locations generated by the compiler and automatically
10972 dereferenced, as in:
1098
1099There is no reason why a variable needs to have a location in memory, and indeed in a typical
1100program many variables will not. In standard terminology an object identifier refers to data in the
1101execution environment, but not necessarily in memory.
1102
110313 A pointer/reference is a generalization of a variable name, \ie a mutable address that can point to more
110414 than one memory location during its lifetime.
1105
1106I feel like you're off the reservation here. In my world there are objects of pointer type, which
1107seem to be what you're describing here, but also pointer values, which can be stored in an object of
1108pointer type but don't necessarily have to be. For example, how would you describe the value denoted
1109by "&main" in a C program? I would call it a (function) pointer, but that doesn't satisfy your
1110definition.
1111
111216 not occupy storage as the literal is embedded directly into instructions.) Hence, a pointer occupies memory
111317 to store its current address, and the pointer's value is loaded by dereferencing, e.g.:
1114
1115As with my general objection regarding your definition of variables, there is no reason why a
1116pointer variable (object of pointer type) needs to occupy memory.
1117
111821 p2 = p1 + x; // compiler infers *p2 = *p1 + x;
1119
1120What language are we in now?
1121
112224 pointer usage. However, in C, the following cases are ambiguous, especially with pointer arithmetic:
112325 p1 = p2; // p1 = p2 or *p1 = *p2
1124
1125This isn't ambiguous. it's defined to be the first option.
1126
112726 p1 = p1 + 1; // p1 = p1 + 1 or *p1 = *p1 + 1
1128
1129Again, this statement is not ambiguous.
1130
113113 example. Hence, a reference behaves like the variable name for the current variable it is pointing-to. The
113214 simplest way to understand a reference is to imagine the compiler inserting a dereference operator before
113315 the reference variable for each reference qualifier in a declaration, e.g.:
1134
1135It's hard for me to understand who the audience for this part is. I think a practical programmer is
1136likely to be satisfied with "a reference behaves like the variable name for the current variable it
1137is pointing-to," maybe with some examples. Your "simplest way" doesn't strike me as simpler than
1138that. It feels like you're trying to provide a more precise definition for the semantics of
1139references, but it isn't actually precise enough to be a formal specification. If you want to
1140express the semantics of references using rewrite rules that's a great way to do it, but lay the
1141rules out clearly, and when you're showing an example of rewriting keep your
1142references/pointers/values separate (right now, you use \eg "r3" to mean a reference, a pointer,
1143and a value).
1144
114524 Cancellation works to arbitrary depth, and pointer and reference values are interchangeable because both
114625 contain addresses.
1147
1148Except they're not interchangeable, because they have different and incompatible types.
1149
115040 Interestingly, C++ deals with the address duality by making the pointed-to value the default, and prevent-
115141 ing changes to the reference address, which eliminates half of the duality. Java deals with the address duality
115242 by making address assignment the default and requiring field assignment (direct or indirect via methods),
115343 \ie there is no builtin bit-wise or method-wise assignment, which eliminates half of the duality.
1154
1155I can follow this but I think that's mostly because I already understand what you're trying to
1156say. I don't think I've ever heard the term "method-wise assignment" and I don't see you defining
1157it. Furthermore Java does have value assignment of basic (non-class) types, so your summary here
1158feels incomplete. (If it were me I'd drop this paragraph rather than try to save it.)
1159
116011 Hence, for type & const, there is no pointer assignment, so &rc = &x is disallowed, and the address value
116112 cannot be 0 unless an arbitrary pointer is assigned to the reference.
1162
1163Given the pains you've taken to motivate every little bit of the semantics up until now, this last
1164clause ("the address value cannot be 0") comes out of the blue. It seems like you could have
1165perfectly reasonable semantics that allowed the initialization of null references.
1166
116712 In effect, the compiler is managing the
116813 addresses for type & const not the programmer, and by a programming discipline of only using references
116914 with references, address errors can be prevented.
1170
1171Again, is this assuming automatic storage management?
1172
117318 rary binding. For reference initialization (like pointer), the initializing value must be an address (lvalue) not
117419 a value (rvalue).
1175
1176This sentence appears to suggest that an address and an lvalue are the same thing.
1177
117820 int * p = &x; // both &x and x are possible interpretations
1179
1180Are you saying that we should be considering "x" as a possible interpretation of the initializer
1181"&x"? It seems to me that this expression has only one legitimate interpretation in context.
1182
118321 int & r = x; // x unlikely interpretation, because of auto-dereferencing
1184
1185You mean, we can initialize a reference using an integer value? Surely we would need some sort of
1186cast to induce that interpretation, no?
1187
118822 Hence, the compiler implicitly inserts a reference operator, &, before the initialization expression.
1189
1190But then the expression would have pointer type, which wouldn't be compatible with the type of r.
1191
119222 Similarly,
119323 when a reference is used for a parameter/return type, the call-site argument does not require a reference
119424 operator.
1195
1196Furthermore, it would not be correct to use a reference operator.
1197
119845 The implicit conversion allows
11991 seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
12002 While C' attempts to handle pointers and references in a uniform, symmetric manner, C handles routine
12013 variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave).
1202
1203After all this talk of how expressions can have both pointer and value interpretations, you're
1204disparaging C because it has expressions that have both pointer and value interpretations?
1205
1206On Sat, Jul 9, 2016 at 4:18 PM Peter A. Buhr <pabuhr@plg.uwaterloo.ca> wrote:
1207> Aaron discovered a few places where "&"s are missing and where there are too many "&", which are
1208> corrected in the attached updated. None of the text has changed, if you have started reading
1209> already.
1210\end{comment}
1211
1212
1213\section{Routine Definition}
1214
1215\CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
1216The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
1217\begin{cfa}
1218®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
1219        §\emph{routine body}§
1220}
1221\end{cfa}
1222where routine ©f© has three output (return values) and three input parameters.
1223Existing C syntax cannot be extended with multiple return types because it is impossible to embed a single routine name within multiple return type specifications.
1224
1225In 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{
1226\Index*{Michael Tiemann}, with help from \Index*{Doug Lea}, provided named return values in g++, circa 1989.}
1227The value of each local return variable is automatically returned at routine termination.
1228Declaration qualifiers can only appear at the start of a routine definition, \eg:
1229\begin{cfa}
1230®extern® [ int x ] g( int y ) {§\,§}
1231\end{cfa}
1232Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
1233in 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:
1234\begin{cfa}
1235\,§] g();                                             §\C{// no input or output parameters}§
1236[ void ] g( void );                             §\C{// no input or output parameters}§
1237\end{cfa}
1238
1239Routine f is called as follows:
1240\begin{cfa}
1241[ i, j, ch ] = f( 3, 'a', ch );
1242\end{cfa}
1243The 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.
1244
1245\CFA style declarations cannot be used to declare parameters for K\&R style routine definitions because of the following ambiguity:
1246\begin{cfa}
1247int (*f(x))[ 5 ] int x; {}
1248\end{cfa}
1249The 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.
1250Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string.
1251As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
1252\begin{cfa}
1253typedef int foo;
1254int f( int (* foo) );                   §\C{// foo is redefined as a parameter name}§
1255\end{cfa}
1256The 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.
1257The 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.
1258The 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.
1259
1260C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
1261\begin{cfa}
1262[ int ] f( * int, int * );              §\C{// returns an integer, accepts 2 pointers to integers}§
1263[ * int, int * ] f( int );              §\C{// returns 2 pointers to integers, accepts an integer}§
1264\end{cfa}
1265The 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:
1266\begin{cfa}
1267#define ptoa( n, d ) int (*n)[ d ]
1268int f( ptoa( p, 5 ) ) ...               §\C{// expands to int f( int (*p)[ 5 ] )}§
1269[ int ] f( ptoa( p, 5 ) ) ...   §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
1270\end{cfa}
1271Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
1272
1273
1274\subsection{Named Return Values}
1275
1276\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:
1277\begin{cfa}
1278int f() {
1279        int x;
1280        ... x = 0; ... x = y; ...
1281        return x;
1282}
1283\end{cfa}
1284Because 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:
1285\newline
1286\begin{minipage}{\linewidth}
1287\begin{cfa}
1288®[ int x, int y ]® f() {
1289        int z;
1290        ... x = 0; ... y = z; ...
1291        ®return;® §\C{// implicitly return x, y}§
1292}
1293\end{cfa}
1294\end{minipage}
1295\newline
1296When the return is encountered, the current values of ©x© and ©y© are returned to the calling routine.
1297As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in:
1298\begin{cfa}
1299[ int x, int y ] f() {
1300        ...
1301} §\C{// implicitly return x, y}§
1302\end{cfa}
1303In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
1304
1305
1306\subsection{Routine Prototype}
1307
1308The syntax of the new routine prototype declaration follows directly from the new routine definition syntax;
1309as well, parameter names are optional, \eg:
1310\begin{cfa}
1311[ int x ] f ();                                 §\C{// returning int with no parameters}§
1312[ * int ] g (int y);                    §\C{// returning pointer to int with int parameter}§
1313[ ] h (int,char);                               §\C{// returning no result with int and char parameters}§
1314[ * int,int ] j (int);                  §\C{// returning pointer to int and int, with int parameter}§
1315\end{cfa}
1316This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
1317It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg:
1318\begin{quote2}
1319\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
1320\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
1321\begin{cfa}
1322[ int ] f(int), g;
1323\end{cfa}
1324&
1325\begin{cfa}
1326int f(int), g(int);
1327\end{cfa}
1328\end{tabular}
1329\end{quote2}
1330Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
1331\begin{cfa}
1332extern [ int ] f (int);
1333static [ int ] g (int);
1334\end{cfa}
1335
1336
1337\section{Routine Pointers}
1338
1339The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
1340\begin{cfa}
1341* [ int x ] () fp;                      §\C{// pointer to routine returning int with no parameters}§
1342* [ * int ] (int y) gp;         §\C{// pointer to routine returning pointer to int with int parameter}§
1343* [ ] (int,char) hp;            §\C{// pointer to routine returning no result with int and char parameters}§
1344* [ * int,int ] (int) jp;       §\C{// pointer to routine returning pointer to int and int, with int parameter}§
1345\end{cfa}
1346While parameter names are optional, \emph{a routine name cannot be specified};
1347for example, the following is incorrect:
1348\begin{cfa}
1349* [ int x ] f () fp;            §\C{// routine name "f" is not allowed}§
1350\end{cfa}
1351
1352
1353\section{Named and Default Arguments}
1354
1355Named\index{named arguments}\index{arguments!named} and default\index{default arguments}\index{arguments!default} arguments~\cite{Hardgrave76}\footnote{
1356Francez~\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.}
1357are two mechanisms to simplify routine call.
1358Both mechanisms are discussed with respect to \CFA.
1359\begin{description}
1360\item[Named (or Keyword) Arguments:]
1361provide the ability to specify an argument to a routine call using the parameter name rather than the position of the parameter.
1362For example, given the routine:
1363\begin{cfa}
1364void p( int x, int y, int z ) {...}
1365\end{cfa}
1366a positional call is:
1367\begin{cfa}
1368p( 4, 7, 3 );
1369\end{cfa}
1370whereas a named (keyword) call may be:
1371\begin{cfa}
1372p( z : 3, x : 4, y : 7 );       §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
1373\end{cfa}
1374Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
1375The compiler rewrites a named call into a positional call.
1376The advantages of named parameters are:
1377\begin{itemize}
1378\item
1379Remembering the names of the parameters may be easier than the order in the routine definition.
1380\item
1381Parameter names provide documentation at the call site (assuming the names are descriptive).
1382\item
1383Changes can be made to the order or number of parameters without affecting the call (although the call must still be recompiled).
1384\end{itemize}
1385
1386Unfortunately, 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.
1387For example, the following routine prototypes and definition are all valid.
1388\begin{cfa}
1389void p( int, int, int );                        §\C{// equivalent prototypes}§
1390void p( int x, int y, int z );
1391void p( int y, int x, int z );
1392void p( int z, int y, int x );
1393void p( int q, int r, int s ) {}        §\C{// match with this definition}§
1394\end{cfa}
1395Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
1396Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports.
1397The former is easy to do, while the latter is more complex.
1398
1399Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching.
1400For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site:
1401\begin{cfa}
1402int f( int i, int j );
1403int f( int x, double y );
1404
1405f( j : 3, i : 4 );                              §\C{// 1st f}§
1406f( x : 7, y : 8.1 );                    §\C{// 2nd f}§
1407f( 4, 5 );                                              §\C{// ambiguous call}§
1408\end{cfa}
1409However, named arguments compound routine resolution in conjunction with conversions:
1410\begin{cfa}
1411f( i : 3, 5.7 );                                §\C{// ambiguous call ?}§
1412\end{cfa}
1413Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
1414Adding named argument into the routine resolution algorithm does not seem worth the complexity.
1415Therefore, \CFA does \emph{not} attempt to support named arguments.
1416
1417\item[Default Arguments]
1418provide the ability to associate a default value with a parameter so it can be optionally specified in the argument list.
1419For example, given the routine:
1420\begin{cfa}
1421void p( int x = 1, int y = 2, int z = 3 ) {...}
1422\end{cfa}
1423the allowable positional calls are:
1424\begin{cfa}
1425p();                                                    §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
1426p( 4 );                                                 §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
1427p( 4, 4 );                                              §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
1428p( 4, 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
1429// empty arguments
1430p(  , 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
1431p( 4,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
1432p( 4, 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
1433p( 4,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
1434p(  , 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
1435p(  ,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
1436p(  ,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
1437\end{cfa}
1438Here the missing arguments are inserted from the default values in the parameter list.
1439The compiler rewrites missing default values into explicit positional arguments.
1440The advantages of default values are:
1441\begin{itemize}
1442\item
1443Routines with a large number of parameters are often very generalized, giving a programmer a number of different options on how a computation is performed.
1444For many of these kinds of routines, there are standard or default settings that work for the majority of computations.
1445Without 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.
1446\item
1447When a routine's interface is augmented with new parameters, it extends the interface providing generalizability\footnote{
1448``It should be possible for the implementor of an abstraction to increase its generality.
1449So long as the modified abstraction is a generalization of the original, existing uses of the abstraction will not require change.
1450It 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.
1451This 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}}
1452(somewhat like the generalization provided by inheritance for classes).
1453That is, all existing calls are still valid, although the call must still be recompiled.
1454\end{itemize}
1455The only disadvantage of default arguments is that unintentional omission of an argument may not result in a compiler-time error.
1456Instead, a default value is used, which may not be the programmer's intent.
1457
1458Default values may only appear in a prototype versus definition context:
1459\begin{cfa}
1460void p( int x, int y = 2, int z = 3 );          §\C{// prototype: allowed}§
1461void p( int, int = 2, int = 3 );                        §\C{// prototype: allowed}§
1462void p( int x, int y = 2, int z = 3 ) {}        §\C{// definition: not allowed}§
1463\end{cfa}
1464The reason for this restriction is to allow separate compilation.
1465Multiple prototypes with different default values is an error.
1466\end{description}
1467
1468Ellipse (``...'') arguments present problems when used with default arguments.
1469The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities:
1470\begin{cfa}
1471p( /* positional */, ... , /* named */ );
1472p( /* positional */, /* named */, ... );
1473\end{cfa}
1474While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:
1475\begin{cfa}
1476p( int x, int y, int z, ... );
1477p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
1478p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
1479\end{cfa}
1480In 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.
1481Hence, this approach seems significantly more difficult, and hence, confusing and error prone.
1482In the second call, the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
1483
1484The problem is exacerbated with default arguments, \eg:
1485\begin{cfa}
1486void p( int x, int y = 2, int z = 3... );
1487p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, ... , /* named */ );}§
1488p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, ... );}§
1489\end{cfa}
1490The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
1491therefore, argument 5 subsequently conflicts with the named argument z : 3.
1492In 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.
1493For these reasons, \CFA requires named arguments before ellipse arguments.
1494Finally, 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.
1495
1496Default arguments and overloading (see Section 24) are complementary.
1497While in theory default arguments can be simulated with overloading, as in:
1498\begin{quote2}
1499\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
1500\multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}}   & \multicolumn{1}{c}{\textbf{overloading}}      \\
1501\begin{cfa}
1502void p( int x, int y = 2, int z = 3 ) {...}
1503
1504
1505\end{cfa}
1506&
1507\begin{cfa}
1508void p( int x, int y, int z ) {...}
1509void p( int x ) { p( x, 2, 3 ); }
1510void p( int x, int y ) { p( x, y, 3 ); }
1511\end{cfa}
1512\end{tabular}
1513\end{quote2}
1514the number of required overloaded routines is linear in the number of default values, which is unacceptable growth.
1515In general, overloading should only be used over default arguments if the body of the routine is significantly different.
1516Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
1517\begin{cfa}
1518p( 1, /* default */, 5 );               §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
1519\end{cfa}
1520
1521Given the \CFA restrictions above, both named and default arguments are backwards compatible.
1522\Index*[C++]{\CC{}} only supports default arguments;
1523\Index*{Ada} supports both named and default arguments.
1524
1525
1526\section{Unnamed Structure Fields}
1527
1528C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg:
1529\begin{cfa}
1530struct {
1531        int f1;                                 §\C{// named field}§
1532        int f2 : 4;                             §\C{// named field with bit field size}§
1533        int : 3;                                §\C{// unnamed field for basic type with bit field size}§
1534        int ;                                   §\C{// disallowed, unnamed field}§
1535        int *;                                  §\C{// disallowed, unnamed field}§
1536        int (*)(int);                   §\C{// disallowed, unnamed field}§
1537};
1538\end{cfa}
1539This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
1540As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
1541A list of unnamed fields is also supported, \eg:
1542\begin{cfa}
1543struct {
1544        int , , ;                               §\C{// 3 unnamed fields}§
1545}
1546\end{cfa}
1547
1548
1549\section{Nesting}
1550
1551Nesting of types and routines is useful for controlling name visibility (\newterm{name hiding}).
1552
1553
1554\subsection{Type Nesting}
1555
1556\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.
1557\begin{figure}
1558\centering
1559\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
1560\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
1561\hline
1562\begin{cfa}
1563struct S {
1564        enum C { R, G, B };
1565        struct T {
1566                union U { int i, j; };
1567                enum C c;
1568                short int i, j;
1569        };
1570        struct T t;
1571} s;
1572
1573int fred() {
1574        s.t.c = R;
1575        struct T t = { R, 1, 2 };
1576        enum C c;
1577        union U u;
1578}
1579\end{cfa}
1580&
1581\begin{cfa}
1582enum C { R, G, B };
1583union U { int i, j; };
1584struct T {
1585        enum C c;
1586        short int i, j;
1587};
1588struct S {
1589        struct T t;
1590} s;
1591       
1592
1593
1594
1595
1596
1597
1598\end{cfa}
1599&
1600\begin{cfa}
1601struct S {
1602        enum C { R, G, B };
1603        struct T {
1604                union U { int i, j; };
1605                enum C c;
1606                short int i, j;
1607        };
1608        struct T t;
1609} s;
1610
1611int fred() {
1612        s.t.c = ®S.®R;  // type qualification
1613        struct ®S.®T t = { ®S.®R, 1, 2 };
1614        enum ®S.®C c;
1615        union ®S.T.®U u;
1616}
1617\end{cfa}
1618\end{tabular}
1619\caption{Type Nesting / Qualification}
1620\label{f:TypeNestingQualification}
1621\end{figure}
1622In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
1623In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does \Index*{Java}, rather than the \CC type-selection operator ``©::©''.
1624
1625
1626\subsection{Routine Nesting}
1627
1628While \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.
1629For example, the C quick-sort is wrapped into the following polymorphic \CFA routine:
1630\begin{cfa}
1631forall( otype T | { int ?<?( T, T ); } )
1632void qsort( const T * arr, size_t dimension );
1633\end{cfa}
1634which can be used to sort in ascending and descending order by locally redefining the less-than operator into greater-than.
1635\begin{cfa}
1636const unsigned int size = 5;
1637int ia[size];
1638...                                             §\C{// assign values to array ia}§
1639qsort( ia, size );              §\C{// sort ascending order using builtin ?<?}§
1640{
1641        ®int ?<?( int x, int y ) { return x > y; }® §\C{// nested routine}§
1642        qsort( ia, size );      §\C{// sort descending order by local redefinition}§
1643}
1644\end{cfa}
1645
1646Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks;
1647the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program.
1648The following program in undefined in \CFA (and Indexc{gcc})
1649\begin{cfa}
1650[* [int]( int )] foo() {                §\C{// int (*foo())( int )}§
1651        int ®i® = 7;
1652        int bar( int p ) {
1653                ®i® += 1;                               §\C{// dependent on local variable}§
1654                sout | ®i® | endl;
1655        }
1656        return bar;                                     §\C{// undefined because of local dependence}§
1657}
1658int main() {
1659        * [int](int) fp = foo();        §\C{// int (*fp)(int)}§
1660        sout | fp( 3 ) | endl;
1661}
1662\end{cfa}
1663because
1664
1665Currently, there are no \Index{lambda} expressions, \ie unnamed routines because routine names are very important to properly select the correct routine.
1666
1667
1668\section{Tuples}
1669
1670In C and \CFA, lists of elements appear in several contexts, such as the parameter list for a routine call.
1671(More contexts are added shortly.)
1672A list of such elements is called a \newterm{lexical list}.
1673The general syntax of a lexical list is:
1674\begin{cfa}
1675[ §\emph{exprlist}§ ]
1676\end{cfa}
1677where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
1678The brackets, ©[]©, allow differentiating between lexical lists and expressions containing the C comma operator.
1679The following are examples of lexical lists:
1680\begin{cfa}
1681[ x, y, z ]
1682[ 2 ]
1683[ v+w, x*y, 3.14159, f() ]
1684\end{cfa}
1685Tuples are permitted to contain sub-tuples (\ie nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
1686Note, a tuple is not a record (structure);
1687a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1).
1688In essence, tuples are largely a compile time phenomenon, having little or no runtime presence.
1689
1690Tuples can be organized into compile-time tuple variables;
1691these variables are of \newterm{tuple type}.
1692Tuple variables and types can be used anywhere lists of conventional variables and types can be used.
1693The general syntax of a tuple type is:
1694\begin{cfa}
1695[ §\emph{typelist}§ ]
1696\end{cfa}
1697where ©$\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.
1698Examples of tuple types include:
1699\begin{cfa}
1700[ unsigned int, char ]
1701[ double, double, double ]
1702[ * int, int * ]                §\C{// mix of CFA and ANSI}§
1703[ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
1704\end{cfa}
1705Like 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.
1706
1707Examples of declarations using tuple types are:
1708\begin{cfa}
1709[ int, int ] x;                 §\C{// 2 element tuple, each element of type int}§
1710* [ char, char ] y;             §\C{// pointer to a 2 element tuple}§
1711[ [ int, int ] ] z ([ int, int ]);
1712\end{cfa}
1713The 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.
1714
1715As mentioned, tuples can appear in contexts requiring a list of value, such as an argument list of a routine call.
1716In unambiguous situations, the tuple brackets may be omitted, \eg a tuple that appears as an argument may have its
1717square brackets omitted for convenience; therefore, the following routine invocations are equivalent:
1718\begin{cfa}
1719f( [ 1, x+2, fred() ] );
1720f( 1, x+2, fred() );
1721\end{cfa}
1722Also, 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.
1723For example, the following are all legal:
1724\begin{cfa}
1725[ int, int ] w1;
1726[ int, int, int ] w2;
1727[ void ] f (int, int, int); /* three input parameters of type int */
1728[ void ] g ([ int, int, int ]); /* 3 element tuple as input */
1729f( [ 1, 2, 3 ] );
1730f( w1, 3 );
1731f( 1, w1 );
1732f( w2 );
1733g( [ 1, 2, 3 ] );
1734g( w1, 3 );
1735g( 1, w1 );
1736g( w2 );
1737\end{cfa}
1738Note, in all cases 3 arguments are supplied even though the syntax may appear to supply less than 3. As mentioned, a
1739tuple does not have structure like a record; a tuple is simply converted into a list of components.
1740\begin{rationale}
1741The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \ie a statement such as ©g( f() )© is not supported.
1742Using a temporary variable to store the  results of the inner routine and then passing this variable to the outer routine works, however.
1743\end{rationale}
1744
1745A tuple can contain a C comma expression, provided the expression containing the comma operator is enclosed in parentheses.
1746For instance, the following tuples are equivalent:
1747\begin{cfa}
1748[ 1, 3, 5 ]
1749[ 1, (2, 3), 5 ]
1750\end{cfa}
1751The second element of the second tuple is the expression (2, 3), which yields the result 3.
1752This requirement is the same as for comma expressions in argument lists.
1753
1754Type qualifiers, \ie const and volatile, may modify a tuple type.
1755The 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)], \ie the qualifier is distributed across all of the types in the tuple, \eg:
1756\begin{cfa}
1757const volatile [ int, float, const int ] x;
1758\end{cfa}
1759is equivalent to:
1760\begin{cfa}
1761[ const volatile int, const volatile float, const volatile int ] x;
1762\end{cfa}
1763Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg:
1764\begin{cfa}
1765extern [ int, int ] w1;
1766static [ int, int, int ] w2;
1767\end{cfa}
1768\begin{rationale}
1769Unfortunately, C's syntax for subscripts precluded treating them as tuples.
1770The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©.
1771Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg ©f[g()]© always means a single subscript value because there is only one set of brackets.
1772Fixing 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.
1773\end{rationale}
1774
1775
1776\subsection{Tuple Coercions}
1777
1778There are four coercions that can be performed on tuples and tuple variables: closing, opening, flattening and structuring.
1779In addition, the coercion of dereferencing can be performed on a tuple variable to yield its value(s), as for other variables.
1780A \newterm{closing coercion} takes a set of values and converts it into a tuple value, which is a contiguous set of values, as in:
1781\begin{cfa}
1782[ int, int, int, int ] w;
1783w = [ 1, 2, 3, 4 ];
1784\end{cfa}
1785First the right-hand tuple is closed into a tuple value and then the tuple value is assigned.
1786
1787An \newterm{opening coercion} is the opposite of closing; a tuple value is converted into a tuple of values, as in:
1788\begin{cfa}
1789[ a, b, c, d ] = w
1790\end{cfa}
1791©w© is implicitly opened to yield a tuple of four values, which are then assigned individually.
1792
1793A \newterm{flattening coercion} coerces a nested tuple, \ie 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:
1794\begin{cfa}
1795[ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ];
1796\end{cfa}
1797First the right-hand tuple is flattened and then the values are assigned individually.
1798Flattening is also performed on tuple types.
1799For example, the type ©[ int, [ int, int ], int ]© can be coerced, using flattening, into the type ©[ int, int, int, int ]©.
1800
1801A \newterm{structuring coercion} is the opposite of flattening;
1802a tuple is structured into a more complex nested tuple.
1803For 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 ]©.
1804In the following example, the last assignment illustrates all the tuple coercions:
1805\begin{cfa}
1806[ int, int, int, int ] w = [ 1, 2, 3, 4 ];
1807int x = 5;
1808[ x, w ] = [ w, x ];            §\C{// all four tuple coercions}§
1809\end{cfa}
1810Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
1811therefore, the right-hand tuple is now the tuple ©[ [ 1, 2, 3, 4 ], 5 ]©.
1812This 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.
1813The tuple ©[ 2, 3, 4, 5 ]© is then closed to create a tuple value.
1814Finally, ©x© is assigned ©1© and ©w© is assigned the tuple value using multiple assignment (see Section 14).
1815\begin{rationale}
1816A possible additional language extension is to use the structuring coercion for tuples to initialize a complex record with a tuple.
1817\end{rationale}
1818
1819
1820\section{Mass Assignment}
1821
1822\CFA permits assignment to several variables at once using mass assignment~\cite{CLU}.
1823Mass assignment has the following form:
1824\begin{cfa}
1825[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
1826\end{cfa}
1827\index{lvalue}
1828The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, \ie any data object that can appear on the left-hand side of a conventional assignment statement.
1829©$\emph{expr}$© is any standard arithmetic expression.
1830Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
1831
1832Mass assignment has parallel semantics, \eg the statement:
1833\begin{cfa}
1834[ x, y, z ] = 1.5;
1835\end{cfa}
1836is equivalent to:
1837\begin{cfa}
1838x = 1.5; y = 1.5; z = 1.5;
1839\end{cfa}
1840This semantics is not the same as the following in C:
1841\begin{cfa}
1842x = y = z = 1.5;
1843\end{cfa}
1844as conversions between intermediate assignments may lose information.
1845A more complex example is:
1846\begin{cfa}
1847[ i, y[i], z ] = a + b;
1848\end{cfa}
1849which is equivalent to:
1850\begin{cfa}
1851t = a + b;
1852a1 = &i; a2 = &y[i]; a3 = &z;
1853*a1 = t; *a2 = t; *a3 = t;
1854\end{cfa}
1855The temporary ©t© is necessary to store the value of the expression to eliminate conversion issues.
1856The temporaries for the addresses are needed so that locations on the left-hand side do not change as the values are assigned.
1857In this case, ©y[i]© uses the previous value of ©i© and not the new value set at the beginning of the mass assignment.
1858
1859
1860\section{Multiple Assignment}
1861
1862\CFA also supports the assignment of several values at once, known as multiple assignment~\cite{CLU,Galletly96}.
1863Multiple assignment has the following form:
1864\begin{cfa}
1865[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
1866\end{cfa}
1867\index{lvalue}
1868The left-hand side is a tuple of \emph{lvalues}, and the right-hand side is a tuple of \emph{expr}s.
1869Each \emph{expr} appearing on the right-hand 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.
1870An example of multiple assignment is:
1871\begin{cfa}
1872[ x, y, z ] = [ 1, 2, 3 ];
1873\end{cfa}
1874Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©.
1875 A more complex example is:
1876\begin{cfa}
1877[ i, y[ i ], z ] = [ 1, i, a + b ];
1878\end{cfa}
1879Here, the values ©1©, ©i© and ©a + b© are assigned to the variables ©i©, ©y[i]© and ©z©, respectively.
1880 Note, the parallel semantics of
1881multiple assignment ensures:
1882\begin{cfa}
1883[ x, y ] = [ y, x ];
1884\end{cfa}
1885correctly interchanges (swaps) the values stored in ©x© and ©y©.
1886The following cases are errors:
1887\begin{cfa}
1888[ a, b, c ] = [ 1, 2, 3, 4 ];
1889[ a, b, c ] = [ 1, 2 ];
1890\end{cfa}
1891because the number of entities in the left-hand tuple is unequal with the right-hand tuple.
1892
1893As 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;
1894both these examples produce indeterminate results:
1895\begin{cfa}
1896f( x++, x++ );                          §\C{// C routine call with side effects in arguments}§
1897[ v1, v2 ] = [ x++, x++ ];      §\C{// side effects in righthand side of multiple assignment}§
1898\end{cfa}
1899
1900
1901\section{Cascade Assignment}
1902
1903As in C, \CFA mass and multiple assignments can be cascaded, producing cascade assignment.
1904Cascade assignment has the following form:
1905\begin{cfa}
1906§\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
1907\end{cfa}
1908and it has the same parallel semantics as for mass and multiple assignment.
1909Some examples of cascade assignment are:
1910\begin{cfa}
1911x1 = y1 = x2 = y2 = 0;
1912[ x1, y1 ] = [ x2, y2 ] = [ x3, y3 ];
1913[ x1, y1 ] = [ x2, y2 ] = 0;
1914[ x1, y1 ] = z = 0;
1915\end{cfa}
1916As in C, the rightmost assignment is performed first, \ie assignment parses right to left.
1917
1918
1919\section{Field Tuples}
1920
1921Tuples may be used to select multiple fields of a record by field name.
1922Its general form is:
1923\begin{cfa}
1924§\emph{expr}§ . [ §\emph{fieldlist}§ ]
1925§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
1926\end{cfa}
1927\emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©.
1928Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
1929A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
1930the following:
1931\begin{cfa}
1932struct s {
1933        int f1, f2;
1934        char f3;
1935        double f4;
1936} v;
1937v.[ f3, f1, f2 ] = ['x', 11, 17 ];      §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§
1938f( v.[ f3, f1, f2 ] );                          §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§
1939\end{cfa}
1940Note, the fields appearing in a record-field tuple may be specified in any order;
1941also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple.
1942
1943If 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:
1944\begin{cfa}
1945struct inner {
1946        int f2, f3;
1947};
1948struct outer {
1949        int f1;
1950        struct inner i;
1951        double f4;
1952} o;
1953
1954o.[ f1, i.[ f2, f3 ], f4 ] = [ 11, 12, 13, 3.14159 ];
1955\end{cfa}
1956
1957
1958\section{Labelled Continue/Break}
1959
1960While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
1961Unfortunately, this restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
1962To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@\lstinline $continue$!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@\lstinline $break$!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}.
1963For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
1964for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
1965\VRef[Figure]{f:MultiLevelResumeTermination} shows the labelled ©continue© and ©break©, specifying which control structure is the target for exit, and the corresponding C program using only ©goto©.
1966The innermost loop has 7 exit points, which cause resumption or termination of one or more of the 7 \Index{nested control-structure}s.
1967
1968\begin{figure}
1969\begin{tabular}{@{\hspace{\parindentlnth}}l@{\hspace{1.5em}}l@{}}
1970\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        \\
1971\begin{cfa}
1972®LC:® {
1973        ... §declarations§ ...
1974        ®LS:® switch ( ... ) {
1975          case 3:
1976                ®LIF:® if ( ... ) {
1977                        ®LF:® for ( ... ) {
1978                                ®LW:® while ( ... ) {
1979                                        ... break ®LC®; ...                     // terminate compound
1980                                        ... break ®LS®; ...                     // terminate switch
1981                                        ... break ®LIF®; ...                    // terminate if
1982                                        ... continue ®LF;® ...   // resume loop
1983                                        ... break ®LF®; ...                     // terminate loop
1984                                        ... continue ®LW®; ...   // resume loop
1985                                        ... break ®LW®; ...               // terminate loop
1986                                } // while
1987                        } // for
1988                } else {
1989                        ... break ®LIF®; ...                                     // terminate if
1990                } // if
1991        } // switch
1992} // compound
1993\end{cfa}
1994&
1995\begin{cfa}
1996{
1997        ... §declarations§ ...
1998        switch ( ... ) {
1999          case 3:
2000                if ( ... ) {
2001                        for ( ... ) {
2002                                while ( ... ) {
2003                                        ... goto ®LC®; ...
2004                                        ... goto ®LS®; ...
2005                                        ... goto ®LIF®; ...
2006                                        ... goto ®LFC®; ...
2007                                        ... goto ®LFB®; ...
2008                                        ... goto ®LWC®; ...
2009                                        ... goto ®LWB®; ...
2010                                  ®LWC®: ; } ®LWB:® ;
2011                          ®LFC:® ; } ®LFB:® ;
2012                } else {
2013                        ... goto ®LIF®; ...
2014                } ®L3:® ;
2015        } ®LS:® ;
2016} ®LC:® ;
2017\end{cfa}
2018\end{tabular}
2019\caption{Multi-level Resume/Termination}
2020\label{f:MultiLevelResumeTermination}
2021\end{figure}
2022
2023\begin{comment}
2024int main() {
2025  LC: {
2026          LS: switch ( 1 ) {
2027                  case 3:
2028                  LIF: if ( 1 ) {
2029                          LF: for ( ;; ) {
2030                                  LW: while ( 1 ) {
2031                                                break LC;                       // terminate compound
2032                                                break LS;                       // terminate switch
2033                                                break LIF;                      // terminate if
2034                                                continue LF;     // resume loop
2035                                                break LF;                       // terminate loop
2036                                                continue LW;     // resume loop
2037                                                break LW;                 // terminate loop
2038                                        } // while
2039                                } // for
2040                        } else {
2041                                break LIF;                                       // terminate if
2042                        } // if
2043                } // switch
2044        } // compound
2045        {
2046                switch ( 1 ) {
2047                  case 3:
2048                        if ( 1 ) {
2049                                for ( ;; ) {
2050                                        while ( 1 ) {
2051                                                goto LCx;
2052                                                goto LSx;
2053                                                goto LIF;
2054                                                goto LFC;
2055                                                goto LFB;
2056                                                goto LWC;
2057                                                goto LWB;
2058                                          LWC: ; } LWB: ;
2059                                  LFC: ; } LFB: ;
2060                        } else {
2061                                goto LIF;
2062                        } L3: ;
2063                } LSx: ;
2064        } LCx: ;
2065}
2066
2067// Local Variables: //
2068// tab-width: 4 //
2069// End: //
2070\end{comment}
2071
2072
2073Both labelled ©continue© and ©break© are a ©goto©\index{goto@\lstinline $goto$!restricted} restricted in the following ways:
2074\begin{itemize}
2075\item
2076They cannot create a loop, which means only the looping constructs cause looping.
2077This restriction means all situations resulting in repeated execution are clearly delineated.
2078\item
2079They cannot branch into a control structure.
2080This restriction prevents missing initialization at the start of a control structure resulting in undefined behaviour.
2081\end{itemize}
2082The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement, and tying control flow to the target control structure rather than an arbitrary point in a program.
2083Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
2084With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
2085Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
2086The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
2087
2088
2089\section{Switch Statement}
2090
2091C allows a number of questionable forms for the ©switch© statement:
2092\begin{enumerate}
2093\item
2094By default, the end of a ©case© clause\footnote{
2095In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
2096\emph{falls through} to the next ©case© clause in the ©switch© statement;
2097to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
2098\begin{cfa}
2099switch ( i ) {
2100  case 1:
2101        ...
2102        // fall-through
2103  case 2:
2104        ...
2105        break;  // exit switch statement
2106}
2107\end{cfa}
2108The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
2109\begin{quote2}
2110\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
2111\begin{cfa}
2112switch ( argc ) {
2113  case 3:
2114        // open output file
2115        // fall-through
2116  case 2:
2117        // open input file
2118        break;  // exit switch statement
2119  default:
2120        // usage message
2121}
2122\end{cfa}
2123&
2124\begin{cfa}
2125
2126if ( argc == 3 ) {
2127        // open output file
2128        ®// open input file
2129®} else if ( argc == 2 ) {
2130        ®// open input file
2131
2132®} else {
2133        // usage message
2134}
2135\end{cfa}
2136\end{tabular}
2137\end{quote2}
2138In this example, case 2 is always done if case 3 is done.
2139This 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.
2140C also uses fall-through to handle multiple case-values resulting in the same action:
2141\begin{cfa}
2142switch ( i ) {
2143  case 1: case 3: case 5:       // odd values
2144        // same action
2145        break;
2146  case 2: case 4: case 6:       // even values
2147        // same action
2148        break;
2149}
2150\end{cfa}
2151However, this situation is handled in other languages without fall-through by allowing a list of case values.
2152While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
2153Hence, 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.
2154
2155\item
2156It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
2157\begin{cfa}
2158switch ( i ) {
2159  case 0:
2160        if ( j < k ) {
2161                ...
2162          ®case 1:®             // transfer into "if" statement
2163                ...
2164        } // if
2165  case 2:
2166        while ( j < 5 ) {
2167                ...
2168          ®case 3:®             // transfer into "while" statement
2169                ...
2170        } // while
2171} // switch
2172\end{cfa}
2173The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
2174The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
2175The technical problem results from the inability to ensure allocation and initialization of variables when blocks are not entered at the beginning.
2176Often transferring into a block can bypass variable declaration and/or its initialization, which results in subsequent errors.
2177There are virtually no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
2178Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
2179\begin{cfa}
2180register int n = (count + 7) / 8;
2181switch ( count % 8 ) {
2182case 0: do{ *to = *from++;
2183case 7:         *to = *from++;
2184case 6:         *to = *from++;
2185case 5:         *to = *from++;
2186case 4:         *to = *from++;
2187case 3:         *to = *from++;
2188case 2:         *to = *from++;
2189case 1:         *to = *from++;
2190                } while ( --n > 0 );
2191}
2192\end{cfa}
2193which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
2194While efficient, this sort of special purpose usage is questionable:
2195\begin{quote}
2196Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
2197discovery.~\cite{Duff83}
2198\end{quote}
2199\item
2200It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
2201Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
2202The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
2203hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
2204This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
2205
2206\item
2207It is possible to place unreachable code at the start of a ©switch© statement, as in:
2208\begin{cfa}
2209switch ( x ) {
2210        ®int y = 1;®                            §\C{// unreachable initialization}§
2211        ®x = 7;®                                        §\C{// unreachable code without label/branch}§
2212  case 3: ...
2213        ...
2214        ®int z = 0;®                            §\C{// unreachable initialization, cannot appear after case}§
2215        z = 2;
2216  case 3:
2217        ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
2218}
2219\end{cfa}
2220While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
2221Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
2222As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
2223The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
2224\end{enumerate}
2225
2226Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
2227\begin{itemize}
2228\item
2229the number of ©switch© statements is small,
2230\item
2231most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
2232\item
2233the ©default© clause is usually written as the last case-clause,
2234\item
2235and 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.
2236\end{itemize}
2237These observations help to put the \CFA changes to the ©switch© into perspective.
2238\begin{enumerate}
2239\item
2240Eliminating default fall-through has the greatest potential for affecting existing code.
2241However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
2242\begin{cfa}
2243case 1:  case 2:  case 3: ...
2244\end{cfa}
2245still works.
2246Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
2247Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, e.g.:
2248\begin{cfa}
2249®choose® ( i ) {
2250  case 1:  case 2:  case 3:
2251        ...
2252        ®// implicit end of switch (break)
2253  ®case 5:
2254        ...
2255        ®fallthru®;                                     §\C{// explicit fall through}§
2256  case 7:
2257        ...
2258        ®break®                                         §\C{// explicit end of switch}§
2259  default:
2260        j = 3;
2261}
2262\end{cfa}
2263Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
2264the implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
2265The explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
2266As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
2267\item
2268\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
2269Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
2270\item
2271The 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 needs to appear is locations other than at the end.
2272Therefore, no change is made for this issue.
2273\item
2274Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
2275Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
2276Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
2277\begin{cfa}
2278switch ( x ) {
2279        ®int i = 0;®                            §\C{// allowed only at start}§
2280  case 0:
2281        ...
2282        ®int j = 0;®                            §\C{// disallowed}§
2283  case 1:
2284        {
2285                ®int k = 0;®                    §\C{// allowed at different nesting levels}§
2286                ...
2287        }
2288  ...
2289}
2290\end{cfa}
2291\end{enumerate}
2292
2293
2294\section{Case Clause}
2295
2296C restricts the ©case© clause of a ©switch© statement to a single value.
2297For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
2298Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
2299Therefore, the ©case© clause is extended with a list of values, as in:
2300\begin{quote2}
2301\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
2302\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
2303\begin{cfa}
2304switch ( i ) {
2305  case ®1, 3, 5®:
2306        ...
2307  case ®2, 4, 6®:
2308        ...
2309}
2310\end{cfa}
2311&
2312\begin{cfa}
2313switch ( i ) {
2314  case 1: case 3 : case 5:
2315        ...
2316  case 2: case 4 : case 6:
2317        ...
2318}
2319\end{cfa}
2320&
2321\begin{cfa}
2322
2323// odd values
2324
2325// even values
2326
2327
2328\end{cfa}
2329\end{tabular}
2330\end{quote2}
2331In addition, two forms of subranges are allowed to specify case values: a new \CFA form and an existing GNU C form.\footnote{
2332The GNU C form \emph{requires} spaces around the ellipse.}
2333\begin{quote2}
2334\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
2335\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}}     \\
2336\begin{cfa}
2337switch ( i ) {
2338  case ®1~5:®
2339        ...
2340  case ®10~15:®
2341        ...
2342}
2343\end{cfa}
2344&
2345\begin{cfa}
2346switch ( i )
2347  case ®1 ... 5®:
2348        ...
2349  case ®10 ... 15®:
2350        ...
2351}
2352\end{cfa}
2353&
2354\begin{cfa}
2355
2356// 1, 2, 3, 4, 5
2357
2358// 10, 11, 12, 13, 14, 15
2359
2360
2361\end{cfa}
2362\end{tabular}
2363\end{quote2}
2364Lists of subranges are also allowed.
2365\begin{cfa}
2366case ®1~5, 12~21, 35~42®:
2367\end{cfa}
2368
2369
2370\section{Exception Handling}
2371
2372Exception handling provides two mechanism: change of control flow from a raise to a handler, and communication from the raise to the handler.
2373\begin{cfa}
2374exception void h( int i );
2375exception int h( int i, double d );
2376
2377void f(...) {
2378        ... throw h( 3 );
2379        ... i = resume h( 3, 5.1 );
2380}
2381
2382try {
2383        f(...);
2384} catch h( int w ) {
2385        // reset
2386} resume h( int p, double x ) {
2387        return 17;  // recover
2388} finally {
2389}
2390\end{cfa}
2391So 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.
2392The 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.
2393
2394
2395\section{I/O Library}
2396\label{s:IOLibrary}
2397\index{input/output library}
2398
2399The goal of \CFA I/O is to simplify the common cases\index{I/O!common case}, while fully supporting polymorphism and user defined types in a consistent way.
2400The \CFA header file for the I/O library is \Indexc{fstream}.
2401
2402The common case is printing out a sequence of variables separated by whitespace.
2403\begin{quote2}
2404\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
2405\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
2406\begin{cfa}
2407int x = 1, y = 2, z = 3;
2408sout | x ®|® y ®|® z | endl;
2409\end{cfa}
2410&
2411\begin{cfa}
2412
2413cout << x ®<< " "® << y ®<< " "® << z << endl;
2414\end{cfa}
2415\\
2416\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
24171 2 3
2418\end{cfa}
2419&
2420\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
24211 2 3
2422\end{cfa}
2423\end{tabular}
2424\end{quote2}
2425The \CFA form has half as many characters as the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators.
2426A tuple prints all the tuple's values, each separated by ©", "©.
2427\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2428[int, int] t1 = [1, 2], t2 = [3, 4];
2429sout | t1 | t2 | endl;                                  §\C{// print tuples}§
2430\end{cfa}
2431\begin{cfa}[mathescape=off,showspaces=true,belowskip=0pt]
24321, 2, 3, 4
2433\end{cfa}
2434\CFA uses the logical-or operator for I/O because it is the lowest-priority overloadable operator, other than assignment.
2435Therefore, fewer output expressions require parenthesis.
2436\begin{quote2}
2437\begin{tabular}{@{}ll@{}}
2438\textbf{\CFA:}
2439&
2440\begin{cfa}
2441sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
2442\end{cfa}
2443\\
2444\textbf{\CC:}
2445&
2446\begin{cfa}
2447cout << x * 3 << y + 1 << ®(®z << 2®)® << ®(®x == y®)® << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
2448\end{cfa}
2449\\
2450&
2451\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
24523 3 12 0 3 1 2
2453\end{cfa}
2454\end{tabular}
2455\end{quote2}
2456Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, where data flows in the correct direction for input but the opposite direction for output.
2457
2458
2459The implicit separator\index{I/O!separator} character (space/blank) is a separator not a terminator.
2460The rules for implicitly adding the separator are:
2461\begin{enumerate}
2462\item
2463A separator does not appear at the start or end of a line.
2464\begin{cfa}[belowskip=0pt]
2465sout | 1 | 2 | 3 | endl;
2466\end{cfa}
2467\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
24681 2 3
2469\end{cfa}
2470
2471\item
2472A separator does not appear before or after a character literal or variable.
2473\begin{cfa}
2474sout | '1' | '2' | '3' | endl;
2475123
2476\end{cfa}
2477
2478\item
2479A separator does not appear before or after a null (empty) C string.
2480\begin{cfa}
2481sout | 1 | "" | 2 | "" | 3 | endl;
2482123
2483\end{cfa}
2484which is a local mechanism to disable insertion of the separator character.
2485
2486\item
2487A separator does not appear before a C string starting with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off,basicstyle=\tt]@([{=$£¥¡¿«@
2488%$
2489\begin{cfa}[mathescape=off]
2490sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
2491                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
2492\end{cfa}
2493%$
2494\begin{cfa}[mathescape=off,basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
2495x ®(®1 x ®[®2 x ®{®3 x ®=®4 x ®$®5 x ®£®6 x ®¥®7 x ®¡®8 x ®¿®9 x ®«®10
2496\end{cfa}
2497%$
2498where \lstinline[basicstyle=\tt]@¡¿@ are inverted opening exclamation and question marks, and \lstinline[basicstyle=\tt]@«@ is an opening citation mark.
2499
2500\item
2501{\lstset{language=CFA,deletedelim=**[is][]{¢}{¢}}
2502A seperator does not appear after a C string ending with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[basicstyle=\tt]@,.;!?)]}%¢»@
2503\begin{cfa}[belowskip=0pt]
2504sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
2505                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
2506\end{cfa}
2507\begin{cfa}[basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
25081®,® x 2®.® x 3®;® x 4®!® x 5®?® x 6®%® x 7§\color{red}\textcent§ x 8®»® x 9®)® x 10®]® x 11®}® x
2509\end{cfa}}%
2510where \lstinline[basicstyle=\tt]@»@ is a closing citation mark.
2511
2512\item
2513A seperator does not appear before or after a C string begining/ending with the \Index*{ASCII} quote or whitespace characters: \lstinline[basicstyle=\tt,showspaces=true]@`'": \t\v\f\r\n@
2514\begin{cfa}[belowskip=0pt]
2515sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
2516\end{cfa}
2517\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
2518x®`®1®`®x§\color{red}\texttt{'}§2§\color{red}\texttt{'}§x§\color{red}\texttt{"}§3§\color{red}\texttt{"}§x®:®4®:®x® ®5® ®x®      ®6®     ®x
2519\end{cfa}
2520
2521\item
2522If a space is desired before or after one of the special string start/end characters, simply insert a space.
2523\begin{cfa}[belowskip=0pt]
2524sout | "x (§\color{red}\texttt{\textvisiblespace}§" | 1 | "§\color{red}\texttt{\textvisiblespace) x" | 2 | "§\color{red}\texttt{\textvisiblespace}§, x" | 3 | "§\color{red}\texttt{\textvisiblespace}§:x:§\color{red}\texttt{\textvisiblespace}§" | 4 | endl;
2525\end{cfa}
2526\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
2527x (® ®1® ®) x 2® ®, x 3® ®:x:® ®4
2528\end{cfa}
2529\end{enumerate}
2530
2531The following routines and \CC-style \Index{manipulator}s control implicit seperation.
2532\begin{enumerate}
2533\item
2534Routines \Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} and \Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} set and get the separator string.
2535The separator string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters).
2536\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2537sepSet( sout, ", $" );                                          §\C{// set separator from " " to ", \$"}§
2538sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"" | endl;
2539\end{cfa}
2540%$
2541\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
25421, $2, $3 ®", $
2543\end{cfa}
2544%$
2545\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2546sepSet( sout, " " );                                            §\C{// reset separator to " "}§
2547sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"" | endl;
2548\end{cfa}
2549\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
25501 2 3 ®" "®
2551\end{cfa}
2552
2553\item
2554Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item.
2555\begin{cfa}[mathescape=off,belowskip=0pt]
2556sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start of line}§
2557\end{cfa}
2558\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
2559 1 2 3
2560\end{cfa}
2561\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2562sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// locally turn off implicit separator}§
2563\end{cfa}
2564\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
256512 3
2566\end{cfa}
2567
2568\item
2569Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.
2570\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2571sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// globally turn off implicit separation}§
2572\end{cfa}
2573\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
2574123
2575\end{cfa}
2576\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2577sout | 1 | sepOn | 2 | 3 | endl;                        §\C{// locally turn on implicit separator}§
2578\end{cfa}
2579\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
25801 23
2581\end{cfa}
2582\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2583sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// globally turn on implicit separation}§
2584\end{cfa}
2585\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
25861 2 3
2587\end{cfa}
2588
2589\item
2590Routine \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} and \Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} get and set the tuple separator-string.
2591The tuple separator-string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters).
2592\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2593sepSetTuple( sout, " " );                                       §\C{// set tuple separator from ", " to " "}§
2594sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"" | endl;
2595\end{cfa}
2596\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
25971 2 3 4 ®" "®
2598\end{cfa}
2599\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2600sepSetTuple( sout, ", " );                                      §\C{// reset tuple separator to ", "}§
2601sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"" | endl;
2602\end{cfa}
2603\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
26041, 2, 3, 4 ®", "®
2605\end{cfa}
2606
2607\item
2608The tuple separator can also be turned on and off.
2609\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
2610sout | sepOn | t1 | sepOff | t2 | endl;         §\C{// locally turn on/off implicit separation}§
2611\end{cfa}
2612\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
2613, 1, 23, 4
2614\end{cfa}
2615Notice a tuple seperator starts the line because the next item is a tuple.
2616\end{enumerate}
2617
2618\begin{comment}
2619#include <fstream>
2620
2621int main( void ) {
2622        int x = 1, y = 2, z = 3;
2623        sout | x | y | z | endl;
2624        [int, int] t1 = [1, 2], t2 = [3, 4];
2625        sout | t1 | t2 | endl;                                          // print tuple
2626        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
2627        sout | 1 | 2 | 3 | endl;
2628        sout | '1' | '2' | '3' | endl;
2629        sout | 1 | "" | 2 | "" | 3 | endl;
2630        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
2631                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
2632        sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
2633                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
2634        sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
2635        sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4 | endl;
2636
2637        sepSet( sout, ", $" );                                          // set separator from " " to ", $"
2638        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
2639        sepSet( sout, " " );                                            // reset separator to " "
2640        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
2641
2642        sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
2643        sout | 1 | sepOff | 2 | 3 | endl;                       // locally turn off implicit separator
2644
2645        sout | sepDisable | 1 | 2 | 3 | endl;           // globally turn off implicit separation
2646        sout | 1 | sepOn | 2 | 3 | endl;                        // locally turn on implicit separator
2647        sout | sepEnable | 1 | 2 | 3 | endl;            // globally turn on implicit separation
2648
2649        sepSetTuple( sout, " " );                                       // set tuple separator from ", " to " "
2650        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
2651        sepSetTuple( sout, ", " );                                      // reset tuple separator to ", "
2652        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
2653
2654        sout | t1 | t2 | endl;                                          // print tuple
2655        sout | sepOn | t1 | sepOff | t2 | endl;         // locally turn on/off implicit separation
2656}
2657
2658// Local Variables: //
2659// tab-width: 4 //
2660// fill-column: 100 //
2661// End: //
2662\end{comment}
2663%$
2664
2665
2666\section{Types}
2667
2668\subsection{Type Definitions}
2669
2670\CFA allows users to define new types using the keyword type.
2671
2672\begin{cfa}
2673// SensorValue is a distinct type and represented as an int
2674type SensorValue = int;
2675\end{cfa}
2676
2677A 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.
2678This means that users can define distinct function overloads for the new type (see Overloading for more information).
2679For example:
2680
2681\begin{cfa}
2682type SensorValue = int;
2683void printValue(int v) {...}
2684void printValue(SensorValue v) {...}
2685void process(int v) {...}
2686
2687SensorValue s = ...;
2688
2689printValue(s); // calls version with SensorValue argument
2690
2691printValue((int) s); // calls version with int argument
2692
2693process(s); // implicit conversion to int
2694\end{cfa}
2695
2696If SensorValue was defined with a typedef, then these two print functions would not have unique signatures.
2697This can be very useful to create a distinct type that has the same representation as another type.
2698
2699The compiler will assume it can safely convert from the old type to the new type, implicitly.
2700Users may override this and define a function that must be called to convert from one type to another.
2701
2702\begin{cfa}
2703type SensorValue = int;
2704// ()? is the overloaded conversion operator identifier
2705// This function converts an int to a SensorValue
2706SensorValue ()?(int val) {
2707        ...
2708}
2709void process(int v) {...}
2710
2711SensorValue s = ...;
2712process(s); // implicit call to conversion operator
2713\end{cfa}
2714
2715In many cases, it is not desired for the compiler to do this implicit conversion.
2716To avoid that, the user can use the explicit modifier on the conversion operator.
2717Any places where the conversion is needed but not explicit (with a cast), will result in a compile-time error.
2718
2719\begin{cfa}
2720type SensorValue = int;
2721
2722// conversion from int to SensorValue; must be explicit
2723explicit SensorValue ()?(int val) {
2724        ...
2725}
2726
2727void process(int v) {...}
2728
2729SensorValue s = ...;
2730process(s); // implicit cast to int: compile-time error
2731process((int) s); // explicit cast to int: calls conversion func
2732\end{cfa}
2733
2734The conversion may not require any code, but still need to be explicit; in that case, the syntax can be simplified to:
2735\begin{cfa}
2736type SensorValue = int;
2737explicit SensorValue ()?(int);
2738void process(int v) {...}
2739
2740SensorValue s = ...;
2741process(s); // compile-time error
2742process((int) s); // type is converted, no function is called
2743\end{cfa}
2744
2745
2746\subsection{Structures}
2747
2748Structures in \CFA are basically the same as structures in C.
2749A structure is defined with the same syntax as in C.
2750When referring to a structure in \CFA, users may omit the struct keyword.
2751\begin{cfa}
2752struct Point {
2753        double x;
2754        double y;
2755};
2756
2757Point p = {0.0, 0.0};
2758\end{cfa}
2759
2760\CFA does not support inheritance among types, but instead uses composition to enable reuse of structure fields.
2761Composition is achieved by embedding one type into another.
2762When 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.
2763Embedding types is achieved using anonymous members.
2764For example, using Point from above:
2765\begin{cfa}
2766void foo(Point p);
2767
2768struct ColoredPoint {
2769        Point; // anonymous member (no identifier)
2770        int Color;
2771};
2772...
2773        ColoredPoint cp = ...;
2774        cp.x = 10.3; // x from Point is accessed directly
2775        cp.color = 0x33aaff; // color is accessed normally
2776        foo(cp); // cp can be used directly as a Point
2777\end{cfa}
2778
2779
2780\subsection{Constructors and Destructors}
2781
2782\CFA supports C initialization of structures, but it also adds constructors for more advanced initialization.
2783Additionally, \CFA adds destructors that are called when a variable is deallocated (variable goes out of scope or object is deleted).
2784These functions take a reference to the structure as a parameter (see References for more information).
2785
2786\begin{figure}
2787\begin{cfa}
2788struct Widget {
2789        int id;
2790        float size;
2791        Parts *optionalParts;
2792};
2793
2794// ?{} is the constructor operator identifier
2795// The first argument is a reference to the type to initialize
2796// Subsequent arguments can be specified for initialization
2797
2798void ?{}(Widget &w) { // default constructor
2799        w.id = -1;
2800        w.size = 0.0;
2801        w.optionalParts = 0;
2802}
2803
2804// constructor with values (does not need to include all fields)
2805void ?{}(Widget &w, int id, float size) {
2806        w.id = id;
2807        w.size = size;
2808        w.optionalParts = 0;
2809}
2810
2811// ^? is the destructor operator identifier
2812void ^?(Widget &w) { // destructor
2813        w.id = 0;
2814        w.size = 0.0;
2815        if (w.optionalParts != 0) {
2816        // This is the only pointer to optionalParts, free it
2817        free(w.optionalParts);
2818        w.optionalParts = 0;
2819        }
2820}
2821
2822Widget baz; // reserve space only
2823Widget foo{}; // calls default constructor
2824Widget bar{23, 2.45}; // calls constructor with values
2825baz{24, 0.91}; // calls constructor with values
2826?{}(baz, 24, 0.91}; // explicit call to constructor
2827^bar; // explicit call to destructor
2828^?(bar); // explicit call to destructor
2829\end{cfa}
2830\caption{Constructors and Destructors}
2831\end{figure}
2832
2833
2834\section{Overloading}
2835
2836Overloading refers to the capability of a programmer to define and use multiple objects in a program with the same name.
2837In \CFA, a declaration may overload declarations from outer scopes with the same name, instead of hiding them as is the case in C.
2838This may cause identical C and \CFA programs to behave differently.
2839The compiler selects the appropriate object (overload resolution) based on context information at the place where it is used.
2840Overloading allows programmers to give functions with different signatures but similar semantics the same name, simplifying the interface to users.
2841Disadvantages 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.
2842\CFA allows overloading of functions, operators, variables, and even the constants 0 and 1.
2843
2844The compiler follows some overload resolution rules to determine the best interpretation of all of these overloads.
2845The best valid interpretations are the valid interpretations that use the fewest unsafe conversions.
2846Of these, the best are those where the functions and objects involved are the least polymorphic.
2847Of these, the best have the lowest total conversion cost, including all implicit conversions in the argument expressions.
2848Of these, the best have the highest total conversion cost for the implicit conversions (if any) applied to the argument expressions.
2849If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous.
2850For details about type inference and overload resolution, please see the \CFA Language Specification.
2851\begin{cfa}
2852int foo(int a, int b) {
2853        float sum = 0.0;
2854        float special = 1.0;
2855        {
2856                int sum = 0;
2857                // both the float and int versions of sum are available
2858                float special = 4.0;
2859                // this inner special hides the outer version
2860                ...
2861        }
2862        ...
2863}
2864\end{cfa}
2865
2866
2867\subsection{Overloaded Constant}
2868
2869The constants 0 and 1 have special meaning.
2870In \CFA, as in C, all scalar types can be incremented and
2871decremented, which is defined in terms of adding or subtracting 1.
2872The 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)©).
2873
2874In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a special case.
2875However, user-defined arithmetic types often need the equivalent of a 1 or 0 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
2876Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
2877
2878Why just 0 and 1? Why not other integers? No other integers have special status in C.
2879A facility that let programmers declare specific constants..const Rational 12., for instance. would not be much of an improvement.
2880Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
2881The complexity of such a feature does not seem worth the gain.
2882
2883For example, to define the constants for a complex type, the programmer would define the following:
2884
2885\begin{cfa}
2886struct Complex {
2887        double real;
2888        double imaginary;
2889}
2890
2891const Complex 0 = {0, 0};
2892const Complex 1 = {1, 0};
2893...
2894
2895        Complex a = 0;
2896...
2897
2898        a++;
2899...
2900        if (a) { // same as if (a == 0)
2901...
2902}
2903\end{cfa}
2904
2905
2906\subsection{Variable Overloading}
2907
2908The overload rules of \CFA allow a programmer to define multiple variables with the same name, but different types.
2909Allowing 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.
2910For example, a developer may want to do the following:
2911\begin{cfa}
2912int pi = 3;
2913float pi = 3.14;
2914char pi = .p.;
2915\end{cfa}
2916
2917
2918\subsection{Function Overloading}
2919
2920Overloaded 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).
2921
2922The examples below give some basic intuition about how the resolution works.
2923\begin{cfa}
2924// Choose the one with less conversions
2925int doSomething(int value) {...} // option 1
2926int doSomething(short value) {...} // option 2
2927
2928int a, b = 4;
2929short c = 2;
2930
2931a = doSomething(b); // chooses option 1
2932a = doSomething(c); // chooses option 2
2933
2934// Choose the specialized version over the generic
2935
2936generic(type T)
2937T bar(T rhs, T lhs) {...} // option 3
2938float bar(float rhs, float lhs){...} // option 4
2939float a, b, c;
2940double d, e, f;
2941c = bar(a, b); // chooses option 4
2942
2943// specialization is preferred over unsafe conversions
2944
2945f = bar(d, e); // chooses option 5
2946\end{cfa}
2947
2948
2949\subsection{Operator Overloading}
2950
2951\CFA also allows operators to be overloaded, to simplify the use of user-defined types.
2952Overloading 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.
2953\CFA uses the following special identifiers to name overloaded operators:
2954
2955\begin{table}[hbt]
2956\hfil
2957\begin{tabular}[t]{ll}
2958%identifier & operation \\ \hline
2959©?[?]© & subscripting \impl{?[?]}\\
2960©?()© & function call \impl{?()}\\
2961©?++© & postfix increment \impl{?++}\\
2962©?--© & postfix decrement \impl{?--}\\
2963©++?© & prefix increment \impl{++?}\\
2964©--?© & prefix decrement \impl{--?}\\
2965©*?© & dereference \impl{*?}\\
2966©+?© & unary plus \impl{+?}\\
2967©-?© & arithmetic negation \impl{-?}\\
2968©~?© & bitwise negation \impl{~?}\\
2969©!?© & logical complement \impl{"!?}\\
2970©?*?© & multiplication \impl{?*?}\\
2971©?/?© & division \impl{?/?}\\
2972\end{tabular}\hfil
2973\begin{tabular}[t]{ll}
2974%identifier & operation \\ \hline
2975©?%?© & remainder \impl{?%?}\\
2976©?+?© & addition \impl{?+?}\\
2977©?-?© & subtraction \impl{?-?}\\
2978©?<<?© & left shift \impl{?<<?}\\
2979©?>>?© & right shift \impl{?>>?}\\
2980©?<?© & less than \impl{?<?}\\
2981©?<=?© & less than or equal \impl{?<=?}\\
2982©?>=?© & greater than or equal \impl{?>=?}\\
2983©?>?© & greater than \impl{?>?}\\
2984©?==?© & equality \impl{?==?}\\
2985©?!=?© & inequality \impl{?"!=?}\\
2986©?&& bitwise AND \impl{?&?}\\
2987\end{tabular}\hfil
2988\begin{tabular}[t]{ll}
2989%identifier & operation \\ \hline
2990©?^& exclusive OR \impl{?^?}\\
2991©?|?© & inclusive OR \impl{?"|?}\\
2992©?=?© & simple assignment \impl{?=?}\\
2993©?*=?© & multiplication assignment \impl{?*=?}\\
2994©?/=?© & division assignment \impl{?/=?}\\
2995©?%=?© & remainder assignment \impl{?%=?}\\
2996©?+=?© & addition assignment \impl{?+=?}\\
2997©?-=?© & subtraction assignment \impl{?-=?}\\
2998©?<<=?© & left-shift assignment \impl{?<<=?}\\
2999©?>>=?© & right-shift assignment \impl{?>>=?}\\
3000©?&=?© & bitwise AND assignment \impl{?&=?}\\
3001©?^=?© & exclusive OR assignment \impl{?^=?}\\
3002©?|=?© & inclusive OR assignment \impl{?"|=?}\\
3003\end{tabular}
3004\hfil
3005\caption{Operator Identifiers}
3006\label{opids}
3007\end{table}
3008
3009These identifiers are defined such that the question marks in the name identify the location of the operands.
3010These operands represent the parameters to the functions, and define how the operands are mapped to the function call.
3011For example, ©a + b© becomes ©?+?(a, b)©.
3012
3013In the example below, a new type, myComplex, is defined with an overloaded constructor, + operator, and string operator.
3014These operators are called using the normal C syntax.
3015
3016\begin{cfa}
3017type Complex = struct { // define a Complex type
3018        double real;
3019        double imag;
3020}
3021
3022// Constructor with default values
3023
3024void ?{}(Complex &c, double real = 0.0, double imag = 0.0) {
3025        c.real = real;
3026        c.imag = imag;
3027}
3028
3029Complex ?+?(Complex lhs, Complex rhs) {
3030        Complex sum;
3031        sum.real = lhs.real + rhs.real;
3032        sum.imag = lhs.imag + rhs.imag;
3033        return sum;
3034}
3035
3036String ()?(const Complex c) {
3037        // use the string conversions for the structure members
3038        return (String)c.real + . + . + (String)c.imag + .i.;
3039}
3040...
3041
3042Complex a, b, c = {1.0}; // constructor for c w/ default imag
3043...
3044c = a + b;
3045print(.sum = . + c);
3046\end{cfa}
3047
3048
3049\section{Auto Type-Inferencing}
3050
3051Auto type-inferencing occurs in a declaration where a variable's type is inferred from its initialization expression type.
3052\begin{quote2}
3053\begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
3054\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{\textbf{\Indexc{gcc}}} \\
3055\begin{cfa}
3056
3057auto j = 3.0 * 4;
3058int i;
3059auto k = i;
3060\end{cfa}
3061&
3062\begin{cfa}
3063#define expr 3.0 * i
3064typeof(expr) j = expr;
3065int i;
3066typeof(i) k = i;
3067\end{cfa}
3068&
3069\begin{cfa}
3070
3071// use type of initialization expression
3072
3073// use type of primary variable
3074\end{cfa}
3075\end{tabular}
3076\end{quote2}
3077The two important capabilities are:
3078\begin{itemize}
3079\item
3080preventing having to determine or write out long generic types,
3081\item
3082ensure secondary variables, related to a primary variable, always have the same type.
3083\end{itemize}
3084
3085In \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.
3086\Indexc{gcc} provides ©typeof© to declare a secondary variable from a primary variable.
3087\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.
3088Only for overloaded routines with the same return type is variable type-inferencing possible.
3089Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed.
3090For example, given
3091\begin{cfa}
3092auto j = ®...®
3093\end{cfa}
3094and the need to write a routine to compute using ©j©
3095\begin{cfa}
3096void rtn( ®...® parm );
3097rtn( j );
3098\end{cfa}
3099A programmer must work backwards to determine the type of ©j©'s initialization expression, reconstructing the possibly long generic type-name.
3100In this situation, having the type name or a short alias is very useful.
3101
3102There is also the conundrum in type inferencing of when to \emph{\Index{brand}} a type.
3103That is, when is the type of the variable more important than the type of its initialization expression.
3104For example, if a change is made in an initialization expression, it can cause hundreds or thousands of cascading type changes and/or errors.
3105At some point, a programmer wants the type of the variable to remain constant and the expression to be in error when it changes.
3106
3107Given ©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.
3108Should a significant need arise, this feature can be revisited.
3109
3110
3111\section{Generics}
3112
3113\CFA supports parametric polymorphism to allow users to define generic functions and types.
3114Generics allow programmers to use type variables in place of concrete types so that the code can be reused with multiple types.
3115The type parameters can be restricted to satisfy a set of constraints.
3116This enables \CFA to build fully compiled generic functions and types, unlike other languages like \Index*[C++]{\CC{}} where templates are expanded or must be explicitly instantiated.
3117
3118
3119\subsection{Generic Functions}
3120
3121Generic functions in \CFA are similar to template functions in \Index*[C++]{\CC{}}, and will sometimes be expanded into specialized versions, just like in \CC.
3122The 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.
3123This means that compiled libraries can contain generic functions that can be used by programs linked with them (statically or dynamically).
3124Another advantage over \CC templates is unlike templates, generic functions are statically checked, even without being instantiated.
3125
3126A simple example of using Do.s parametric polymorphism to create a generic swap function would look like this:
3127
3128\begin{cfa}
3129generic(type T)
3130void swap(T &a, T &b) {
3131        T tmp = a;
3132        a = b;
3133        b = a;
3134}
3135
3136int a, b;
3137swap(a, b);
3138
3139Point p1, p2;
3140swap(p1, p2);
3141\end{cfa}
3142
3143Here, instead of specifying types for the parameters a and b, the function has a generic type parameter, type T.
3144This 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.
3145
3146
3147\subsection{Bounded Quantification}
3148
3149Some generic functions only work (or make sense) for any type that satisfies a given property.
3150For example, here is a function to pick the minimum of two values of some type.
3151\begin{cfa}
3152generic (type T | bool ?<?(T, T) )
3153
3154T min( T a, T b ) {
3155        return a < b ? a : b;
3156}
3157\end{cfa}
3158
3159It 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.
3160The ordering function used here is the less than operator, <.
3161The syntax used to reference the operator is discussed in further detail in Operator Overloading.
3162In \CFA, this assertion on the type of a generic is written as the bound, (type T | bool ?<?(T, T)).
3163The \CFA compiler enforces that minis only called with types for which the less than operator is defined, and reports a compile-time error otherwise.
3164
3165Bounds can also involve multiple types, and multiple requirements, as shown below:
3166\begin{cfa}
3167generic (type T, type U | { T foo(T, U); U bar(U); })
3168
3169T baz(T t, U u) {
3170        return foo(t, bar(u));
3171}
3172\end{cfa}
3173
3174
3175\subsection{Interfaces}
3176
3177Type bounds as shown above are not very informative, merely requiring that a function exists with the right name and type.
3178Suppose you try to call a polymorphic function and \CFA gives you an error that int combine(int, int) is not defined.
3179Can 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.
3180The function signature doesn't say.
3181
3182Interfaces gather together a set of function signatures under a common name, which solves two problems.
3183First, an interface name can be used in type bounds instead of function signatures.
3184This avoids repetition when a bound is used in many functions.
3185Second, interfaces explicitly document the existence of a commonly used set of functionality, making programs easier to understand.
3186\begin{cfa}
3187generic (type T)
3188interface Orderable {
3189        bool ?<?(T, T);
3190};
3191
3192generic (type T | Orderable(T))
3193T min( T a, T b ) {
3194        return a < b ? a : b;
3195}
3196\end{cfa}
3197
3198This definition of the interface Orderable makes the generic function min easier to read and understand.
3199Orderable can also be reused for other generic functions, max for example.
3200Interfaces can also build on top of other interfaces.
3201For example:
3202\begin{cfa}
3203generic (type T | Orderable(T)
3204interface FooBarable {
3205        int foo(T, T);
3206        int Bar(T, T);
3207};
3208\end{cfa}
3209
3210The FooBarable interface specifies all of the bounds of the Orderable interface, plus the additional bounds specified in its definition.
3211A type does not need to specify that it satisfies any interface, the compiler can figure this out at compile time.
3212For 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.
3213
3214
3215\subsection{Generic Typedefs}
3216
3217Type synonyms can be defined generically using the typedef keyword together with a generic type annotation.
3218These can be used to abbreviate complicated type expressions, especially in generic code.
3219\begin{cfa}
3220// typedef the generic function pointers for later use
3221
3222generic(type T)
3223typedef int (*predicate)(T);
3224generic(type Captured, type T)
3225typedef void (*callback)(Captured, T);
3226
3227generic(type T)
3228void find(int length, T *array,
3229        predicate(T) p, callback(void *, T)f) {
3230        int i;
3231        for (i = 0; i < length; i++)
3232        if (p(array[i])) f(NULL, array[i]);
3233}
3234\end{cfa}
3235
3236
3237\subsection{Generic Types}
3238
3239Generic types are defined using the same mechanisms as those described above for generic functions.
3240This feature allows users to create types that have one or more fields that use generic parameters as types, similar to a template classes in \Index*[C++]{\CC{}}.
3241For 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.
3242In C, something like this would have to be done using void pointers and unsafe casting.
3243As 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.
3244This means that a \CFA generic type from a compiled library can be used with any type that satisfies the bounds.
3245
3246The syntax for defining a generic type looks very similar to that of a generic function.
3247Generic types support bounds and interfaces, using the same syntax as generic functions.
3248\begin{cfa}
3249generic (type T)
3250struct LinkedListElem {
3251        T elem;
3252        LinkedListElem(T) *next;
3253};
3254
3255LinkedListElem *++?(LinkedListElem **elem) {
3256        return *elem = elem->next;
3257}
3258
3259generic (type T)
3260struct LinkedList {
3261        LinkedListElem(T) *head;
3262        unsigned int size;
3263}
3264
3265generic (type T | bool ?==?(T, T))
3266bool contains(LinkedList(T) *list, T elem) {
3267        for(LinkedListElem *iter = list->head; iter != 0; ++iter) {
3268        if (iter->elem == elem) return true;
3269        }
3270        return false;
3271}
3272\end{cfa}
3273
3274
3275\section{Safety}
3276
3277Safety, along with productivity, is a key goal of Do.
3278This section discusses the safety features that have been included in \CFA to help programmers create more stable, reliable, and secure code.
3279
3280
3281\subsection{Exceptions}
3282
3283\CFA introduces support for exceptions as an easier way to recover from exceptional conditions that may be detected within a block of code.
3284In C, developers can use error codes and special return values to report to a caller that an error occurred in a function.
3285The major problem with error codes is that they can be easily ignored by the caller.
3286Failure 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.
3287An unhandled exception on the other hand will cause a crash, revealing the original source of the erroneous state.
3288
3289Exceptions in \CFA allow a different type of control flow.
3290Throwing 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.
3291The exception is immediately re-thrown from the parent block unless it is caught as described below.
3292\CFA uses keywords similar to \Index*[C++]{\CC{}} for exception handling.
3293An exception is thrown using a throw statement, which accepts one argument.
3294
3295\begin{cfa}
3296        ...
3297
3298        throw 13;
3299
3300        ...
3301\end{cfa}
3302
3303An exception can be caught using a catch statement, which specifies the type of the exception it can catch.
3304A catch is specified immediately after a guarded block to signify that it can catch an exception from that block.
3305A guarded block is specified using the try keyword, followed by a block of code inside of curly braces.
3306
3307\begin{cfa}
3308        ...
3309
3310        try {
3311                throw 13;
3312        }
3313        catch(int e) {
3314                printf(.caught an exception: %d\n., e);
3315        }
3316\end{cfa}
3317
3318
3319\subsection{Memory Management}
3320
3321
3322\subsubsection{Manual Memory Management}
3323
3324Using malloc and free to dynamically allocate memory exposes several potential, and common, errors.
3325First, malloc breaks type safety because it returns a pointer to void.
3326There is no relationship between the type that the returned pointer is cast to, and the amount of memory allocated.
3327This problem is solved with a type-safe malloc.
3328Do.s type-safe malloc does not take any arguments for size.
3329Instead, it infers the type based on the return value, and then allocates space for the inferred type.
3330
3331\begin{cfa}
3332float *f = malloc(); // allocates the size of a float
3333
3334struct S {
3335        int i, j, k;
3336};
3337
3338struct S *s = malloc(); // allocates the size of a struct S
3339\end{cfa}
3340
3341In addition to the improved malloc, \CFA also provides a technique for combining allocation and initialization into one step, using the new function.
3342For all constructors defined for a given type (see Operator Overloading), a corresponding call to new can be used to allocate and construct that type.
3343
3344\begin{cfa}
3345type Complex = struct {
3346        float real;
3347        float imag;
3348};
3349
3350// default constructor
3351
3352void ?{}(Complex &c) {
3353        c.real = 0.0;
3354        c.imag = 0.0;
3355}
3356
3357
3358
3359// 2 parameter constructor
3360
3361void ?{}(Complex &c, float real, float imag) {
3362        c.real = real;
3363        c.imag = imag;
3364}
3365
3366
3367int main() {
3368        Complex c1; // No constructor is called
3369        Complex c2{}; // Default constructor called
3370        Complex c3{1.0, -1.0}; // 2 parameter constructor is called
3371
3372        Complex *p1 = malloc(); // allocate
3373        Complex *p2 = new(); // allocate + default constructor
3374        Complex *p3 = new(0.5, 1.0); // allocate + 2 param constructor
3375}
3376
3377\end{cfa}
3378
3379
3380\subsubsection{Automatic Memory Management}
3381
3382\CFA may also support automatic memory management to further improve safety.
3383If 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.
3384This feature requires further investigation.
3385\CFA will not have a garbage collector, but might use some kind of region-based memory management.
3386
3387
3388\subsection{Unsafe C Constructs}
3389
3390C programmers are able to access all of the low-level tricks that are sometimes needed for close-to-the-hardware programming.
3391Some of these practices however are often error-prone and difficult to read and maintain.
3392Since \CFA is designed to be safer than C, such constructs are disallowed in \CFA code.
3393If 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.
3394This block means that the user is telling the tools, .I know this is unsafe, but I.m going to do it anyway..
3395
3396The 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.
3397Once the full set is decided, the rules will be listed here.
3398
3399
3400\section{Concurrency}
3401
3402Today's processors for nearly all use cases, ranging from embedded systems to large cloud computing servers, are composed of multiple cores, often heterogeneous.
3403As machines grow in complexity, it becomes more difficult for a program to make the most use of the hardware available.
3404\CFA includes built-in concurrency features to enable high performance and improve programmer productivity on these multi-/many-core machines.
3405
3406Concurrency support in \CFA is implemented on top of a highly efficient runtime system of light-weight, M:N, user level threads.
3407The model integrates concurrency features into the language by making the structure type the core unit of concurrency.
3408All communication occurs through method calls, where data is sent via method arguments, and received via the return value.
3409This enables a very familiar interface to all programmers, even those with no parallel programming experience.
3410It also allows the compiler to do static type checking of all communication, a very important safety feature.
3411This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement
3412channels exactly, as well as create additional communication patterns that channels cannot.
3413Mutex objects, monitors, are used to contain mutual exclusion within an object and synchronization across concurrent threads.
3414
3415Three new keywords are added to support these features:
3416
3417monitor creates a structure with implicit locking when accessing fields
3418
3419mutex implies use of a monitor requiring the implicit locking
3420
3421task creates a type with implicit locking, separate stack, and a thread
3422
3423
3424\subsection{Monitors}
3425
3426A monitor is a structure in \CFA which includes implicit locking of its fields.
3427Users of a monitor interact with it just like any structure, but the compiler handles code as needed to ensure mutual exclusion.
3428An example of the definition of a monitor is shown here:
3429\begin{cfa}
3430type Account = monitor {
3431        const unsigned long number; // account number
3432        float balance; // account balance
3433};
3434\end{cfa}
3435
3436Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor;
3437it is always passed by reference.
3438Users can specify to the compiler whether or not a function will require mutual exclusion of the monitor using the mutex modifier on the parameter.
3439When mutex is specified, the compiler inserts locking before executing the body of the function, and unlocking after the body.
3440This means that a function requiring mutual exclusion could block if the lock is already held by another thread.
3441Blocking 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.
3442If multiple mutex parameters are specified, they will be locked in parameter order (\ie first parameter is locked first) and unlocked in the
3443reverse order.
3444\begin{cfa}
3445// This function accesses a constant field, it does not require
3446// mutual exclusion
3447
3448export unsigned long getAccountNumber(Account &a) {
3449        return a.number;
3450}
3451
3452// This function accesses and modifies a shared field; it
3453// requires mutual exclusion
3454
3455export float withdrawal(mutex Account &a, float amount) {
3456        a.balance -= amount;
3457        return a.balance;
3458}
3459\end{cfa}
3460
3461Often, one function using a monitor will call another function using that same monitor.
3462If both require mutual exclusion, then the thread would be waiting for itself to release the lock when it calls the inner function.
3463This 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.
3464It will still be unlocked the same number of times.
3465An example of this situation is shown below:
3466
3467\begin{cfa}
3468// deleting a job from a worker requires mutual exclusion
3469
3470void deleteJob(mutex Worker &w, Job &j) {
3471        ...
3472}
3473
3474// transferring requires mutual exclusion and calls deleteJob
3475
3476void transferJob(mutex Worker &from, Worker &to) {
3477        ...
3478        deleteJob(j);
3479        ...
3480}
3481\end{cfa}
3482
3483
3484\subsection{Tasks}
3485
3486\CFA also provides a simple mechanism for creating and utilizing user level threads.
3487A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
3488Similar to a monitor, a task is defined like a structure:
3489\begin{cfa}
3490type Adder = task {
3491        int *row;
3492        int size;
3493        int &subtotal;
3494}
3495\end{cfa}
3496
3497A task may define a constructor, which will be called upon allocation and run on the caller.s thread.
3498A destructor may also be defined, which is called at deallocation (when a dynamic object is deleted or when a local object goes out of scope).
3499After a task is allocated and initialized, its thread is spawned implicitly and begins executing in its function call method.
3500All tasks must define this function call method, with a void return value and no additional parameters, or the compiler will report an error.
3501Below are example functions for the above Adder task, and its usage to sum up a matrix on multiple threads.
3502(Note that this example is designed to display the syntax and functionality, not the best method to solve this problem)
3503\begin{cfa}
3504void ?{}(Adder &a, int r[], int s, int &st) { // constructor
3505        a.row = r;
3506        a.size = s;
3507        a.subtotal = st;
3508}
3509
3510// implicitly spawn thread and begin execution here
3511
3512void ?()(Adder &a) {
3513        int c;
3514        subtotal = 0;
3515        for (c=0; c<a.size; ++c) {
3516        subtotal += row[c];
3517        }
3518}
3519
3520int main() {
3521        const int rows = 100, cols = 1000000;
3522        int matrix[rows][cols];
3523        int subtotals[rows];
3524        int total = 0;
3525        int r;
3526
3527        { // create a new scope here for our adders
3528        Adder adders[rows];
3529        // read in the matrix
3530        ...
3531        for (r=0; r<rows; ++r) {
3532        // tasks are initialized on this thread
3533        Adders[r] = {matrix[r], cols, subtotals[r]};
3534        Adders[r](); // spawn thread and begin execution
3535        }
3536        } // adders go out of scope; block here until they all finish
3537        total += subtotals[r];
3538        printf(.total is %d\n., total);
3539}
3540\end{cfa}
3541
3542
3543\subsection{Cooperative Scheduling}
3544
3545Tasks in \CFA are cooperatively scheduled, meaning that a task will not be interrupted by another task, except at specific yield points.
3546In Listing 31, there are no yield points, so each task runs to completion with no interruptions.
3547Places 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.
3548This 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.
3549For example, the code below defines a monitor that maintains a generic list.
3550When 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.
3551Similarly, 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.
3552
3553\begin{cfa}
3554// type T is used as a generic type for all definitions inside
3555// the curly brackets
3556
3557generic(type T) {
3558        type Channel = monitor {
3559        List(T) list; // list is a simple generic list type
3560        };
3561
3562        T pop(mutex &Channel(T) ch) {
3563        if (ch.list.empty()) {
3564        // yield until push is called for this channel
3565        yield(push);
3566        }
3567        return ch.list.pop();
3568        }
3569
3570        void push(mutex &Channel(T)ch, T val) {
3571        if (ch.list.full()) {
3572        // yield until pop is called for this channel
3573        yield(pop);
3574        }
3575        ch.list.push(val);
3576        }
3577}
3578\end{cfa}
3579
3580A task can also yield indefinitely by calling yield with no arguments.
3581This will tell the scheduler to yield this task until it is resumed by some other task.
3582A task can resume another task by using its functional call operator.
3583The code below shows a simple ping-pong example, where two tasks yield back and forth to each other using these methods.
3584
3585\begin{cfa}
3586type Ping = task {
3587        Pong *partner;
3588};
3589
3590void ?{}(Ping &p, Pong *partner = 0) {
3591        p.partner = partner;
3592}
3593
3594void ?()(Ping &p) {
3595        for(;;) { // loop forever
3596        printf(.ping\n.);
3597        partner(); // resumes the partner task
3598        yield(); // yields this task
3599        }
3600}
3601
3602type Pong = task {
3603        Ping *partner;
3604};
3605
3606void ?{}(Pong &p, Ping *partner = 0) {
3607        p.partner = partner;
3608}
3609
3610void ?()(Pong &p) {
3611        for(;;) { // loop forever
3612        yield(); // yields this task
3613        printf(.pong/n.);
3614        partner(); // resumes the partner task
3615        }
3616}
3617
3618void main() {
3619        Ping ping; // allocate ping
3620        Pong pong{ping}; // allocate, initialize, and start pong
3621        Ping{pong}; // initialize and start ping
3622}
3623\end{cfa}
3624
3625The same functionality can be accomplished by providing functions to be called by the partner task.
3626\begin{cfa}
3627type Pingpong = task {
3628        String msg;
3629        Pingpong *partner;
3630};
3631
3632void ?{}(Pingpong &p, String msg, Pingpong *partner = 0) {
3633        p.msg = msg;
3634        p.partner = partner;
3635}
3636
3637void ?()(Pingpong &p) {
3638        for(;;) {
3639        yield(go);
3640        }
3641}
3642
3643void go(Pingpong &p) {
3644        print(.%(p.msg)\n.);
3645        go(p.partner);
3646}
3647
3648void main() {
3649        Pingpong ping = {.ping.};
3650        Pingpong pong = {.pong., ping};
3651        ping.partner = pong;
3652        go(ping);
3653}
3654\end{cfa}
3655
3656
3657\section{Modules and Packages }
3658
3659\begin{comment}
3660High-level encapsulation is useful for organizing code into reusable units, and accelerating compilation speed.
3661\CFA provides a convenient mechanism for creating, building and sharing groups of functionality that enhances productivity and improves compile time.
3662
3663There are two levels of encapsulation in \CFA, module and package.
3664A module is a logical grouping of functionality that can be easily pulled into another project, much like a module in \Index*{Python} or a package in \Index*{Go}.
3665A module forms a namespace to limit the visibility and prevent naming conflicts of variables.
3666Furthermore, a module is an independent translation unit, which can be compiled separately to accelerate the compilation speed.
3667
3668A package is a physical grouping of one or more modules that is used for code distribution and version management.
3669Package is also the level of granularity at which dependences are managed.
3670A package is similar to the Crate in \Index*{Rust}.
3671
3672
3673\subsection{No Declarations, No Header Files}
3674
3675In C and \Index*[C++]{\CC{}}, it is necessary to declare or define every global variable, global function, and type before it is used in each file.
3676Header files and a preprocessor are normally used to avoid repeating code.
3677Thus, many variables, functions, and types are described twice, which exposes an opportunity for errors and causes additional maintenance work.
3678Instead of following this model, the \CFA tools can extract all of the same information from the code automatically.
3679This 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.
3680In 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.
3681This seems like a minor change, but according to (Pike, \Index*{Go} at Google: Language Design in the Service of Software Engineering), this simple change can cause massive reductions in compile time.
3682
3683In \CFA, multiple definitions are not necessary.
3684Within a module, all of the module's global definitions are visible throughout the module.
3685For example, the following code compiles, even though ©isOdd© was not declared before being called:
3686\begin{cfa}
3687bool isEven(unsigned int x) {
3688        if (x == 0) return true;
3689        else return !isOdd(x);
3690}
3691
3692bool isOdd(unsigned int x) {
3693        if (x == 1) return true;
3694        else return !isEven(x - 2);
3695}
3696\end{cfa}
3697
3698Header files in C are used to expose the declarations from a library, so that they can be used externally.
3699With \CFA, this functionality is replaced with module exports, discussed below.
3700When 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.
3701
3702In 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).
3703
3704
3705\subsection{Modules}
3706
3707A 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.
3708These modules can then be easily shared and reused in multiple projects.
3709As modules are intended to be distributed for reuse, they should generally have stable, well-defined interfaces.
3710
3711\CFA adds the following keywords to express the module systems: module, export, import, as.
3712
3713
3714\subsubsection{Module Declaration}
3715
3716The syntax to declare a module is module moduleName;.
3717
3718The module declaration must be at the beginning of a file, and each file can only belong to one module.
3719If there is no module declaration at the beginning of a file, the file belongs to the global module.
3720A module can span several files.
3721By convention, a module and the files belonging to the module have additional mapping relationship which is described in the Do-Lang Tooling documentation.
3722
3723The moduleName follows the same rules of a variable name, except that it can use slash "/" to indicate the module/sub-module relationship.
3724For example, container/vector is a valid module name, where container is the parent module name, and vector is the sub-module under container.
3725
3726Only the interfaces of a module are visible from outside, when the module is imported. export is a type decorator to declare a module interface.
3727A method, a global variable or a type can be declared as a module interface.
3728Types defined in a module and referenced by an exported function or a variable must be exported, too.
3729
3730The following code is a simple module declaration example.
3731\begin{cfa}
3732module M;
3733
3734//visible outside module M
3735
3736export int f(int i) { return i + 1; }
3737export double aCounter;
3738
3739//not visible outside module M
3740
3741int g(int i) { return i - 1; }
3742
3743double bCounter;
3744\end{cfa}
3745
3746export module moduleName; can be use to re-export all the visible (exported) names in moduleName from the current module.
3747
3748
3749\subsubsection{Module Import}
3750
3751The syntax to import a module is import moduleName; or import moduleName as anotherName;.
3752One package cannot be imported with both of the two types of syntax in one file.
3753A package imported in one file will only be visible in this file.
3754For example, two files, A and B belong to the same module.
3755If file A imports another module, M, the exported names in M are not visible in file B.
3756
3757All of the exported names are visible in the file that imports the module.
3758The exported names can be accessed within a namespace based on the module name in the first syntax (ex moduleName.foo).
3759If 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(...);).
3760The 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.
3761Conflicts in namespaces will be reported by the compiler.
3762The second method can be used to solve conflicting name problems.
3763The following code snippets show the two situations.
3764
3765\begin{cfa}
3766module util/counter;
3767export int f(int i) { return i+1; }
3768
3769import util/counter;
3770
3771int main() {
3772        return counter.f(200); // f() from the package counter
3773}
3774
3775import util/counter as ct;
3776int main() {
3777        return ct.f(200); // f() from the package counter
3778}
3779\end{cfa}
3780
3781
3782Additionally, 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.
3783
3784\begin{cfa}
3785module M1;
3786export int f(int i) { return i+1;} // visible outside
3787
3788int g(int i) { return i-1;} // not visible outside
3789
3790module M2;
3791int f(int i) { return i * 2; } // not visible outside
3792export int g(int g) { return i / 2; } // visible outside
3793
3794import M1 as .;
3795
3796import M2 as .;
3797
3798
3799int main() {
3800        return f(3) + g(4); //f() from M1 and g() from M2;
3801}
3802\end{cfa}
3803
3804
3805\subsubsection{Sub-Module and Module Aggregation}
3806
3807Several modules can be organized in a parent module and sub-modules relationship.
3808The sub-module names are based on hierarchical naming, and use slash, "/", to indicate the relationship.
3809For example, std/vector and std/io are sub-modules of module std.
3810The 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
3811not implicitly exported in the parent module.
3812
3813Aggregation is a mechanism to support components and simplified importing.
3814The mechanism is not based on naming but based on manual declaration.
3815For example, the following is the aggregated sequence module.
3816The export {...} is syntactic sugar for many lines of export module aModule;.
3817If an aggregated module is imported, all the included modules in the aggregation are imported.
3818
3819\begin{cfa}
3820module std/sequence;
3821
3822export {
3823        module std/vector;
3824        module std/list;
3825        module std/array;
3826        module std/deque;
3827        module std/forward_list;
3828        module std/queue;
3829        module std/stack;
3830};
3831\end{cfa}
3832
3833After importing the aggregated module, each individual name is still contained in the original name space.
3834For 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.
3835
3836
3837\subsubsection{Import from Repository}
3838
3839When 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).
3840The tools also support retrieving modules of a package from external repositories.
3841See Listing 40: Package directory structure
3842
3843
3844\subsubsection{Package Import}
3845
3846Because 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.
3847In 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;
3848or 2) Adding the package dependence into the current project's Do.prj.
3849More details about locating a module in a package are explained in the next section.
3850
3851
3852\subsubsection{Package Versioning}
3853
3854A package must have a version number.
3855The version number is a string.
3856For example "1.0", "1.a", "A1", and "1ec5fab753eb979d3886a491845b8ae152d58c8f" are all valid version numbers.
3857By convention, a package is stored in a directory named packageName-packageVersion.
3858For example, the util package with version 1.1 is stored in a directory named util-1.1.
3859
3860The project description file can optionally specify the version of the package used in the current project.
3861If 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.
3862The builder tool will record the specific package version used in the build in the project's "Do.lock" file to enable fully repeatable builds.
3863
3864
3865\subsection{Module and Package Organization}
3866
3867\CFA has two level of encapsulations, module and package.
3868This section explains the object model of modules, packages and other language concepts.
3869It also explains how programmers should organize their code, and the method used by the build tools to locate packages, and import modules for compilation.
3870
3871
3872\subsubsection{Object Model}
3873
3874There are several concepts in Do.
3875\begin{itemize}
3876\item
3877File: a \CFA source file
3878\item
3879Module: a container to organize a set of related types and methods; It has a module name, and several interfaces visible from outside
3880\item
3881Package: a container to organize modules for distribution; It has attributes like name, author,
3882version, dependences, etc.
3883\item
3884Project: a working set for a \CFA project; It has attributes like name, author, version, dependences, etc.
3885\end{itemize}
3886
3887The following rules summarize the object model of all the above concepts:
3888\begin{itemize}
3889\item
3890A module contains one or more files
3891\begin{itemize}
3892\item
3893One file can only belong to one module
3894\item
3895A module has its name and interfaces exported
3896\item
3897A file without a module declaration at the beginning belongs to the global module
3898\item
3899\end{itemize}
3900
3901\item
3902A package contains one or more modules
3903\begin{itemize}
3904\item
3905A package has additional meta info described in Do.prj file
3906\item
3907A package may be dependent on other packages.
3908\end{itemize}
3909
3910\item
3911A project contains one or more modules in its source code
3912\begin{itemize}
3913\item
3914A project has additional meta info described in Do.prj file
3915\item
3916A project may be dependent on other packages
3917\item
3918A project can be transformed into a package for distribution
3919\item
3920A project can generate one or more executable binaries
3921\end{itemize}
3922\end{itemize}
3923
3924
3925\subsubsection{Module File Organization}
3926
3927The rules of this section are the conventions to organize module files in one package.
3928
3929The file location of a module in a package must match the module/submodule naming hierarchy.
3930The names separated by slash "/" must match the directory levels.
3931If only one file is used to implement one module, there is no need to put the module implementation file inside a sub-directory.
3932The file can be put inside its parent module's sub-directory with the sub module's name as the file name.
3933
3934Here is an example of a package, util.
3935\begin{cfa}
3936+ util
3937Do.prj #package description file
3938        heap.do #Case 1: module heap;
3939        list.do #Case 1: mdoule list;
3940        ring.do #Case 1: module ring;
3941        + string #Case 2
3942        impl1.do #module string;
3943        + std
3944        vector.do
3945        list.do
3946        + array #Case 3
3947        array1.do #module std/array;
3948        array2.do #module std/array;
3949        sequence.do #Case 4, module std/sequence;
3950        test.do #Case 5
3951\end{cfa}
3952
3953\begin{itemize}
3954\item
3955Case 1: Each individual file implements a module
3956\item
3957Case 2: Put the implementation of a module under the sub-directory, but there is only one file
3958\item
3959Case 3: Put the implementation of a module under the sub-directory; There are several files to
3960implement one module
3961\item
3962Case 4: One file to express one aggregation
3963\item
3964Case 5: The file does not belong to any module; It is used for testing purpose
3965\end{itemize}
3966
3967The example only uses source code, ".do" files, to show the module file organization.
3968Other module packaging formats, like binary, must also follow the same rules.
3969
3970
3971\subsection{Module File Format}
3972
3973\CFA supports different types of module file formats.
3974
3975\begin{itemize}
3976\item
3977Pure source code format: The files should be organized following the previous section's definition.
3978\item
3979IR format (TBD): The \CFA compiler IR format, similar to the source code format
3980\item
3981Binary format, including ".a" static library or ".so" dynamic linkage library
3982\begin{itemize}
3983\item
3984The file's name must match the right level's module name defined in the previous section
3985\item
3986E.g. "util.so" includes all modules for the package util.
3987\item
3988E.g. "string.so" under the package directory to include files belonging to "module string;"
3989\end{itemize}
3990\item.
3991Archive format
3992\begin{itemize}
3993\item
3994The archive is named as ".dar", and is a zip archive of the source code or the binary for a package
3995\item
3996E.g. "util.dar" is the whole package for util package including the package direction file
3997\end{itemize}
3998\item
3999Hybrid format
4000\begin{itemize}
4001\item
4002A package can be distributed partly in source code, partly in binary format, and/or packaged in the archive format
4003\item
4004The only limitation is that the names of the files must match the module location names defined in previous section
4005\end{itemize}
4006\end{itemize}
4007Package and Module Locating and the \CFA Language Tooling documentation for more details.
4008
4009
4010\subsection{Packages}
4011
4012A package is synonymous with a library in other languages.
4013The intent of the package level encapsulation is to facilitate code distribution, version control, and dependence management.
4014A package is a physical grouping of one or more modules in a directory (an archive file for a directory).
4015The 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.
4016
4017
4018\subsubsection{Package Definition}
4019
4020A package is defined by putting a project description file, Do.prj, with one or more modules into a directory.
4021This project description file contains the package's meta data, including package name, author, version, dependences, etc.
4022It should be in the root of the package directory.
4023
4024The modules in the package could be either source code, or compiled binary format.
4025The location of the module files should follow the module name's path.
4026
4027Here is a simple example of the directory structure of a package, core.
4028It contains a module std and several sub-modules under std.
4029\begin{cfa}
4030+ core
4031        Do.prj
4032        + std
4033        + io
4034        file.do # module std/io/file;
4035        network.do #module std/io/network;
4036        + container
4037        vector.do #module std/container/vector;
4038        list.do #module std/container/list;
4039\end{cfa}
4040
4041
4042\subsubsection{Package Import}
4043
4044Because 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.
4045In 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.
4046More details about locating a module in a package are explained in the next section.
4047
4048
4049\subsubsection{Package Versioning}
4050
4051A package must have a version number.
4052The version number is a string.
4053For example "1.0", "1.a", "A1", and "1ec5fab753eb979d3886a491845b8ae152d58c8f" are all valid version numbers.
4054By convention, a package is stored in a directory named packageName-packageVersion.
4055For example, the util package with version 1.1 is stored in a directory named util-1.1.
4056
4057The project description file can optionally specify the version of the package used in the current project.
4058If 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.
4059The builder tool will record the specific package version used in the build in the project's "Do.lock" file to enable fully repeatable builds.
4060
4061
4062\subsection{Module and Package Organization}
4063
4064\CFA has two level of encapsulations, module and package.
4065This section explains the object model of modules, packages and other language concepts.
4066It also explains how programmers should organize their code, and the method used by the build tools to locate packages, and import modules for compilation.
4067
4068
4069\subsubsection{Object Model}
4070
4071There are several concepts in Do.
4072\begin{itemize}
4073\item
4074File: a \CFA source file
4075\item
4076Module: a container to organize a set of related types and methods; It has a module name, and several interfaces visible from outside
4077\item
4078Package: a container to organize modules for distribution; It has attributes like name, author, version, dependences, etc.
4079\item
4080Project: a working set for a \CFA project; It has attributes like name, author, version, dependences, etc.
4081\end{itemize}
4082
4083The following rules summarize the object model of all the above concepts:
4084\begin{itemize}
4085\item
4086A module contains one or more files
4087\begin{itemize}
4088\item
4089One file can only belong to one module
4090\item
4091A module has its name and interfaces exported
4092\item
4093A file without a module declaration at the beginning belongs to the global module
4094\end{itemize}
4095\item
4096A package contains one or more modules
4097\begin{itemize}
4098\item
4099A package has additional meta info described in Do.prj file
4100\item
4101A package may be dependent on other packages.
4102\end{itemize}
4103\item
4104A project contains one or more modules in its source code
4105\begin{itemize}
4106\item
4107A project has additional meta info described in Do.prj file
4108\item
4109A project may be dependent on other packages
4110\item
4111A project can be transformed into a package for distribution
4112\item
4113A project can generate one or more executable binaries
4114\end{itemize}
4115\end{itemize}
4116
4117
4118\subsubsection{Module File Organization}
4119
4120The rules of this section are the conventions to organize module files in one package.
4121
4122The file location of a module in a package must match the module/submodule naming hierarchy.
4123The names separated by slash "/" must match the directory levels.
4124If only one file is used to implement one module, there is no need to put the module implementation file inside a sub-directory.
4125The file can be put inside its parent module's sub-directory with the sub module's name as the file name.
4126
4127Here is an example of a package, util.
4128\begin{cfa}
4129+ util
4130        Do.prj #package description file
4131        heap.do #Case 1: module heap;
4132        list.do #Case 1: mdoule list;
4133        ring.do #Case 1: module ring;
4134        + string #Case 2
4135        impl1.do #module string;
4136        + std
4137        vector.do
4138        list.do
4139        + array #Case 3
4140        array1.do #module std/array;
4141        array2.do #module std/array;
4142        sequence.do #Case 4, module std/sequence;
4143        test.do #Case 5
4144\end{cfa}
4145
4146
4147\begin{itemize}
4148\item
4149Case 1: Each individual file implements a module
4150\item
4151Case 2: Put the implementation of a module under the sub-directory, but there is only one file
4152\item
4153Case 3: Put the implementation of a module under the sub-directory; There are several files to implement one module
4154\item
4155Case 4: One file to express one aggregation
4156\item
4157Case 5: The file does not belong to any module; It is used for testing purpose
4158\end{itemize}
4159
4160The example only uses source code, ".do" files, to show the module file organization.
4161Other module packaging formats, like binary, must also follow the same rules.
4162
4163
4164\subsubsection{Module File Format}
4165
4166\CFA supports different types of module file formats.
4167
4168\begin{itemize}
4169\item
4170Pure source code format: The files should be organized following the previous section's definition.
4171\item
4172IR format (TBD): The \CFA compiler IR format, similar to the source code format
4173\item
4174Binary format, including ".a" static library or ".so" dynamic linkage library
4175\begin{itemize}
4176\item
4177The file's name must match the right level's module name defined in the previous section
4178\item
4179E.g. "util.so" includes all modules for the package util.
4180\item
4181E.g. "string.so" under the package directory to include files belonging to "module string;"
4182\end{itemize}
4183\item
4184Archive format
4185\begin{itemize}
4186\item
4187The archive is named as ".dar", and is a zip archive of the source code or the binary for a package
4188\item
4189E.g. "util.dar" is the whole package for util package including the package direction file
4190\end{itemize}
4191\item
4192Hybrid format
4193\begin{itemize}
4194\item
4195A package can be distributed partly in source code, partly in binary format, and/or packaged in the archive format
4196\item
4197The only limitation is that the names of the files must match the module location names defined in previous section
4198\end{itemize}
4199\end{itemize}
4200
4201
4202\subsection{Package and Module Locating}
4203
4204The 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.
4205If a programmer prefers, one can directly call the compiler, docc to build the source files and create and link to static libraries.
4206
4207When a source file imports a module, the \CFA build tool and docc compiler will locate the module according to the following order:
4208
4209\begin{enumerate}
4210\item
4211This source file's directory tree, which is typically the project's src directory
4212\item
4213All of the dependent packages (in a directory or in an archive file) under the current \CFA project's pkg directory
4214\item
4215The dependent packages (in a directory or in an archive file) inside the paths defined in the DOPATH environment variable
4216\item
4217The dependent packages (in a directory or in an archive file) inside the global \CFA SDK installation's pkg directory
4218\item
4219If 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
4220\end{enumerate}
4221
4222The module found first in a package will shadow the modules with the same name in the later packages in the search sequence.
4223
4224
4225\subsubsection{Dependent Package}
4226
4227Dependent packages are those packages containing modules that the current project's source code will import from.
4228Dependent packages are defined implicitly or explicitly in one \CFA project.
4229All of the packages under the current project's pkg directory are implicitly dependent packages.
4230For others, the dependent packages must be defined in the project's Do.prj file.
4231
4232
4233\subsubsection{Package and Module Locating Example}
4234
4235\begin{cfa}
4236# A project's source code tree
4237
4238--------------------------------------
4239
4240+ testProject
4241        Do.prj
4242        + src
4243        main.do
4244        + pkg
4245        + security-1.1
4246        Do.prj
4247        security.do #module security
4248
4249--------------------------------------
4250
4251# Do.prj
4252
4253--------------------------------------
4254
4255[dependences]
4256std
4257util = "0.2"
4258
4259--------------------------------------
4260
4261# main.do
4262
4263---------------------------------------
4264
4265import security;
4266import std/vector;
4267import container;
4268
4269----------------------------------------
4270\end{cfa}
4271
4272
4273\begin{cfa}
4274# pkg directory's source code tree
4275
4276-----------------------------------------
4277
4278+ pkg
4279        + std-1.0
4280        Do.prj
4281        vector.do #module std/vector;
4282        queue.do #module std/queue;
4283        + std-1.1
4284        Do.prj
4285        vector.do #module std/vector;
4286        queue.do #module std/queue;
4287        list.do #module std/list;
4288        + util-0.1
4289        Do.prj
4290        container.do #module container;
4291        + security-1.0
4292        security.do #module security;
4293------------------------------------------
4294\end{cfa}
4295
4296
4297During the compiling of main.do file import security;
4298The security module appears in both the local security-1.1 package, and the global security-1.0 package.
4299According to the locating sequence, the local security module in security-1.1 will be used.
4300And because the security-1.1 package is under local's pkg directory.
4301No dependence description is required in the project Do.prj file.
4302
4303import std/vector;
4304
4305The 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.
4306
4307import container;
4308
4309The 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.
4310The builder tool then will try to retrieve it from the web and store it in the global pkg directory.
4311After that, the container module from the newly downloaded package will be used in the compilation.
4312\end{comment}
4313
4314
4315\section{Comparison with Other Languages}
4316
4317\CFA is one of many languages that attempts to improve upon C.
4318In developing \CFA, many other languages were consulted for ideas, constructs, and syntax.
4319Therefore, it is important to show how these languages each compare with Do.
4320In this section, \CFA is compared with what the writers of this document consider to be the closest competitors of Do: \Index*[C++]{\CC{}}, \Index*{Go}, \Index*{Rust}, and \Index*{D}.
4321
4322
4323\subsection[Comparing Key Features of CFA]{Comparing Key Features of \CFA}
4324
4325
4326{% local change to lstlising to reduce font size
4327
4328
4329\lstset{basicstyle=\linespread{0.9}\sf\relsize{-2}}
4330
4331
4332\subsubsection{Constructors and Destructors}
4333
4334\begin{flushleft}
4335\begin{tabular}{@{}l|l|l|l@{}}
4336\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
4337\hline
4338\begin{cfa}
4339struct Line {
4340        float lnth;
4341}
4342// default constructor
4343void ?{}( Line * l ) {
4344        l->lnth = 0.0;
4345        sout | "default" | endl;
4346}
4347
4348
4349// constructor with length
4350void ?{}( Line * l, float lnth ) {
4351        l->lnth = lnth;
4352        sout | "lnth" | l->lnth | endl;
4353
4354}
4355
4356// destructor
4357void ^?() {
4358        sout | "destroyed" | endl;
4359        l.lnth = 0.0;
4360}
4361
4362// usage
4363Line line1;
4364Line line2 = { 3.4 };
4365\end{cfa}
4366&
4367\begin{lstlisting}[language=C++]
4368class Line {
4369        float lnth;
4370
4371        // default constructor
4372        Line() {
4373                cout << "default" << endl;
4374                lnth = 0.0;
4375        }
4376
4377
4378        // constructor with lnth
4379        Line( float l ) {
4380                cout << "length " << length
4381                         << endl;
4382                length = l;
4383        }
4384
4385        // destructor
4386        ~Line() {
4387                cout << "destroyed" << endl;
4388                length = 0.0;
4389        }
4390}
4391// usage
4392Line line1;
4393Line line2( 3.4 );
4394\end{lstlisting}
4395&
4396\begin{lstlisting}[language=Golang]
4397type Line struct {
4398        length float32
4399}
4400// default constructor
4401func makeLine() Line {
4402        fmt.PrintLn( "default" )
4403        return Line{0.0}
4404}
4405
4406
4407// constructor with length
4408func makeLine( length float32 ) Line {
4409        fmt.Printf( "length %v", length )
4410
4411        return Line{length}
4412}
4413
4414// no destructor
4415
4416
4417
4418
4419
4420// usage
4421line1 := makeLine()
4422line2 := makeLine( 3.4 )
4423\end{lstlisting}
4424&
4425\begin{cfa}
4426struct Line {
4427        length: f32
4428}
4429// default constructor
4430impl Default for Line {
4431        fn default () -> Line {
4432                println!( "default" );
4433                Line{ length: 0.0 }
4434        }
4435}
4436// constructor with length
4437impl Line {
4438        fn make( len: f32 ) -> Line {
4439                println!( "length: {}", len );
4440                Line{ length: len }
4441        }
4442}
4443// destructor
4444impl Drop for Line {
4445        fn drop( &mut self ) {
4446                self.length = 0.0
4447        }
4448}
4449// usage
4450let line1:Line = Default::default();
4451Line line2( 3.4 );
4452\end{cfa}
4453\end{tabular}
4454\end{flushleft}
4455
4456
4457\subsubsection{Operator Overloading}
4458
4459\begin{flushleft}
4460\begin{tabular}{@{}l|l|l|l@{}}
4461\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
4462\hline
4463\begin{cfa}
4464struct Cpx {
4465        double re, im;
4466};
4467// overload addition operator
4468Cpx ?+?( Cpx l, const Cpx r ) {
4469        return (Cpx){l.re+l.im, l.im+r.im};
4470}
4471Cpx a, b, c;
4472c = a + b;
4473\end{cfa}
4474&
4475\begin{cfa}
4476struct Cpx {
4477        double re, im;
4478};
4479// overload addition operator
4480Cpx operator+( Cpx l, const Cpx r ) {
4481        return (Cpx){l.re+l.im, l.im+r.im};
4482}
4483Cpx a, b, c;
4484c = a + b;
4485\end{cfa}
4486&
4487\begin{cfa}
4488// no operator overloading
4489
4490
4491
4492
4493
4494
4495
4496\end{cfa}
4497&
4498\begin{cfa}
4499struct Cpx {
4500        re: f32,
4501        im: f32
4502}
4503// overload addition operator
4504impl Add for Cpx {
4505        type Output = Cpx
4506        fn add(self, r: Cpx) -> Cpx {
4507                let mut res = Cpx{re: 0.0, im: 0.0};
4508                res.re = self.re + r.re;
4509                res.im = self.im + r.im;
4510                return res
4511        }
4512}
4513let (a, b, mut c) = ...;
4514c = a + b
4515\end{cfa}
4516\end{tabular}
4517\end{flushleft}
4518
4519
4520\subsubsection{Calling C Functions}
4521
4522\begin{flushleft}
4523\begin{tabular}{@{}l|l|l@{}}
4524\multicolumn{1}{c|}{\textbf{\CFA/\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}   \\
4525\hline
4526\begin{cfa}[boxpos=t]
4527extern "C" {
4528#include <sys/types.h>
4529#include <sys/stat.h>
4530#include <unistd.h>
4531}
4532size_t fileSize( const char *path ) {
4533        struct stat s;
4534        stat(path, &s);
4535        return s.st_size;
4536}
4537\end{cfa}
4538&
4539\begin{cfa}[boxpos=t]
4540/*
4541#cgo
4542#include <sys/types.h>
4543#include <sys/stat.h>
4544#include <unistd.h>
4545*/
4546import "C"
4547import "unsafe"
4548
4549func fileSize(path string) C.size_t {
4550        var buf C.struct_stat
4551        c_string := C.CString(path)
4552        C.stat(p, &buf)
4553        C.free(unsafe.Pointer(c_string))
4554        return buf._st_size
4555}
4556\end{cfa}
4557&
4558\begin{cfa}[boxpos=t]
4559use libc::{c_int, size_t};
4560// translated from sys/stat.h
4561#[repr(C)]
4562struct stat_t {
4563        ...
4564        st_size: size_t,
4565        ...
4566}
4567#[link(name = "libc")]
4568extern {
4569        fn stat(path: *const u8,
4570        buf: *mut stat_t) -> c_int;
4571}
4572fn fileSize(path: *const u8) -> size_t
4573{
4574        unsafe {
4575                let mut buf: stat_t = uninit();
4576                stat(path, &mut buf);
4577                buf.st_size
4578        }
4579}
4580\end{cfa}
4581\end{tabular}
4582\end{flushleft}
4583
4584
4585\subsubsection{Generic Functions}
4586
4587\begin{flushleft}
4588\begin{tabular}{@{}l|l|l|l@{}}
4589\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
4590\hline
4591\begin{cfa}
4592generic(type T, type N |
4593        { int ?<?(N, N); })
4594T *maximize(N (*f)(const T&),
4595        int n, T *a) {
4596        T *bestX = NULL;
4597        N bestN;
4598        for (int i = 0; i < n; i++) {
4599        N curN = f(a[i]);
4600        if (bestX == NULL ||
4601        curN > bestN) {
4602        bestX = &a[i]; bestN = curN;
4603        }
4604        }
4605        return bestX;
4606}
4607
4608string *longest(int n, string *p)
4609{
4610        return maximize(length, n, p);
4611}
4612\end{cfa}
4613&
4614\begin{cfa}
4615template<typename T, typename F>
4616T *maximize(const F &f,
4617        int n, T *a) {
4618        typedef decltype(f(a[0])) N;
4619        T *bestX = NULL;
4620        N bestN;
4621        for (int i = 0; i < n; i++) {
4622        N curN = f(a[i]);
4623        if (bestX == NULL || curN > bestN)
4624        {
4625        bestX = &a[i]; bestN = curN;
4626        }
4627        }
4628        return bestX;
4629}
4630
4631string *longest(int n, string *p) {
4632        return maximize(
4633        [](const string &s) {
4634        return s.length();
4635        }, n, p);
4636}
4637\end{cfa}
4638&
4639\begin{cfa}
4640// Go does not support generics!
4641func maximize(
4642        gt func(interface{}, interface{}) bool,
4643        f func(interface{}) interface{},
4644        a []interface{}) interface{} {
4645        var bestX interface{} = nil
4646        var bestN interface{} = nil
4647        for _, x := range a {
4648        curN := f(x)
4649        if bestX == nil || gt(curN, bestN)
4650        {
4651        bestN = curN
4652        bestX = x
4653        }
4654        }
4655        return bestX
4656}
4657
4658func longest(
4659        a []interface{}) interface{} {
4660        return maximize(
4661        func(a, b interface{}) bool {
4662        return a.(int) > b.(int) },
4663        func(s interface{}) interface{} {
4664        return len(s.(string)) },
4665        a).(string)
4666}
4667\end{cfa}
4668&
4669\begin{cfa}
4670use std::cmp::Ordering;
4671
4672fn maximize<N: Ord + Copy, T, F:
4673Fn(&T) -> N>(f: F, a: &Vec<T>) ->
4674Option<&T> {
4675        let mut best_x: Option<&T> = None;
4676        let mut best_n: Option<N> = None;
4677        for x in a {
4678        let n = f(x);
4679        if (match best_n { None => true,
4680        Some(bn) =>
4681        n.cmp(&bn) == Ordering::Greater })
4682        {
4683        best_x = Some(x);
4684        best_n = Some(n);
4685        }
4686        }
4687        return best_x
4688}
4689
4690fn longest(a: &Vec<String>) ->
4691        Option<&String> {
4692        return
4693        maximize(|x: &String| x.len(), a)
4694}
4695\end{cfa}
4696\end{tabular}
4697\end{flushleft}
4698
4699
4700\begin{comment}
4701\subsubsection{Modules / Packages}
4702
4703\begin{cfa}
4704\CFA
4705\CC
4706
4707
4708module example/M;
4709
4710export int inc(int val) {
4711        return val + 1;
4712}
4713
4714
4715
4716
4717--------------------------------------
4718//Use the module in another file
4719import example/M;
4720int main() {
4721        print(M.inc(100));
4722        return 0;
4723}
4724// Using \CC17 module proposal
4725
4726module example.M;
4727
4728export {
4729        int inc(int val);
4730}
4731
4732int inc(inv val) {
4733        return val + 1;
4734}
4735--------------------------------------
4736// Use the module in another file
4737import example.M;
4738int main() {
4739        cout << inc(100) << endl;
4740        return 0;
4741}
4742
4743Go
4744Rust
4745package example/M;
4746
4747func Inc(val int32) int32 {
4748        // Capitalization indicates exported
4749        return val + 100
4750}
4751
4752
4753--------------------------------------
4754//Use the package in another file
4755package main
4756import .fmt.
4757import "example/M"
4758
4759func main() int32 {
4760        fmt.Printf(.%v., M.Inc(100))
4761}
4762pub mod example {
4763        pub mod M {
4764        pub inc(val i32) -> i32 {
4765        return val + 100;
4766        }
4767        }
4768}
4769
4770--------------------------------------
4771//Use the module in another file
4772use example::M;
4773
4774
4775
4776fn main() {
4777        println!(.{}., M::inc(100));
4778}
4779\end{cfa}
4780\end{comment}
4781
4782
4783\subsubsection{Parallel Tasks}
4784
4785\begin{flushleft}
4786\begin{tabular}{@{}l|l|l|l@{}}
4787\multicolumn{1}{c|}{\textbf{\CFA}}      & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}      \\
4788\hline
4789\begin{cfa}
4790task Nonzero {
4791        int *data;
4792        int start;
4793        int end;
4794        int* res;
4795};
4796
4797void ?{}(Nonzero &a, int d[], int s,
4798        int e, int* subres) {
4799        // constructor
4800        a.data = d;
4801        a.start = s;
4802        a.end = e;
4803        a.res = subres;
4804}
4805
4806// implicitly spawn thread here
4807void ?()(NonzeroCounter &a) {
4808        int i;
4809        int nonzero = 0;
4810        for (i=start; c<end; ++i) {
4811        if(a.data[i]!=0){ nonzero++;}
4812        }
4813        *a.res = nonzero;
4814}
4815
4816int main() {
4817        int sz = ...
4818        int data[sz] = ...;
4819        int r1 = 0, r2=0;
4820        int res;
4821        { // create a scope for Nonzero
4822        Nonzero n1{data, 0, sz/2, &n1};
4823        Nonzero n2{data, sz/2, sz, &n2};
4824        n1();//spawn
4825        n2();//spawn
4826        }
4827        res = r1+r2;
4828        return res;
4829}
4830\end{cfa}
4831&
4832\begin{cfa}
4833#include <thread>
4834#include <mutex>
4835
4836std::mutex m;
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849void task(const vector<int>&v,
4850        int* res, size_t s,
4851        size_t e) {
4852        int non_zero = 0;
4853        for(size_t i = s; i < e; ++i){
4854        if(v[i]!=0) { non_zero++;}
4855        }
4856        std::unique_lock<mutex> lck {m};
4857        *res += non_zero;
4858}
4859
4860int main() {
4861        vector<int> data = ...; //data
4862        int res = 0;
4863        std::thread t1 {task, ref(data),
4864        &res, 0,
4865        data.size()/2};
4866        std::thread t2 {task, ref(data),
4867        &res, data.size()/2,
4868        data.size()};
4869        t1.join();
4870        t2.join();
4871        return res;
4872}
4873\end{cfa}
4874&
4875\begin{cfa}
4876package main
4877
4878import "fmt"
4879
4880func nonzero(data []int, c chan int) {
4881        nz := 0
4882        for _, v:=range data {
4883        if(v!=0) { nz := nz+1 }
4884        }
4885        c <- nz
4886}
4887
4888func main() {
4889        sz := ...
4890        data := make([]int, sz)
4891        ... // data init
4892        go nonzero(data[:len(data)/2], c)
4893        go nonzero(data[len(data)/2:], c)
4894        n1, n2 := <-c, <-c
4895        res := n1 + n2
4896        fmt.Println(res)
4897}
4898\end{cfa}
4899&
4900\begin{cfa}
4901use std::thread;
4902use std::sync:mpsc::channel;
4903
4904fn main() {
4905        let sz = ...;
4906        let mut data:Vec<i32> =
4907        Vec::with_capacity(sz as usize);
4908        ... //init data
4909        let (tx, rx) = channel();
4910        for i in 0..1 {
4911        let tx = tx.clone();
4912        let data = data.clone()
4913        thread::spawn(move|| {
4914        let mut nz := 0;
4915        let mut s = 0;
4916        let mut e = sz / 2;
4917        if i == 1 {
4918        s = sz/2;
4919        e = data.len();
4920        }
4921        for i in s..(e - 1) {
4922        if data[i] != 0 (
4923        nz = nz + 1
4924        }
4925        }
4926        tx.send(nz).unwrap();
4927        });
4928        }
4929        let res = rx.recv().unwrap() +
4930        rx.recv().unwrap();
4931        println!(.{}., res);
4932}
4933\end{cfa}
4934\end{tabular}
4935\end{flushleft}
4936
4937}% local change to lstlising to reduce font size
4938
4939
4940\subsection{Summary of Language Comparison}
4941
4942
4943\subsubsection[C++]{\CC}
4944
4945\Index*[C++]{\CC{}} is a general-purpose programming language.
4946It has imperative, object-oriented and generic programming features, while also providing facilities for low-level memory manipulation. (Wikipedia)
4947
4948The primary focus of \CC seems to be adding object-oriented programming to C, and this is the primary difference between \CC and Do.
4949\CC uses classes to encapsulate data and the functions that operate on that data, and to hide the internal representation of the data.
4950\CFA uses modules instead to perform these same tasks.
4951Classes in \CC also enable inheritance among types.
4952Instead of inheritance, \CFA embraces composition and interfaces to achieve the same goals with more flexibility.
4953There 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, \Index*{Go} at Google: Language Design in the Service of Software Engineering , 2012).
4954
4955Overloading 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.
4956References and exceptions in \CFA are heavily based on the same features from \CC.
4957The mechanism for interoperating with C code in \CFA is also borrowed from \CC.
4958
4959Both \CFA and \CC provide generics, and the syntax is quite similar.
4960The 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.
4961This means that a generic function can be defined in a compiled library, and still be used as expected from source.
4962
4963
4964\subsubsection{Go}
4965
4966\Index*{Go}, also commonly referred to as golang, is a programming language developed at Google in 2007 [.].
4967It is a statically typed language with syntax loosely derived from that of C, adding garbage collection, type
4968safety, some structural typing capabilities, additional built-in types such as variable-length arrays and key-value maps, and a large standard library. (Wikipedia)
4969
4970Go and \CFA differ significantly in syntax and implementation, but the underlying core concepts of the two languages are aligned.
4971Both Go and \CFA use composition and interfaces as opposed to inheritance to enable encapsulation and abstraction.
4972Both languages (along with their tooling ecosystem) provide a simple packaging mechanism for building units of code for easy sharing and reuse.
4973Both 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.
4974
4975Go has a significant runtime which handles the scheduling of its light weight threads, and performs garbage collection, among other tasks.
4976\CFA uses a cooperative scheduling algorithm for its tasks, and uses automatic reference counting to enable advanced memory management without garbage collection.
4977This results in Go requiring significant overhead to interface with C libraries while \CFA has no overhead.
4978
4979
4980\subsubsection{Rust}
4981
4982\Index*{Rust} is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.
4983It is designed to be a "safe, concurrent, practical language", supporting pure-functional, concurrent-actor[dubious . discuss][citation needed], imperative-procedural, and object-oriented styles.
4984
4985The primary focus of Rust is in safety, especially in concurrent programs.
4986To enforce a high level of safety, Rust has added ownership as a core feature of the language to guarantee memory safety.
4987This safety comes at the cost of a difficult learning curve, a change in the thought model of the program, and often some runtime overhead.
4988
4989Aside from those key differences, Rust and \CFA also have several similarities.
4990Both languages support no overhead interoperability with C and have minimal runtimes.
4991Both languages support inheritance and polymorphism through the use of interfaces (traits).
4992
4993
4994\subsubsection{D}
4995
4996The \Index*{D} programming language is an object-oriented, imperative, multi-paradigm system programming
4997language created by Walter Bright of Digital Mars and released in 2001. [.]
4998Though 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 \Index*{Java}, \Index*{Python}, Ruby, C\#, and Eiffel.
4999
5000D and \CFA both start with C and add productivity features.
5001The obvious difference is that D uses classes and inheritance while \CFA uses composition and interfaces.
5002D is closer to \CFA than \CC since it is limited to single inheritance and also supports interfaces.
5003Like \CC, and unlike \CFA, D uses garbage collection and has compile-time expanded templates.
5004D does not have any built-in concurrency constructs in the
5005language, though it does have a standard library for concurrency which includes the low-level primitives for concurrency.
5006
5007
5008\appendix
5009
5010
5011\section{Syntax Ambiguities}
5012
5013C has a number of syntax ambiguities, which are resolved by taking the longest sequence of overlapping characters that constitute a token.
5014For example, the program fragment ©x+++++y© is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens ©++© and ©+© overlap.
5015Unfortunately, the longest sequence violates a constraint on increment operators, even though the parse \lstinline[showspaces=true]@x ++ + ++ y@ might yield a correct expression.
5016Hence, C programmers are aware that spaces have to added to disambiguate certain syntactic cases.
5017
5018In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be interpreted as:
5019\begin{cfa}
5020*?§\color{red}\textvisiblespace§*?              §\C{// dereference operator, dereference operator}§
5021\color{red}\textvisiblespace§?*?              §\C{// dereference, multiplication operator}§
5022\end{cfa}
5023By default, the first interpretation is selected, which does not yield a meaningful parse.
5024Therefore, \CFA does a lexical look-ahead for the second case, and backtracks to return the leading unary operator and reparses the trailing operator identifier.
5025Otherwise a space is needed between the unary operator and operator identifier to disambiguate this common case.
5026
5027A similar issue occurs with the dereference, ©*?(...)©, and routine-call, ©?()(...)© identifiers.
5028The ambiguity occurs when the deference operator has no parameters:
5029\begin{cfa}
5030*?()§\color{red}\textvisiblespace...§ ;
5031*?()§\color{red}\textvisiblespace...§(...) ;
5032\end{cfa}
5033requiring arbitrary whitespace look-ahead for the routine-call parameter-list to disambiguate.
5034However, the dereference operator \emph{must} have a parameter/argument to dereference ©*?(...)©.
5035Hence, always interpreting the string ©*?()© as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program.
5036
5037The remaining cases are with the increment/decrement operators and conditional expression, \eg:
5038\begin{cfa}
5039i++?§\color{red}\textvisiblespace...§(...);
5040i?++§\color{red}\textvisiblespace...§(...);
5041\end{cfa}
5042requiring arbitrary whitespace look-ahead for the operator parameter-list, even though that interpretation is an incorrect expression (juxtaposed identifiers).
5043Therefore, it is necessary to disambiguate these cases with a space:
5044\begin{cfa}
5045i++§\color{red}\textvisiblespace§? i : 0;
5046i?§\color{red}\textvisiblespace§++i : 0;
5047\end{cfa}
5048
5049
5050\section{\protect\CFA Keywords}
5051\label{s:CFAKeywords}
5052
5053\begin{quote2}
5054\begin{tabular}{llll}
5055\begin{tabular}{@{}l@{}}
5056©_AT©                   \\
5057©catch©                 \\
5058©catchResume©   \\
5059©choose©                \\
5060©coroutine©             \\
5061©disable©               \\
5062\end{tabular}
5063&
5064\begin{tabular}{@{}l@{}}
5065©dtype©                 \\
5066©enable©                \\
5067©fallthrough©   \\
5068©fallthru©              \\
5069©finally©               \\
5070©forall©                \\
5071\end{tabular}
5072&
5073\begin{tabular}{@{}l@{}}
5074©ftype©                 \\
5075©lvalue©                \\
5076©monitor©               \\
5077©mutex©                 \\
5078©one_t©                 \\
5079©otype©                 \\
5080\end{tabular}
5081&
5082\begin{tabular}{@{}l@{}}
5083©throw©                 \\
5084©throwResume©   \\
5085©trait©                 \\
5086©try©                   \\
5087©ttype©                 \\
5088©zero_t©                \\
5089\end{tabular}
5090\end{tabular}
5091\end{quote2}
5092
5093
5094\section{Incompatible}
5095
5096The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}.
5097
5098
5099\begin{enumerate}
5100\item
5101\begin{description}
5102\item[Change:] add new keywords \\
5103New keywords are added to \CFA (see~\VRef{s:CFAKeywords}).
5104\item[Rationale:] keywords added to implement new semantics of \CFA.
5105\item[Effect on original feature:] change to semantics of well-defined feature. \\
5106Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
5107\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}).
5108\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
5109\end{description}
5110
5111\item
5112\begin{description}
5113\item[Change:] drop K\&R C declarations \\
5114K\&R declarations allow an implicit base-type of ©int©, if no type is specified, plus an alternate syntax for declaring parameters.
5115\eg:
5116\begin{cfa}
5117x;                                                              §\C{// int x}§
5118*y;                                                             §\C{// int *y}§
5119f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
5120g( p1, p2 ) int p1, p2;                 §\C{// int g( int p1, int p2 );}§
5121\end{cfa}
5122\CFA supports K\&R routine definitions:
5123\begin{cfa}
5124f( a, b, c )                                    §\C{// default int return}§
5125        int a, b; char c                        §\C{// K\&R parameter declarations}§
5126{
5127        ...
5128}
5129\end{cfa}
5130\item[Rationale:] dropped from \Celeven standard.\footnote{
5131At 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}}
5132\item[Effect on original feature:] original feature is deprecated. \\
5133Any old C programs using these K\&R declarations are invalid \CFA programs.
5134\item[Difficulty of converting:] trivial to convert to \CFA.
5135\item[How widely used:] existing usages are rare.
5136\end{description}
5137
5138\item
5139\begin{description}
5140\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
5141\begin{cfa}
5142int rtn( int i );
5143int rtn( char c );
5144rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
5145\end{cfa}
5146\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
5147In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
5148\begin{cfa}
5149sout | 'x' | " " | (int)'x' | endl;
5150x 120
5151\end{cfa}
5152Having to cast ©'x'© to ©char© is non-intuitive.
5153\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
5154\begin{cfa}
5155sizeof( 'x' ) == sizeof( int )
5156\end{cfa}
5157no long work the same in \CFA programs.
5158\item[Difficulty of converting:] simple
5159\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
5160\end{description}
5161
5162\item
5163\begin{description}
5164\item[Change:] make string literals ©const©:
5165\begin{cfa}
5166char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
5167char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
5168\end{cfa}
5169The type of a string literal is changed from ©[] char© to ©const [] char©.
5170Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
5171\item[Rationale:] This change is a safety issue:
5172\begin{cfa}
5173char * p = "abc";
5174p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
5175\end{cfa}
5176The same problem occurs when passing a string literal to a routine that changes its argument.
5177\item[Effect on original feature:] change to semantics of well-defined feature.
5178\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
5179\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
5180\end{description}
5181
5182\item
5183\begin{description}
5184\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
5185\begin{cfa}
5186int i;                                                  §\C{// forward definition}§
5187int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
5188int i = 0;                                              §\C{// definition}§
5189\end{cfa}
5190is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
5191This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
5192\begin{cfa}
5193struct X { int i; struct X *next; };
5194static struct X a;                              §\C{// forward definition}§
5195static struct X b = { 0, ®&};        §\C{// forward reference, valid in C, invalid in \CFA}§
5196static struct X a = { 1, &b };  §\C{// definition}§
5197\end{cfa}
5198\item[Rationale:] avoids having different initialization rules for builtin types and user-defined types.
5199\item[Effect on original feature:] change to semantics of well-defined feature.
5200\item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization.
5201\item[How widely used:] seldom
5202\end{description}
5203
5204\item
5205\begin{description}
5206\item[Change:] have ©struct© introduce a scope for nested types:
5207\begin{cfa}
5208enum ®Colour® { R, G, B, Y, C, M };
5209struct Person {
5210        enum ®Colour® { R, G, B };      §\C{// nested type}§
5211        struct Face {                           §\C{// nested type}§
5212                ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
5213        };
5214        ®.Colour® shirt;                        §\C{// type defined outside (top level)}§
5215        ®Colour® pants;                         §\C{// type defined same level}§
5216        Face looks[10];                         §\C{// type defined same level}§
5217};
5218®Colour® c = R;                                 §\C{// type/enum defined same level}§
5219Person®.Colour® pc = Person®.®R;        §\C{// type/enum defined inside}§
5220Person®.®Face pretty;                   §\C{// type defined inside}§
5221\end{cfa}
5222In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
5223\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC{}}.
5224Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
5225\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
5226\item[Effect on original feature:] change to semantics of well-defined feature.
5227\item[Difficulty of converting:] Semantic transformation.
5228\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
5229\end{description}
5230
5231\item
5232\begin{description}
5233\item[Change:] In C++, the name of a nested class is local to its enclosing class.
5234\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
5235\item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
5236\begin{cfa}
5237struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
5238struct X {
5239        struct Y { /* ... */ } y;
5240};
5241\end{cfa}
5242All 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.
5243Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
5244\item[How widely used:] Seldom.
5245\end{description}
5246
5247\item
5248\begin{description}
5249\item[Change:] comma expression is disallowed as subscript
5250\item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays.
5251\item[Effect on original feature:] change to semantics of well-defined feature.
5252\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
5253\item[How widely used:] seldom.
5254\end{description}
5255\end{enumerate}
5256
5257
5258\section{Standard Headers}
5259\label{s:StandardHeaders}
5260
5261\Celeven prescribes the following standard header-files~\cite[\S~7.1.2]{C11} and \CFA adds to this list:
5262\begin{quote2}
5263\lstset{deletekeywords={float}}
5264\begin{tabular}{@{}llll|l@{}}
5265\multicolumn{4}{c|}{C11} & \multicolumn{1}{c}{\CFA}             \\
5266\hline
5267\begin{tabular}{@{}l@{}}
5268\Indexc{assert.h}               \\
5269\Indexc{complex.h}              \\
5270\Indexc{ctype.h}                \\
5271\Indexc{errno.h}                \\
5272\Indexc{fenv.h}                 \\
5273\Indexc{float.h}                \\
5274\Indexc{inttypes.h}             \\
5275\Indexc{iso646.h}               \\
5276\end{tabular}
5277&
5278\begin{tabular}{@{}l@{}}
5279\Indexc{limits.h}               \\
5280\Indexc{locale.h}               \\
5281\Indexc{math.h}                 \\
5282\Indexc{setjmp.h}               \\
5283\Indexc{signal.h}               \\
5284\Indexc{stdalign.h}             \\
5285\Indexc{stdarg.h}               \\
5286\Indexc{stdatomic.h}    \\
5287\end{tabular}
5288&
5289\begin{tabular}{@{}l@{}}
5290\Indexc{stdbool.h}              \\
5291\Indexc{stddef.h}               \\
5292\Indexc{stdint.h}               \\
5293\Indexc{stdio.h}                \\
5294\Indexc{stdlib.h}               \\
5295\Indexc{stdnoreturn.h}  \\
5296\Indexc{string.h}               \\
5297\Indexc{tgmath.h}               \\
5298\end{tabular}
5299&
5300\begin{tabular}{@{}l@{}}
5301\Indexc{threads.h}              \\
5302\Indexc{time.h}                 \\
5303\Indexc{uchar.h}                \\
5304\Indexc{wchar.h}                \\
5305\Indexc{wctype.h}               \\
5306                                                \\
5307                                                \\
5308                                                \\
5309\end{tabular}
5310&
5311\begin{tabular}{@{}l@{}}
5312\Indexc{unistd.h}               \\
5313\Indexc{gmp.h}                  \\
5314                                                \\
5315                                                \\
5316                                                \\
5317                                                \\
5318                                                \\
5319                                                \\
5320\end{tabular}
5321\end{tabular}
5322\end{quote2}
5323For the prescribed head-files, \CFA uses header interposition to wraps these includes in an ©extern "C"©;
5324hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
5325All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
5326For \Index*[C++]{\CC{}}, the name-mangling issue is handled implicitly because most C header-files are augmented with checks for preprocessor variable ©__cplusplus©, which adds appropriate ©extern "C"© qualifiers.
5327
5328
5329\section{Standard Library}
5330\label{s:StandardLibrary}
5331
5332The \CFA standard-library wraps explicitly-polymorphic C routines into implicitly-polymorphic versions.
5333
5334
5335\subsection{Storage Management}
5336
5337The storage-management routines extend their C equivalents by overloading, alternate names, providing shallow type-safety, and removing the need to specify the allocation size for non-array types.
5338
5339Storage management provides the following capabilities:
5340\begin{description}
5341\item[fill]
5342after allocation the storage is filled with a specified character.
5343\item[resize]
5344an existing allocation is decreased or increased in size.
5345In either case, new storage may or may not be allocated and, if there is a new allocation, as much data from the existing allocation is copied.
5346For an increase in storage size, new storage after the copied data may be filled.
5347\item[alignment]
5348an allocation starts on a specified memory boundary, e.g., an address multiple of 64 or 128 for cache-line purposes.
5349\item[array]
5350the allocation size is scaled to the specified number of array elements.
5351An array may be filled, resized, or aligned.
5352\end{description}
5353The table shows allocation routines supporting different combinations of storage-management capabilities:
5354\begin{center}
5355\begin{tabular}{@{}lr|l|l|l|l@{}}
5356                &                                       & \multicolumn{1}{c|}{fill}     & resize        & alignment     & array \\
5357\hline
5358C               & ©malloc©                      & no                    & no            & no            & no    \\
5359                & ©calloc©                      & yes (0 only)  & no            & no            & yes   \\
5360                & ©realloc©                     & no/copy               & yes           & no            & no    \\
5361                & ©memalign©            & no                    & no            & yes           & no    \\
5362                & ©posix_memalign©      & no                    & no            & yes           & no    \\
5363C11             & ©aligned_alloc©       & no                    & no            & yes           & no    \\
5364\CFA    & ©alloc©                       & no/copy/yes   & no/yes        & no            & yes   \\
5365                & ©align_alloc©         & no/yes                & no            & yes           & yes   \\
5366\end{tabular}
5367\end{center}
5368It is impossible to resize with alignment because the underlying ©realloc© allocates storage if more space is needed, and it does not honour alignment from the original allocation.
5369
5370\leavevmode
5371\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5372// C unsafe allocation
5373extern "C" {
5374void * mallac( size_t size );§\indexc{memset}§
5375void * calloc( size_t dim, size_t size );§\indexc{calloc}§
5376void * realloc( void * ptr, size_t size );§\indexc{realloc}§
5377void * memalign( size_t align, size_t size );§\indexc{memalign}§
5378int posix_memalign( void ** ptr, size_t align, size_t size );§\indexc{posix_memalign}§
5379}
5380
5381// §\CFA§ safe equivalents, i.e., implicit size specification
5382forall( dtype T | sized(T) ) T * malloc( void );
5383forall( dtype T | sized(T) ) T * calloc( size_t dim );
5384forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size );
5385forall( dtype T | sized(T) ) T * memalign( size_t align );
5386forall( dtype T | sized(T) ) T * aligned_alloc( size_t align );
5387forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t align );
5388
5389// §\CFA§ safe general allocation, fill, resize, array
5390forall( dtype T | sized(T) ) T * alloc( void );§\indexc{alloc}§
5391forall( dtype T | sized(T) ) T * alloc( char fill );
5392forall( dtype T | sized(T) ) T * alloc( size_t dim );
5393forall( dtype T | sized(T) ) T * alloc( size_t dim, char fill );
5394forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim );
5395forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim, char fill );
5396
5397// §\CFA§ safe general allocation, align, fill, array
5398forall( dtype T | sized(T) ) T * align_alloc( size_t align );
5399forall( dtype T | sized(T) ) T * align_alloc( size_t align, char fill );
5400forall( dtype T | sized(T) ) T * align_alloc( size_t align, size_t dim );
5401forall( dtype T | sized(T) ) T * align_alloc( size_t align, size_t dim, char fill );
5402
5403// C unsafe initialization/copy
5404extern "C" {
5405void * memset( void * dest, int c, size_t size );
5406void * memcpy( void * dest, const void * src, size_t size );
5407}
5408
5409// §\CFA§ safe initialization/copy, i.e., implicit size specification
5410forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
5411forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
5412
5413// §\CFA§ safe initialization/copy array
5414forall( dtype T | sized(T) ) T * memset( T dest[], size_t dim, char c );
5415forall( dtype T | sized(T) ) T * memcpy( T dest[], const T src[], size_t dim );
5416
5417// §\CFA§ allocation/deallocation and constructor/destructor
5418forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * new( Params p );§\indexc{new}§
5419forall( dtype T | { void ^?{}( T * ); } ) void delete( T * ptr );§\indexc{delete}§
5420forall( dtype T, ttype Params | { void ^?{}( T * ); void delete( Params ); } )
5421  void delete( T * ptr, Params rest );
5422
5423// §\CFA§ allocation/deallocation and constructor/destructor, array
5424forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * anew( size_t dim, Params p );§\indexc{anew}§
5425forall( dtype T | sized(T) | { void ^?{}( T * ); } ) void adelete( size_t dim, T arr[] );§\indexc{adelete}§
5426forall( dtype T | sized(T) | { void ^?{}( T * ); }, ttype Params | { void adelete( Params ); } )
5427  void adelete( size_t dim, T arr[], Params rest );
5428\end{cfa}
5429
5430
5431\subsection{Conversion}
5432
5433\leavevmode
5434\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5435int ato( const char * ptr );§\indexc{ato}§
5436unsigned int ato( const char * ptr );
5437long int ato( const char * ptr );
5438unsigned long int ato( const char * ptr );
5439long long int ato( const char * ptr );
5440unsigned long long int ato( const char * ptr );
5441float ato( const char * ptr );
5442double ato( const char * ptr );
5443long double ato( const char * ptr );
5444float _Complex ato( const char * ptr );
5445double _Complex ato( const char * ptr );
5446long double _Complex ato( const char * ptr );
5447
5448int strto( const char * sptr, char ** eptr, int base );
5449unsigned int strto( const char * sptr, char ** eptr, int base );
5450long int strto( const char * sptr, char ** eptr, int base );
5451unsigned long int strto( const char * sptr, char ** eptr, int base );
5452long long int strto( const char * sptr, char ** eptr, int base );
5453unsigned long long int strto( const char * sptr, char ** eptr, int base );
5454float strto( const char * sptr, char ** eptr );
5455double strto( const char * sptr, char ** eptr );
5456long double strto( const char * sptr, char ** eptr );
5457float _Complex strto( const char * sptr, char ** eptr );
5458double _Complex strto( const char * sptr, char ** eptr );
5459long double _Complex strto( const char * sptr, char ** eptr );
5460\end{cfa}
5461
5462
5463\subsection{Search / Sort}
5464
5465\leavevmode
5466\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5467forall( otype T | { int ?<?( T, T ); } )        §\C{// location}§
5468T * bsearch( T key, const T * arr, size_t dim );§\indexc{bsearch}§
5469
5470forall( otype T | { int ?<?( T, T ); } )        §\C{// position}§
5471unsigned int bsearch( T key, const T * arr, size_t dim );
5472
5473forall( otype T | { int ?<?( T, T ); } )
5474void qsort( const T * arr, size_t dim );§\indexc{qsort}§
5475\end{cfa}
5476
5477
5478\subsection{Absolute Value}
5479
5480\leavevmode
5481\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5482unsigned char abs( signed char );§\indexc{abs}§
5483int abs( int );
5484unsigned long int abs( long int );
5485unsigned long long int abs( long long int );
5486float abs( float );
5487double abs( double );
5488long double abs( long double );
5489float abs( float _Complex );
5490double abs( double _Complex );
5491long double abs( long double _Complex );
5492forall( otype T | { void ?{}( T *, zero_t ); int ?<?( T, T ); T -?( T ); } )
5493T abs( T );
5494\end{cfa}
5495
5496
5497\subsection{Random Numbers}
5498
5499\leavevmode
5500\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5501void rand48seed( long int s );§\indexc{rand48seed}§
5502char rand48();§\indexc{rand48}§
5503int rand48();
5504unsigned int rand48();
5505long int rand48();
5506unsigned long int rand48();
5507float rand48();
5508double rand48();
5509float _Complex rand48();
5510double _Complex rand48();
5511long double _Complex rand48();
5512\end{cfa}
5513
5514
5515\subsection{Algorithms}
5516
5517\leavevmode
5518\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5519forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
5520forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
5521forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
5522forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
5523\end{cfa}
5524
5525
5526\section{Math Library}
5527\label{s:Math Library}
5528
5529The \CFA math-library wraps explicitly-polymorphic C math-routines into implicitly-polymorphic versions.
5530
5531
5532\subsection{General}
5533
5534\leavevmode
5535\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5536float ?%?( float, float );§\indexc{fmod}§
5537float fmod( float, float );
5538double ?%?( double, double );
5539double fmod( double, double );
5540long double ?%?( long double, long double );
5541long double fmod( long double, long double );
5542
5543float remainder( float, float );§\indexc{remainder}§
5544double remainder( double, double );
5545long double remainder( long double, long double );
5546
5547[ int, float ] remquo( float, float );§\indexc{remquo}§
5548float remquo( float, float, int * );
5549[ int, double ] remquo( double, double );
5550double remquo( double, double, int * );
5551[ int, long double ] remquo( long double, long double );
5552long double remquo( long double, long double, int * );
5553
5554[ int, float ] div( float, float );                                             // alternative name for remquo
5555float div( float, float, int * );§\indexc{div}§
5556[ int, double ] div( double, double );
5557double div( double, double, int * );
5558[ int, long double ] div( long double, long double );
5559long double div( long double, long double, int * );
5560
5561float fma( float, float, float );§\indexc{fma}§
5562double fma( double, double, double );
5563long double fma( long double, long double, long double );
5564
5565float fdim( float, float );§\indexc{fdim}§
5566double fdim( double, double );
5567long double fdim( long double, long double );
5568
5569float nan( const char * );§\indexc{nan}§
5570double nan( const char * );
5571long double nan( const char * );
5572\end{cfa}
5573
5574
5575\subsection{Exponential}
5576
5577\leavevmode
5578\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5579float exp( float );§\indexc{exp}§
5580double exp( double );
5581long double exp( long double );
5582float _Complex exp( float _Complex );
5583double _Complex exp( double _Complex );
5584long double _Complex exp( long double _Complex );
5585
5586float exp2( float );§\indexc{exp2}§
5587double exp2( double );
5588long double exp2( long double );
5589float _Complex exp2( float _Complex );
5590double _Complex exp2( double _Complex );
5591long double _Complex exp2( long double _Complex );
5592
5593float expm1( float );§\indexc{expm1}§
5594double expm1( double );
5595long double expm1( long double );
5596
5597float log( float );§\indexc{log}§
5598double log( double );
5599long double log( long double );
5600float _Complex log( float _Complex );
5601double _Complex log( double _Complex );
5602long double _Complex log( long double _Complex );
5603
5604float log2( float );§\indexc{log2}§
5605double log2( double );
5606long double log2( long double );
5607float _Complex log2( float _Complex );
5608double _Complex log2( double _Complex );
5609long double _Complex log2( long double _Complex );
5610
5611float log10( float );§\indexc{log10}§
5612double log10( double );
5613long double log10( long double );
5614float _Complex log10( float _Complex );
5615double _Complex log10( double _Complex );
5616long double _Complex log10( long double _Complex );
5617
5618float log1p( float );§\indexc{log1p}§
5619double log1p( double );
5620long double log1p( long double );
5621
5622int ilogb( float );§\indexc{ilogb}§
5623int ilogb( double );
5624int ilogb( long double );
5625
5626float logb( float );§\indexc{logb}§
5627double logb( double );
5628long double logb( long double );
5629\end{cfa}
5630
5631
5632\subsection{Power}
5633
5634\leavevmode
5635\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5636float sqrt( float );§\indexc{sqrt}§
5637double sqrt( double );
5638long double sqrt( long double );
5639float _Complex sqrt( float _Complex );
5640double _Complex sqrt( double _Complex );
5641long double _Complex sqrt( long double _Complex );
5642
5643float cbrt( float );§\indexc{cbrt}§
5644double cbrt( double );
5645long double cbrt( long double );
5646
5647float hypot( float, float );§\indexc{hypot}§
5648double hypot( double, double );
5649long double hypot( long double, long double );
5650
5651float pow( float, float );§\indexc{pow}§
5652double pow( double, double );
5653long double pow( long double, long double );
5654float _Complex pow( float _Complex, float _Complex );
5655double _Complex pow( double _Complex, double _Complex );
5656long double _Complex pow( long double _Complex, long double _Complex );
5657\end{cfa}
5658
5659
5660\subsection{Trigonometric}
5661
5662\leavevmode
5663\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5664float sin( float );§\indexc{sin}§
5665double sin( double );
5666long double sin( long double );
5667float _Complex sin( float _Complex );
5668double _Complex sin( double _Complex );
5669long double _Complex sin( long double _Complex );
5670
5671float cos( float );§\indexc{cos}§
5672double cos( double );
5673long double cos( long double );
5674float _Complex cos( float _Complex );
5675double _Complex cos( double _Complex );
5676long double _Complex cos( long double _Complex );
5677
5678float tan( float );§\indexc{tan}§
5679double tan( double );
5680long double tan( long double );
5681float _Complex tan( float _Complex );
5682double _Complex tan( double _Complex );
5683long double _Complex tan( long double _Complex );
5684
5685float asin( float );§\indexc{asin}§
5686double asin( double );
5687long double asin( long double );
5688float _Complex asin( float _Complex );
5689double _Complex asin( double _Complex );
5690long double _Complex asin( long double _Complex );
5691
5692float acos( float );§\indexc{acos}§
5693double acos( double );
5694long double acos( long double );
5695float _Complex acos( float _Complex );
5696double _Complex acos( double _Complex );
5697long double _Complex acos( long double _Complex );
5698
5699float atan( float );§\indexc{atan}§
5700double atan( double );
5701long double atan( long double );
5702float _Complex atan( float _Complex );
5703double _Complex atan( double _Complex );
5704long double _Complex atan( long double _Complex );
5705
5706float atan2( float, float );§\indexc{atan2}§
5707double atan2( double, double );
5708long double atan2( long double, long double );
5709
5710float atan( float, float );                                                             // alternative name for atan2
5711double atan( double, double );§\indexc{atan}§
5712long double atan( long double, long double );
5713\end{cfa}
5714
5715
5716\subsection{Hyperbolic}
5717
5718\leavevmode
5719\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5720float sinh( float );§\indexc{sinh}§
5721double sinh( double );
5722long double sinh( long double );
5723float _Complex sinh( float _Complex );
5724double _Complex sinh( double _Complex );
5725long double _Complex sinh( long double _Complex );
5726
5727float cosh( float );§\indexc{cosh}§
5728double cosh( double );
5729long double cosh( long double );
5730float _Complex cosh( float _Complex );
5731double _Complex cosh( double _Complex );
5732long double _Complex cosh( long double _Complex );
5733
5734float tanh( float );§\indexc{tanh}§
5735double tanh( double );
5736long double tanh( long double );
5737float _Complex tanh( float _Complex );
5738double _Complex tanh( double _Complex );
5739long double _Complex tanh( long double _Complex );
5740
5741float asinh( float );§\indexc{asinh}§
5742double asinh( double );
5743long double asinh( long double );
5744float _Complex asinh( float _Complex );
5745double _Complex asinh( double _Complex );
5746long double _Complex asinh( long double _Complex );
5747
5748float acosh( float );§\indexc{acosh}§
5749double acosh( double );
5750long double acosh( long double );
5751float _Complex acosh( float _Complex );
5752double _Complex acosh( double _Complex );
5753long double _Complex acosh( long double _Complex );
5754
5755float atanh( float );§\indexc{atanh}§
5756double atanh( double );
5757long double atanh( long double );
5758float _Complex atanh( float _Complex );
5759double _Complex atanh( double _Complex );
5760long double _Complex atanh( long double _Complex );
5761\end{cfa}
5762
5763
5764\subsection{Error / Gamma}
5765
5766\leavevmode
5767\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5768float erf( float );§\indexc{erf}§
5769double erf( double );
5770long double erf( long double );
5771float _Complex erf( float _Complex );
5772double _Complex erf( double _Complex );
5773long double _Complex erf( long double _Complex );
5774
5775float erfc( float );§\indexc{erfc}§
5776double erfc( double );
5777long double erfc( long double );
5778float _Complex erfc( float _Complex );
5779double _Complex erfc( double _Complex );
5780long double _Complex erfc( long double _Complex );
5781
5782float lgamma( float );§\indexc{lgamma}§
5783double lgamma( double );
5784long double lgamma( long double );
5785float lgamma( float, int * );
5786double lgamma( double, int * );
5787long double lgamma( long double, int * );
5788
5789float tgamma( float );§\indexc{tgamma}§
5790double tgamma( double );
5791long double tgamma( long double );
5792\end{cfa}
5793
5794
5795\subsection{Nearest Integer}
5796
5797\leavevmode
5798\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5799float floor( float );§\indexc{floor}§
5800double floor( double );
5801long double floor( long double );
5802
5803float ceil( float );§\indexc{ceil}§
5804double ceil( double );
5805long double ceil( long double );
5806
5807float trunc( float );§\indexc{trunc}§
5808double trunc( double );
5809long double trunc( long double );
5810
5811float rint( float );§\indexc{rint}§
5812long double rint( long double );
5813long int rint( float );
5814long int rint( double );
5815long int rint( long double );
5816long long int rint( float );
5817long long int rint( double );
5818long long int rint( long double );
5819
5820long int lrint( float );§\indexc{lrint}§
5821long int lrint( double );
5822long int lrint( long double );
5823long long int llrint( float );
5824long long int llrint( double );
5825long long int llrint( long double );
5826
5827float nearbyint( float );§\indexc{nearbyint}§
5828double nearbyint( double );
5829long double nearbyint( long double );
5830
5831float round( float );§\indexc{round}§
5832long double round( long double );
5833long int round( float );
5834long int round( double );
5835long int round( long double );
5836long long int round( float );
5837long long int round( double );
5838long long int round( long double );
5839
5840long int lround( float );§\indexc{lround}§
5841long int lround( double );
5842long int lround( long double );
5843long long int llround( float );
5844long long int llround( double );
5845long long int llround( long double );
5846\end{cfa}
5847
5848
5849\subsection{Manipulation}
5850
5851\leavevmode
5852\begin{cfa}[aboveskip=0pt,belowskip=0pt]
5853float copysign( float, float );§\indexc{copysign}§
5854double copysign( double, double );
5855long double copysign( long double, long double );
5856
5857float frexp( float, int * );§\indexc{frexp}§
5858double frexp( double, int * );
5859long double frexp( long double, int * );
5860
5861float ldexp( float, int );§\indexc{ldexp}§
5862double ldexp( double, int );
5863long double ldexp( long double, int );
5864
5865[ float, float ] modf( float );§\indexc{modf}§
5866float modf( float, float * );
5867[ double, double ] modf( double );
5868double modf( double, double * );
5869[ long double, long double ] modf( long double );
5870long double modf( long double, long double * );
5871
5872float nextafter( float, float );§\indexc{nextafter}§
5873double nextafter( double, double );
5874long double nextafter( long double, long double );
5875
5876float nexttoward( float, long double );§\indexc{nexttoward}§
5877double nexttoward( double, long double );
5878long double nexttoward( long double, long double );
5879
5880float scalbn( float, int );§\indexc{scalbn}§
5881double scalbn( double, int );
5882long double scalbn( long double, int );
5883
5884float scalbln( float, long int );§\indexc{scalbln}§
5885double scalbln( double, long int );
5886long double scalbln( long double, long int );
5887\end{cfa}
5888
5889
5890\section{Multi-precision Integers}
5891\label{s:MultiPrecisionIntegers}
5892
5893\CFA has an interface to the GMP \Index{multi-precision} signed-integers~\cite{GMP}, similar to the \CC interface provided by GMP.
5894The \CFA interface wraps GMP routines into operator routines to make programming with multi-precision integers identical to using fixed-sized integers.
5895The \CFA type name for multi-precision signed-integers is \Indexc{Int} and the header file is \Indexc{gmp}.
5896
5897\begin{cfa}
5898void ?{}( Int * this );                                 §\C{// constructor}§
5899void ?{}( Int * this, Int init );
5900void ?{}( Int * this, zero_t );
5901void ?{}( Int * this, one_t );
5902void ?{}( Int * this, signed long int init );
5903void ?{}( Int * this, unsigned long int init );
5904void ?{}( Int * this, const char * val );
5905void ^?{}( Int * this );
5906
5907Int ?=?( Int * lhs, Int rhs );                  §\C{// assignment}§
5908Int ?=?( Int * lhs, long int rhs );
5909Int ?=?( Int * lhs, unsigned long int rhs );
5910Int ?=?( Int * lhs, const char * rhs );
5911
5912char ?=?( char * lhs, Int rhs );
5913short int ?=?( short int * lhs, Int rhs );
5914int ?=?( int * lhs, Int rhs );
5915long int ?=?( long int * lhs, Int rhs );
5916unsigned char ?=?( unsigned char * lhs, Int rhs );
5917unsigned short int ?=?( unsigned short int * lhs, Int rhs );
5918unsigned int ?=?( unsigned int * lhs, Int rhs );
5919unsigned long int ?=?( unsigned long int * lhs, Int rhs );
5920
5921long int narrow( Int val );
5922unsigned long int narrow( Int val );
5923
5924int ?==?( Int oper1, Int oper2 );               §\C{// comparison}§
5925int ?==?( Int oper1, long int oper2 );
5926int ?==?( long int oper2, Int oper1 );
5927int ?==?( Int oper1, unsigned long int oper2 );
5928int ?==?( unsigned long int oper2, Int oper1 );
5929
5930int ?!=?( Int oper1, Int oper2 );
5931int ?!=?( Int oper1, long int oper2 );
5932int ?!=?( long int oper1, Int oper2 );
5933int ?!=?( Int oper1, unsigned long int oper2 );
5934int ?!=?( unsigned long int oper1, Int oper2 );
5935
5936int ?<?( Int oper1, Int oper2 );
5937int ?<?( Int oper1, long int oper2 );
5938int ?<?( long int oper2, Int oper1 );
5939int ?<?( Int oper1, unsigned long int oper2 );
5940int ?<?( unsigned long int oper2, Int oper1 );
5941
5942int ?<=?( Int oper1, Int oper2 );
5943int ?<=?( Int oper1, long int oper2 );
5944int ?<=?( long int oper2, Int oper1 );
5945int ?<=?( Int oper1, unsigned long int oper2 );
5946int ?<=?( unsigned long int oper2, Int oper1 );
5947
5948int ?>?( Int oper1, Int oper2 );
5949int ?>?( Int oper1, long int oper2 );
5950int ?>?( long int oper1, Int oper2 );
5951int ?>?( Int oper1, unsigned long int oper2 );
5952int ?>?( unsigned long int oper1, Int oper2 );
5953
5954int ?>=?( Int oper1, Int oper2 );
5955int ?>=?( Int oper1, long int oper2 );
5956int ?>=?( long int oper1, Int oper2 );
5957int ?>=?( Int oper1, unsigned long int oper2 );
5958int ?>=?( unsigned long int oper1, Int oper2 );
5959
5960Int +?( Int oper );                                             §\C{// arithmetic}§
5961Int -?( Int oper );
5962Int ~?( Int oper );
5963
5964Int ?&?( Int oper1, Int oper2 );
5965Int ?&?( Int oper1, long int oper2 );
5966Int ?&?( long int oper1, Int oper2 );
5967Int ?&?( Int oper1, unsigned long int oper2 );
5968Int ?&?( unsigned long int oper1, Int oper2 );
5969Int ?&=?( Int * lhs, Int rhs );
5970
5971Int ?|?( Int oper1, Int oper2 );
5972Int ?|?( Int oper1, long int oper2 );
5973Int ?|?( long int oper1, Int oper2 );
5974Int ?|?( Int oper1, unsigned long int oper2 );
5975Int ?|?( unsigned long int oper1, Int oper2 );
5976Int ?|=?( Int * lhs, Int rhs );
5977
5978Int ?^?( Int oper1, Int oper2 );
5979Int ?^?( Int oper1, long int oper2 );
5980Int ?^?( long int oper1, Int oper2 );
5981Int ?^?( Int oper1, unsigned long int oper2 );
5982Int ?^?( unsigned long int oper1, Int oper2 );
5983Int ?^=?( Int * lhs, Int rhs );
5984
5985Int ?+?( Int addend1, Int addend2 );
5986Int ?+?( Int addend1, long int addend2 );
5987Int ?+?( long int addend2, Int addend1 );
5988Int ?+?( Int addend1, unsigned long int addend2 );
5989Int ?+?( unsigned long int addend2, Int addend1 );
5990Int ?+=?( Int * lhs, Int rhs );
5991Int ?+=?( Int * lhs, long int rhs );
5992Int ?+=?( Int * lhs, unsigned long int rhs );
5993Int ++?( Int * lhs );
5994Int ?++( Int * lhs );
5995
5996Int ?-?( Int minuend, Int subtrahend );
5997Int ?-?( Int minuend, long int subtrahend );
5998Int ?-?( long int minuend, Int subtrahend );
5999Int ?-?( Int minuend, unsigned long int subtrahend );
6000Int ?-?( unsigned long int minuend, Int subtrahend );
6001Int ?-=?( Int * lhs, Int rhs );
6002Int ?-=?( Int * lhs, long int rhs );
6003Int ?-=?( Int * lhs, unsigned long int rhs );
6004Int --?( Int * lhs );
6005Int ?--( Int * lhs );
6006
6007Int ?*?( Int multiplicator, Int multiplicand );
6008Int ?*?( Int multiplicator, long int multiplicand );
6009Int ?*?( long int multiplicand, Int multiplicator );
6010Int ?*?( Int multiplicator, unsigned long int multiplicand );
6011Int ?*?( unsigned long int multiplicand, Int multiplicator );
6012Int ?*=?( Int * lhs, Int rhs );
6013Int ?*=?( Int * lhs, long int rhs );
6014Int ?*=?( Int * lhs, unsigned long int rhs );
6015
6016Int ?/?( Int dividend, Int divisor );
6017Int ?/?( Int dividend, unsigned long int divisor );
6018Int ?/?( unsigned long int dividend, Int divisor );
6019Int ?/?( Int dividend, long int divisor );
6020Int ?/?( long int dividend, Int divisor );
6021Int ?/=?( Int * lhs, Int rhs );
6022Int ?/=?( Int * lhs, long int rhs );
6023Int ?/=?( Int * lhs, unsigned long int rhs );
6024
6025[ Int, Int ] div( Int dividend, Int divisor );
6026[ Int, Int ] div( Int dividend, unsigned long int divisor );
6027
6028Int ?%?( Int dividend, Int divisor );
6029Int ?%?( Int dividend, unsigned long int divisor );
6030Int ?%?( unsigned long int dividend, Int divisor );
6031Int ?%?( Int dividend, long int divisor );
6032Int ?%?( long int dividend, Int divisor );
6033Int ?%=?( Int * lhs, Int rhs );
6034Int ?%=?( Int * lhs, long int rhs );
6035Int ?%=?( Int * lhs, unsigned long int rhs );
6036
6037Int ?<<?( Int shiften, mp_bitcnt_t shift );
6038Int ?<<=?( Int * lhs, mp_bitcnt_t shift );
6039Int ?>>?( Int shiften, mp_bitcnt_t shift );
6040Int ?>>=?( Int * lhs, mp_bitcnt_t shift );
6041
6042Int abs( Int oper );                                    §\C{// number functions}§
6043Int fact( unsigned long int N );
6044Int gcd( Int oper1, Int oper2 );
6045Int pow( Int base, unsigned long int exponent );
6046Int pow( unsigned long int base, unsigned long int exponent );
6047void srandom( gmp_randstate_t state );
6048Int random( gmp_randstate_t state, mp_bitcnt_t n );
6049Int random( gmp_randstate_t state, Int n );
6050Int random( gmp_randstate_t state, mp_size_t max_size );
6051int sgn( Int oper );
6052Int sqrt( Int oper );
6053
6054forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  §\C{// I/O}§
6055forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype * os, Int mp );
6056\end{cfa}
6057
6058The following factorial programs contrast using GMP with the \CFA and C interfaces, where the output from these programs appears in \VRef[Figure]{f:MultiPrecisionFactorials}.
6059(Compile with flag \Indexc{-lgmp} to link with the GMP library.)
6060\begin{quote2}
6061\begin{tabular}{@{}l@{\hspace{\parindentlnth}}|@{\hspace{\parindentlnth}}l@{}}
6062\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}}      \\
6063\hline
6064\begin{cfa}
6065#include <gmp>§\indexc{gmp}§
6066int main( void ) {
6067        sout | "Factorial Numbers" | endl;
6068        Int fact = 1;
6069
6070        sout | 0 | fact | endl;
6071        for ( unsigned int i = 1; i <= 40; i += 1 ) {
6072                fact *= i;
6073                sout | i | fact | endl;
6074        }
6075}
6076\end{cfa}
6077&
6078\begin{cfa}
6079#include <gmp.h>§\indexc{gmp.h}§
6080int main( void ) {
6081        ®gmp_printf®( "Factorial Numbers\n" );
6082        ®mpz_t® fact;
6083        ®mpz_init_set_ui®( fact, 1 );
6084        ®gmp_printf®( "%d %Zd\n", 0, fact );
6085        for ( unsigned int i = 1; i <= 40; i += 1 ) {
6086                ®mpz_mul_ui®( fact, fact, i );
6087                ®gmp_printf®( "%d %Zd\n", i, fact );
6088        }
6089}
6090\end{cfa}
6091\end{tabular}
6092\end{quote2}
6093
6094\begin{figure}
6095\begin{cfa}
6096Factorial Numbers
60970 1
60981 1
60992 2
61003 6
61014 24
61025 120
61036 720
61047 5040
61058 40320
61069 362880
610710 3628800
610811 39916800
610912 479001600
611013 6227020800
611114 87178291200
611215 1307674368000
611316 20922789888000
611417 355687428096000
611518 6402373705728000
611619 121645100408832000
611720 2432902008176640000
611821 51090942171709440000
611922 1124000727777607680000
612023 25852016738884976640000
612124 620448401733239439360000
612225 15511210043330985984000000
612326 403291461126605635584000000
612427 10888869450418352160768000000
612528 304888344611713860501504000000
612629 8841761993739701954543616000000
612730 265252859812191058636308480000000
612831 8222838654177922817725562880000000
612932 263130836933693530167218012160000000
613033 8683317618811886495518194401280000000
613134 295232799039604140847618609643520000000
613235 10333147966386144929666651337523200000000
613336 371993326789901217467999448150835200000000
613437 13763753091226345046315979581580902400000000
613538 523022617466601111760007224100074291200000000
613639 20397882081197443358640281739902897356800000000
613740 815915283247897734345611269596115894272000000000
6138\end{cfa}
6139\caption{Multi-precision Factorials}
6140\label{f:MultiPrecisionFactorials}
6141\end{figure}
6142
6143
6144\section{Rational Numbers}
6145\label{s:RationalNumbers}
6146
6147Rational numbers are numbers written as a ratio, \ie as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.
6148When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
6149
6150\begin{cfa}[belowskip=0pt]
6151// implementation
6152struct Rational {§\indexc{Rational}§
6153        long int numerator, denominator;                                        // invariant: denominator > 0
6154}; // Rational
6155
6156Rational rational();                                    §\C{// constructors}§
6157Rational rational( long int n );
6158Rational rational( long int n, long int d );
6159void ?{}( Rational * r, zero_t );
6160void ?{}( Rational * r, one_t );
6161
6162long int numerator( Rational r );               §\C{// numerator/denominator getter/setter}§
6163long int numerator( Rational r, long int n );
6164long int denominator( Rational r );
6165long int denominator( Rational r, long int d );
6166
6167int ?==?( Rational l, Rational r );             §\C{// comparison}§
6168int ?!=?( Rational l, Rational r );
6169int ?<?( Rational l, Rational r );
6170int ?<=?( Rational l, Rational r );
6171int ?>?( Rational l, Rational r );
6172int ?>=?( Rational l, Rational r );
6173
6174Rational -?( Rational r );                              §\C{// arithmetic}§
6175Rational ?+?( Rational l, Rational r );
6176Rational ?-?( Rational l, Rational r );
6177Rational ?*?( Rational l, Rational r );
6178Rational ?/?( Rational l, Rational r );
6179
6180double widen( Rational r );                             §\C{// conversion}§
6181Rational narrow( double f, long int md );
6182
6183forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * ); // I/O
6184forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational );
6185\end{cfa}
6186
6187
6188\bibliographystyle{plain}
6189\bibliography{cfa}
6190
6191
6192\addcontentsline{toc}{section}{\indexname} % add index name to table of contents
6193\begin{theindex}
6194Italic page numbers give the location of the main entry for the referenced term.
6195Plain page numbers denote uses of the indexed term.
6196Entries for grammar non-terminals are italicized.
6197A typewriter font is used for grammar terminals and program identifiers.
6198\indexspace
6199\input{user.ind}
6200\end{theindex}
6201
6202
6203\end{document}
6204
6205% Local Variables: %
6206% tab-width: 4 %
6207% fill-column: 100 %
6208% compile-command: "make" %
6209% End: %
Note: See TracBrowser for help on using the repository browser.