source: doc/user/user.tex @ e945826

ADTaaron-thesisarm-ehast-experimentalcleanup-dtorsctordeferred_resndemanglerenumforall-pointer-decaygc_noraiijacob/cs343-translationjenkins-sandboxmemorynew-astnew-ast-unique-exprnew-envno_listpersistent-indexerpthread-emulationqualifiedEnumresolv-newwith_gc
Last change on this file since e945826 was e945826, checked in by Peter A. Buhr <pabuhr@…>, 8 years ago

formatting in iostream.c, and change escape sequences in documentation

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