Changeset 07bc165 for doc/user


Ignore:
Timestamp:
Jul 10, 2016, 12:56:11 PM (5 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
6e4b913
Parents:
0b4d93a
Message:

update section on pointer/reference and LaTeX macros

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/user/user.tex

    r0b4d93a r07bc165  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Thu Jul  7 08:25:37 2016
    14 %% Update Count     : 1099
     13%% Last Modified On : Sun Jul 10 12:52:09 2016
     14%% Update Count     : 1200
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    127127\section{Introduction}
    128128
    129 \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.
    130 The syntax of the \CFA language builds from C, and should look immediately familiar to C/\CC programmers.
     129\CFA\footnote{Pronounced ``C-for-all'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed as an evolutionary step forward from the C programming language.
     130The syntax of the \CFA language builds from C, and should look immediately familiar to C/\Index*[C++]{\CC} programmers.
    131131% Any language feature that is not described here can be assumed to be using the standard C11 syntax.
    132132\CFA adds many modern programming-language features that directly lead to increased \emph{safety} and \emph{productivity}, while maintaining interoperability with existing C programs and achieving C performance.
    133133Like C, \CFA is a statically typed, procedural language with a low-overhead runtime, meaning there is no global garbage-collection.
    134 The primary new features include parametric-polymorphism routines and types, exceptions, concurrency, and modules.
     134The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
    135135
    136136One 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''.
     
    140140instead, a programmer evolves an existing C program into \CFA by incrementally incorporating \CFA features.
    141141New programs can be written in \CFA using a combination of C and \CFA features.
    142 \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.
     142\Index*[C++]{\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.
    143143\CFA has 30 years of hindsight and a clean starting point.
    144144
    145 Like \CC, there may be both an old and new ways to achieve the same effect.
     145Like \Index*[C++]{\CC}, there may be both an old and new ways to achieve the same effect.
    146146For example, the following programs compare the \CFA and C I/O mechanisms.
    147147\begin{quote2}
     
    166166\end{quote2}
    167167Both programs output the same result.
    168 While the \CFA I/O looks similar to the \CC output style, there are important differences, such as automatic spacing between variables as in Python (see also~\VRef{s:IOLibrary}).
     168While the \CFA I/O looks similar to the \Index*[C++]{\CC} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see also~\VRef{s:IOLibrary}).
    169169
    170170This document is a user manual for the \CFA programming language, targeted at \CFA programmers.
     
    178178
    179179The \CFA project started with K-W C~\cite{Buhr94a,Till89}, which extended C with new declaration syntax, multiple return values from routines, and extended assignment capabilities using the notion of tuples.
    180 (See~\cite{Werther96} for some similar work, but for \CC.)
    181 The 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.
     180(See~\cite{Werther96} for some similar work, but for \Index*[C++]{\CC}.)
     181The original \CFA project~\cite{Ditchfield92} extended the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC} approach of object-oriented extensions to the C type-system.
    182182A 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.
    183183As 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.
     
    189189For system programming, where direct access to hardware and dealing with real-time issues is a requirement, C is usually the language of choice.
    190190As well, there are millions of lines of C legacy code, forming the base for many software development projects (especially on UNIX systems).
    191 The 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\%.
     191The TIOBE index (\url{http://www.tiobe.com/tiobe_index}) for March 2016 shows programming-language popularity, with \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC} 6.7\%, \CS 4.3\%, \Index*{Python} 4.3\%, and all other programming languages below 3\%.
    192192As well, for 30 years, C has been the number 1 and 2 most popular programming language:
    193193\begin{center}
     
    203203\end{tabular}
    204204\end{center}
    205 Hence, C is still an extremely important programming language, with double the usage of \CC, where \CC itself is largely C code.
     205Hence, C is still an extremely important programming language, with double the usage of \Index*[C++]{\CC}, where \CC itself is largely C code.
    206206Finally, 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.
    207207Unfortunately, C has too many problems and omissions to make it an acceptable programming language for modern needs.
     
    211211however, it largely extended the language, and did not address many existing problems.\footnote{%
    212212Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
    213 Fortran~\cite{Fortran08}, Ada~\cite{Ada12}, and Cobol~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (e.g., objects, concurrency) are added and problems fixed within the framework of the existing language.
    214 Java~\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.
     213\Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (e.g., objects, concurrency) are added and problems fixed within the framework of the existing language.
     214\Index*{Java}~\cite{Java8}, \Index*{Go}~\cite{Go}, \Index*{Rust}~\cite{Rust} and \Index*{D}~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
    215215These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
    216216As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
     
    232232In 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.
    233233Language developers often state that adequate library support takes more work than designing and implementing the language itself.
    234 Like \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.
     234Like \Index*[C++]{\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.
    235235Hence, \CFA begins by leveraging the large repository of C libraries with little cost.
    236236
     
    241241char abs( char );
    242242extern "C" {
    243 int abs( int );                                 // use default C routine for int
     243int abs( int );                                 §\C{// use default C routine for int}§
    244244} // extern "C"
    245245long int abs( long int );
     
    253253\end{lstlisting}
    254254The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
    255 Hence, names appearing in an ©extern "C"© block have \newterm{C linkage}.
    256 Then overloading polymorphism uses a mechanism called \newterm{name mangling} to create unique names that are different from C names, which are not mangled.
     255Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
     256Then overloading polymorphism uses a mechanism called \newterm{name mangling}\index{mangling!name} to create unique names that are different from C names, which are not mangled.
    257257Hence, 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.
    258258There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
     
    265265\section[Compiling CFA Program]{Compiling \CFA Program}
    266266
    267 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU ©gcc©\index{gcc} command, e.g.:
     267The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, e.g.:
    268268\begin{lstlisting}
    269269cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
    270270\end{lstlisting}
    271 By default, \CFA programs having the following ©gcc© flags turned on:
     271\CFA programs having the following ©gcc© flags turned on:
    272272\begin{description}
    273 \item\hspace*{-0.6ex}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
     273\item
     274\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
    274275The 1999 C standard plus GNU extensions.
    275 \item\hspace*{-0.6ex}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{©-fgnu89-¶inline¶©}}
     276\item
     277\Indexc{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{©-fgnu89-inline©}}
    276278Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
    277279\end{description}
    278 The following new \CFA option is available:
     280The following new \CFA options are available:
    279281\begin{description}
    280 \item\hspace*{-0.6ex}\Indexc{-CFA}\index{compilation option!-CFA@{©-CFA©}}
     282\item
     283\Indexc{-CFA}\index{compilation option!-CFA@©-CFA©}
    281284Only 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.
     285The generated code started with the standard \CFA prelude.
     286
     287\item
     288\Indexc{-debug}\index{compilation option!-debug@©-debug©}
     289The program is linked with the debugging version of the runtime system.
     290The debug version performs runtime checks to help during the debugging phase of a \CFA program, but substantially slows the execution of the program.
     291The runtime checks should only be removed after the program is completely debugged.
     292\textbf{This option is the default.}
     293
     294\item
     295\Indexc{-nodebug}\index{compilation option!-nodebug@©-nodebug©}
     296The program is linked with the non-debugging version of the unikernel or multikernel, so the execution of the program is faster.
     297\Emph{However, no runtime checks or ©assert©s are performed so errors usually result in abnormal program termination.}
     298
     299\item
     300\Indexc{-help}\index{compilation option!-help@©-help©}
     301Information about the set of \CFA compilation flags is printed.
     302
     303\item
     304\Indexc{-nohelp}\index{compilation option!-nohelp@©-nohelp©}
     305Information about the set of \CFA compilation flags is not printed.
     306\textbf{This option is the default.}
     307
     308\item
     309\Indexc{-quiet}\index{compilation option!-quiet@©-quiet©}
     310The \CFA compilation message is not printed at the beginning of a compilation.
     311
     312\item
     313\Indexc{-noquiet}\index{compilation option!-noquiet@©-noquiet©}
     314The \CFA compilation message is printed at the beginning of a compilation.
     315\textbf{This option is the default.}
    282316\end{description}
    283317
    284318The following preprocessor variables are available:
    285319\begin{description}
    286 \item\hspace*{-0.6ex}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
     320\item
     321\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
    287322is always available during preprocessing and its value is the current major \Index{version number} of \CFA.\footnote{
    288323The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
    289324Hence, the need to have three variables for the major, minor and patch version number.}
    290325
    291 \item\hspace*{-0.6ex}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
     326\item
     327\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
    292328is always available during preprocessing and its value is the current minor \Index{version number} of \CFA.
    293329
    294 \item\hspace*{-0.6ex}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
     330\item
     331\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
    295332is always available during preprocessing and its value is the current patch \Index{version number} of \CFA.
    296333
    297 \item\hspace*{-0.6ex}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@©__CFA__©} and \Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©}
    298 are always available during preprocessing and have no value.
     334\item
     335\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©}
     336is always available during preprocessing and has no value.
    299337\end{description}
    300 
    301338These preprocessor variables allow conditional compilation of programs that must work differently in these situations.
    302339For example, to toggle between C and \CFA extensions, using the following:
     
    308345#endif
    309346\end{lstlisting}
    310 which conditionally includes the correct header file, if the program is compiled using ©gcc© or ©cfa©.
     347which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
    311348
    312349
     
    342379\end{enumerate}
    343380It 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).
    344 This extension is backwards compatible, matches with the use of underscore in variable names, and appears in Ada and Java 8.
     381This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
    345382
    346383
     
    359396\end{tabular}
    360397\end{quote2}
    361 Is this an array of 5 pointers to integers or a pointer to an array of 5 integers?
     398Is this an array of 5 pointers to integers or a \Index{pointer} to an array of 5 integers?
    362399The fact this declaration is unclear to many C programmers means there are \Index{productivity} and \Index{safety} issues even for basic programs.
    363400Another 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.
    364 For example, a routine returning a pointer to an array of integers is defined and used in the following way:
     401For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    365402\begin{lstlisting}
    366403int (*f())[5] {...};                    §\C{}§
     
    373410The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
    374411In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
    375 The \CFA declarations move the qualifiers to the left of the base type, i.e., blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
     412The \CFA declarations move the qualifiers to the left of the base type, i.e., move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
    376413\begin{quote2}
    377414\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     
    393430% Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter.
    394431However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
    395 For instance, variables ©x© and ©y© of type pointer to integer are defined in \CFA as follows:
     432For instance, variables ©x© and ©y© of type \Index{pointer} to integer are defined in \CFA as follows:
    396433\begin{quote2}
    397434\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     
    406443\end{tabular}
    407444\end{quote2}
    408 The downside of this semantics is the need to separate regular and pointer declarations:
     445The downside of this semantics is the need to separate regular and \Index{pointer} declarations:
    409446\begin{quote2}
    410447\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     
    549586\end{tabular}
    550587\end{quote2}
    551 where the right example is how the compiler logically interpreters the variables in the left example.
    552 Since a variable name only points to one location during its lifetime, it is an \Index{immutable} pointer;
     588where the right example is how the compiler logically interprets the variables in the left example.
     589Since a variable name only points to one location during its lifetime, it is an \Index{immutable} \Index{pointer};
    553590hence, variables ©x© and ©y© are constant pointers in the compiler interpretation.
    554591In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address.
     
    570607\end{tabular}
    571608\end{quote2}
    572 Finally, the immutable nature of a variable's address and the fact that there is no storage for a variable address means pointer assignment is impossible.
     609Finally, the immutable nature of a variable's address and the fact that there is no storage for a variable address means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible.
    573610Therefore, the expression ©x = y© only has one meaning, ©*x = *y©, i.e., manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding.
    574611
    575 A pointer/reference is a generalization of a variable name, i.e., a mutable address that can point to more than one memory location during its lifetime.
     612A \Index{pointer}/\Index{reference} is a generalization of a variable name, i.e., a mutable address that can point to more than one memory location during its lifetime.
    576613(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and may not occupy storage as the literal is embedded directly into instructions.)
    577614Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.:
     
    581618int x, y, ®*® p1, ®*® p2, ®**® p3;
    582619p1 = ®&®x;               // p1 points to x
    583 p2 = p1;                 // p2 also points to x
     620p2 = p1;                 // p2 points to x
    584621p1 = ®&®y;               // p1 points to y
    585 p1 = p2 + 1;    // p1 points to y, pointer arithmetic
    586622p3 = &p2;               // p3 points to p2
    587623\end{lstlisting}
     
    592628
    593629Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location.
    594 In many cases, the compiler can infer the meaning:
     630In many cases, a compiler might be able to infer the meaning:
    595631\begin{lstlisting}
    596632p2 = p1 + x;                                    §\C{// compiler infers *p2 = *p1 + x;}§
    597633\end{lstlisting}
    598634because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
    599 Algol68~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
    600 However, there are ambiguous cases, especially when \Index{pointer arithmetic} is possible, as in C:
     635\Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
     636However, in C, the following cases are ambiguous, especially with pointer arithmetic:
    601637\begin{lstlisting}
    602638p1 = p2;                                                §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§
     
    604640\end{lstlisting}
    605641
    606 Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address!duality ambiguity}.
     642Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}.
    607643In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©.
    608644\begin{lstlisting}
     
    610646*p1 = *p1 + 1;                                  §\C{// pointed-to value assignment / operation}§
    611647\end{lstlisting}
    612 which works well for situations where manipulation of addresses in the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
     648which works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
    613649
    614650However, in most other situations, the pointed-to value is requested more often than the pointer address.
     
    626662int x, y, ®&® r1, ®&® r2, ®&&® r3;
    627663®&®r1 = &x;                                             §\C{// r1 points to x}§
    628 ®&®r2 = &r1;                                    §\C{// r2 also points to x}§
    629 ®&®r1 = &y;                                             §\C{// r2 also points to x}§
    630 ®&®r1 = &r2 + 1;                                §\C{// r1 points to y, pointer arithmetic}§
    631 ®&®r3 = ®&®&r2;                                 §\C{// r3 points to r2}§
     664®&®r2 = &r1;                                    §\C{// r2 points to x}§
     665®&®r1 = &y;                                             §\C{// r1 points to y}§
     666®&&®r3 = ®&®&r2;                                §\C{// r3 points to r2}§
    632667r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
    633668\end{lstlisting}
     
    648683Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}):
    649684\begin{lstlisting}
    650 (&®*®)r1 = &x;                                  §\C{// (\&*) cancel out giving variable r1 not the variable pointed-to by r1}§
     685(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving variable r1 not variable pointed-to by r1}§
    651686\end{lstlisting}
    652687Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
    653688\begin{lstlisting}
    654 (&®*®)r3 = &(&®*®)r2;                   §\C{// (\&*) cancel out giving the address of variable r2
    655 \end{lstlisting}
    656 \Index{Cancellation}\index{pointer!cancellation rule} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses.
     689(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3
     690\end{lstlisting}
     691Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses.
    657692\begin{lstlisting}
    658693int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
    659                  &r1 = &x, &&r2 = &&r1, &&&r3 = &&r2;
     694                 &r1 = x,    &&r2 = r1,   &&&r3 = r2;
    660695***p3 = 3;                                              §\C{// change x}§
    661696r3 = 3;                                                 §\C{// change x, ***r3}§
     
    668703Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one.
    669704That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance.
    670 A programmer selects a pointer or reference type solely on whether the address is dereferences frequently or infrequently, which dictates the amount of direct aid from the compiler;
     705A programmer selects a pointer or reference type solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of direct aid from the compiler;
    671706otherwise, everything else is equal.
    672707
    673 Interestingly, \CC deals with the address duality by making the pointed-to value the default, and prevent\-ing changes to the reference address, which eliminates half of the duality.
    674 Java deals with the address duality by making address assignment the default and providing a \Index{clone} mechanism to change the pointed-to value.
     708Interestingly, \Index*[C++]{\CC} deals with the address duality by making the pointed-to value the default, and prevent\-ing changes to the reference address, which eliminates half of the duality.
     709\Index*{Java} deals with the address duality by making address assignment the default and requiring field assignment (direct or indirect via methods), i.e., there is no builtin bit-wise or method-wise assignment, which eliminates half of the duality.
    675710
    676711As for a pointer, a reference may have qualifiers:
    677712\begin{lstlisting}
    678713const int cx = 5;                               §\C{// cannot change cx;}§
    679 const int & r3 = &cx;                   §\C{// cannot change what r3 is pointing to}§
    680 ®&®r3 = &cx;                                    §\C{// can change r3
    681 r3 = 7;                                                 §\C{// error, cannot change cx}§
    682 int & const r4 = &x;                    §\C{// must be initialized, \CC reference}§
    683 ®&®r4 = &x;                                             §\C{// error, cannot change r4
    684 const int & const r5 = &cx;             §\C{// must be initialized, \CC reference}§
    685 r5 = 7;                                                 §\C{// error, cannot change cx}§
    686 ®&®r5 = &cx;                                    §\C{// error, cannot change r5
    687 \end{lstlisting}
    688 Hence, for type ©& const©, there is no pointer assignment, so ©&r4 = &x© is disallowed, and \emph{the address value cannot be ©0©}.
    689 In effect, the compiler is managing the addresses fpr type ©& const© not the programmer.
    690 
    691 \Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage for an object.
     714const int & cr = cx;                    §\C{// cannot change what cr points to}§
     715®&®cr = &cx;                                    §\C{// can change cr
     716cr = 7;                                                 §\C{// error, cannot change cx}§
     717int & const rc = x;                             §\C{// must be initialized, \CC reference}§
     718®&®rc = &x;                                             §\C{// error, cannot change rc
     719const int & const crc = cx;             §\C{// must be initialized, \CC reference}§
     720crc = 7;                                                §\C{// error, cannot change cx}§
     721®&®crc = &cx;                                   §\C{// error, cannot change crc
     722\end{lstlisting}
     723Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}.
     724In effect, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented.
     725
     726\Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object.
    692727There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding.
    693 For reference initialization (like pointer), the initializing value must be an address (lvalue) not a value (rvalue).
     728For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
    694729\begin{lstlisting}
    695730int * p = &x;                                   §\C{// both \&x and x are possible interpretations}§
    696731int & r = x;                                    §\C{// x unlikely interpretation, because of auto-dereferencing}§
    697732\end{lstlisting}
    698 Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression:
     733Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression.
    699734Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator.
    700735\begin{lstlisting}
    701 int & f( int & ri );                    §\C{// reference parameter and return}§
    702 z = f( x ) + f( y );                    §\C{// reference operator added not required
    703 \end{lstlisting}
    704 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©.
     736int & f( int & rp );                    §\C{// reference parameter and return}§
     737z = f( x ) + f( y );                    §\C{// reference operator added
     738\end{lstlisting}
     739Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©.
    705740The return reference from ©f© is copied into a compiler generated temporary, which is treated as an initialization.
    706741
    707742When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
    708743\begin{lstlisting}
    709 void f( ®const® int & cri );
    710 void g( ®const® int * cri );
     744void f( ®const® int & crp );
     745void g( ®const® int * cpp );
    711746f( 3 );                   g( &3 );
    712747f( x + y );             g( &(x + y) );
    713748\end{lstlisting}
    714749Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
    715 (The ©&© is necessary for the pointer parameter to make the types match, and is common requirement for a C programmer.)
    716 \CFA extends this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed to by the reference parameter and can be changed.
    717 \begin{lstlisting}
    718 void f( int & cri );
    719 void g( int * cri );
     750(The ©&© is necessary for the pointer parameter to make the types match, and is a common requirement for a C programmer.)
     751\CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.
     752\begin{lstlisting}
     753void f( int & rp );
     754void g( int * pp );
    720755f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
    721756f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
    722757\end{lstlisting}
    723 Essentially, there is an implicit rvalue to lvalue conversion in this case.\footnote{
    724 This conversion attempts to address the \newterm{const Hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.}
    725 The implicit conversion allows seamless calls to any routine without having to explicit name/copy the literal/expression to allow the call.
    726 
    727 While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine pointers in an inconsistent way: a routine pointer is both a reference and a pointer (particle and wave).
     758Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
     759This conversion attempts to address the \newterm{const hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.}
     760The implicit conversion allows seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
     761
     762While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave).
    728763\begin{lstlisting}
    729764void f( int p ) {...}
     
    737772const void (&fp)( int ) = f;
    738773fp( 3 );
    739 fp = ...                                                §\C{// change code not allowed
    740 &fp = ...;                                              §\C{// change routine reference}§
     774fp = ...                                                §\C{// error, cannot change code
     775&fp = ...;                                              §\C{// changing routine reference}§
    741776\end{lstlisting}
    742777because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{
    743778Dynamic code rewriting is possible but only in special circumstances.}
    744 \CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for routine variables.
     779\CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for them.
    745780
    746781
     
    777812
    778813In detail, the brackets, ©[]©, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
    779 Michael Tiemann, with help from Doug Lea, provided named return values in g++, circa 1989.}
     814\Index*{Michael Tiemann}, with help from \Index*{Doug Lea}, provided named return values in g++, circa 1989.}
    780815The value of each local return variable is automatically returned at routine termination.
    781816Declaration qualifiers can only appear at the start of a routine definition, e.g.:
     
    10561091
    10571092Given the \CFA restrictions above, both named and default arguments are backwards compatible.
    1058 \CC only supports default arguments;
    1059 Ada supports both named and default arguments.
     1093\Index*[C++]{\CC} only supports default arguments;
     1094\Index*{Ada} supports both named and default arguments.
    10601095
    10611096
     
    11331168\end{figure}
    11341169In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
    1135 In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does Java, rather than the \CC type-selection operator ``©::©''.
     1170In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does \Index*{Java}, rather than the \CC type-selection operator ``©::©''.
    11361171
    11371172
     
    11581193Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks;
    11591194the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program.
    1160 The following program in undefined in \CFA (and ©gcc©\index{gcc})
     1195The following program in undefined in \CFA (and Indexc{gcc})
    11611196\begin{lstlisting}
    11621197[* [int]( int )] foo() {                §\C{// int (*foo())( int )}§
     
    13371372[ §\emph{lvalue}§, ..., §\emph{lvalue}§ ] = §\emph{expr}§;
    13381373\end{lstlisting}
     1374\index{lvalue}
    13391375The 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.
    13401376©$\emph{expr}$© is any standard arithmetic expression.
     
    13761412[ §\emph{lvalue}§, . . ., §\emph{lvalue}§ ] = [ §\emph{expr}§, . . ., §\emph{expr}§ ];
    13771413\end{lstlisting}
     1414\index{lvalue}
    13781415The left-hand side is a tuple of \emph{lvalues}, and the right-hand side is a tuple of \emph{expr}s.
    13791416Each \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.
     
    16651702Often transferring into a block can bypass variable declaration and/or its initialization, which results in subsequent errors.
    16661703There are virtually no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
    1667 Nevertheless, C does have an idiom where this capability is used, known as ``Duff's device''~\cite{Duff83}:
     1704Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
    16681705\begin{lstlisting}
    16691706register int n = (count + 7) / 8;
     
    17141751the number of ©switch© statements is small,
    17151752\item
    1716 most ©switch© statements are well formed (i.e., no Duff's device),
     1753most ©switch© statements are well formed (i.e., no \Index*{Duff's device}),
    17171754\item
    17181755the ©default© clause is usually written as the last case-clause,
     
    17491786The 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.
    17501787\item
    1751 Eliminating Duff's device is straightforward and only invalidates a small amount of very questionable code.
     1788Eliminating \Index*{Duff's device} is straightforward and only invalidates a small amount of very questionable code.
    17521789The solution is to allow ©case© clauses to only appear at the same nesting level as the ©switch© body, as is done in most other programming languages with ©switch© statements.
    17531790\item
     
    19912028\CFA supports C initialization of structures, but it also adds constructors for more advanced initialization.
    19922029Additionally, \CFA adds destructors that are called when a variable is de-allocated (variable goes out of scope or object is deleted).
    1993 These functions take a reference to the structure as a parameter (see
    1994 References for more information).
     2030These functions take a reference to the structure as a parameter (see References for more information).
    19952031
    19962032\begin{figure}
     
    20452081\section{References}
    20462082
    2047 \CFA supports reference types similar to rvalue references in \CC.
    2048 A reference is essentially an alias for a variable, allowing multiple names to refer to the same object.
    2049 A 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.
    2050 It cannot be NULL, it must be assigned a value at initialization, and the object it references cannot change once it is set.
     2083
    20512084By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks.
    20522085In structures, a reference can replace a pointer to an object that should always have a valid value.
     
    20572090When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
    20582091The ©&© 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.
    2059 
    2060 \begin{figure}
    2061 \begin{lstlisting}
    2062 // parameter p is a reference to a Point
    2063 void movePointUp(Point &p) {
    2064         p.y += 1.0; // Uses dot-notation to access fields
    2065 }
    2066 
    2067 Point p1 = ...;
    2068 ColoredPoint cp1 = ...;
    2069 movePoint(p1); // reference to p1 passed to movePoint
    2070 movePoint(cp1); // reference to cp1 passed to movePoint
    2071 
    2072 // a ListElement cannot be created without a valid list
    2073 
    2074 struct ListElement {
    2075         int element;
    2076         List &list; // a list element has a reference to the list
    2077 }
    2078 
    2079 // The constructor must initialize the reference
    2080 void ?{}(ListElement &le, int e, List &l) {
    2081         le.element = e;
    2082         &le.list = &l; // initialize the reference
    2083 }
    2084 
    2085 ListElement e1{88, numberList}; // uses constructor
    2086 ListElement e2; // compiler error: uninitialized reference
    2087 Listing 10: References
    2088 \end{lstlisting}
    2089 \end{figure}
    20902092\end{comment}
    20912093
     
    21312133The operations ©&&©, ©||©, and ©!© can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. ©(a && b)© becomes ©(a != 0 && b != 0)©).
    21322134
    2133 In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any
    2134 arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a
    2135 special case.
    2136 However, user-defined arithmetic types often need the equivalent of a 1 or 0 for their
    2137 functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their
    2138 polymorphic parameters, and user-defined pointer-like types may need a null value.
    2139 Defining special
    2140 constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
     2135In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a special case.
     2136However, user-defined arithmetic types often need the equivalent of a 1 or 0 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
     2137Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
    21412138
    21422139Why just 0 and 1? Why not other integers? No other integers have special status in C.
     
    23162313\begin{quote2}
    23172314\begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
    2318 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{©gcc©}\index{gcc} \\
     2315\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{Indexc{gcc}} \\
    23192316\begin{lstlisting}
    23202317
     
    23482345
    23492346In \CFA, ©typedef© provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
    2350 ©gcc© provides ©typeof© to declare a secondary variable from a primary variable.
     2347\Indexc{gcc} provides ©typeof© to declare a secondary variable from a primary variable.
    23512348\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.
    23522349Only for overloaded routines with the same return type is variable type-inferencing possible.
     
    23782375Generics allow programmers to use type variables in place of concrete types so that the code can be reused with multiple types.
    23792376The type parameters can be restricted to satisfy a set of constraints.
    2380 This enables \CFA to build fully compiled generic functions and types, unlike other languages like \CC where templates are expanded or must be explicitly instantiated.
     2377This enables \CFA to build fully compiled generic functions and types, unlike other languages like \Index*[C++]{\CC} where templates are expanded or must be explicitly instantiated.
    23812378
    23822379
    23832380\subsection{Generic Functions}
    23842381
    2385 Generic functions in \CFA are similar to template functions in \CC, and will sometimes be expanded into specialized versions, just like in \CC.
     2382Generic functions in \CFA are similar to template functions in \Index*[C++]{\CC}, and will sometimes be expanded into specialized versions, just like in \CC.
    23862383The 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.
    23872384This means that compiled libraries can contain generic functions that can be used by programs linked with them (statically or dynamically).
     
    25022499
    25032500Generic types are defined using the same mechanisms as those described above for generic functions.
    2504 This 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.
     2501This feature allows users to create types that have one or more fields that use generic parameters as types, similar to a template classes in \Index*[C++]{\CC}.
    25052502For 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.
    25062503In C, something like this would have to be done using void pointers and unsafe casting.
     
    25542551Throwing 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.
    25552552The exception is immediately re-thrown from the parent block unless it is caught as described below.
    2556 \CFA uses keywords similar to \CC for exception handling.
     2553\CFA uses keywords similar to \Index*[C++]{\CC} for exception handling.
    25572554An exception is thrown using a throw statement, which accepts one argument.
    25582555
     
    26822679\end{lstlisting}
    26832680While this sytact is awkward, it is unlikely many programers will name fields of a structure 0 or 1.
    2684 Like the \CC lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
     2681Like the \Index*[C++]{\CC} lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
    26852682
    26862683There are several ambiguous cases with operator identifiers, e.g., ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
     
    27192716This enables a very familiar interface to all programmers, even those with no parallel programming experience.
    27202717It also allows the compiler to do static type checking of all communication, a very important safety feature.
    2721 This controlled communication with type safety has some similarities with channels in Go, and can actually implement
     2718This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement
    27222719channels exactly, as well as create additional communication patterns that channels cannot.
    27232720Mutex objects, monitors, are used to contain mutual exclusion within an object and synchronization across concurrent threads.
     
    29722969
    29732970There are two levels of encapsulation in \CFA, module and package.
    2974 A 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.
     2971A module is a logical grouping of functionality that can be easily pulled into another project, much like a module in \Index*{Python} or a package in \Index*{Go}.
    29752972A module forms a namespace to limit the visibility and prevent naming conflicts of variables.
    29762973Furthermore, a module is an independent translation unit, which can be compiled separately to accelerate the compilation speed.
     
    29782975A package is a physical grouping of one or more modules that is used for code distribution and version management.
    29792976Package is also the level of granularity at which dependences are managed.
    2980 A package is similar to the Crate in Rust.
     2977A package is similar to the Crate in \Index*{Rust}.
    29812978
    29822979
    29832980\subsection{No Declarations, No Header Files}
    29842981
    2985 In C and \CC, it is necessary to declare or define every global variable, global function, and type before it is used in each file.
     2982In C and \Index*[C++]{\CC}, it is necessary to declare or define every global variable, global function, and type before it is used in each file.
    29862983Header files and a preprocessor are normally used to avoid repeating code.
    29872984Thus, many variables, functions, and types are described twice, which exposes an opportunity for errors and causes additional maintenance work.
     
    29892986This 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.
    29902987In 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.
    2991 This 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.
     2988This seems like a minor change, but according to (Pike, \Index*{Go} at Google: Language Design in the Service of Software Engineering), this simple change can cause massive reductions in compile time.
    29922989
    29932990In \CFA, multiple definitions are not necessary.
     
    36283625In developing \CFA, many other languages were consulted for ideas, constructs, and syntax.
    36293626Therefore, it is important to show how these languages each compare with Do.
    3630 In 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.
     3627In this section, \CFA is compared with what the writers of this document consider to be the closest competitors of Do: \Index*[C++]{\CC}, \Index*{Go}, \Index*{Rust}, and \Index*{D}.
    36313628
    36323629
     
    36343631
    36353632
     3633{% local change to lstlising to reduce font size
     3634
     3635
     3636\lstset{basicstyle=\linespread{0.9}\sf\relsize{-2}}
     3637
     3638
    36363639\subsubsection{Constructors and Destructors}
    3637 
    3638 \lstset{basicstyle=\sf\relsize{-2}}
    36393640
    36403641\begin{flushleft}
     
    42414242\end{flushleft}
    42424243
    4243 \lstset{basicstyle=\sf\relsize{-1}}
     4244}% local change to lstlising to reduce font size
    42444245
    42454246
     
    42494250\subsubsection[C++]{\CC}
    42504251
    4251 \CC is a general-purpose programming language.
     4252\Index*[C++]{\CC} is a general-purpose programming language.
    42524253It has imperative, object-oriented and generic programming features, while also providing facilities for low-level memory manipulation. (Wikipedia)
    42534254
     
    42574258Classes in \CC also enable inheritance among types.
    42584259Instead of inheritance, \CFA embraces composition and interfaces to achieve the same goals with more flexibility.
    4259 There 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).
     4260There are many studies and articles comparing inheritance and composition (or is-a versus has-a relationships), so we will not go into more detail here (Venners, 1998) (Pike, \Index*{Go} at Google: Language Design in the Service of Software Engineering , 2012).
    42604261
    42614262Overloading 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.
     
    42704271\subsubsection{Go}
    42714272
    4272 Go, also commonly referred to as golang, is a programming language developed at Google in 2007 [.].
     4273\Index*{Go}, also commonly referred to as golang, is a programming language developed at Google in 2007 [.].
    42734274It is a statically typed language with syntax loosely derived from that of C, adding garbage collection, type
    42744275safety, some structural typing capabilities, additional built-in types such as variable-length arrays and key-value maps, and a large standard library. (Wikipedia)
     
    42864287\subsubsection{Rust}
    42874288
    4288 Rust is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.
     4289\Index*{Rust} is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.
    42894290It is designed to be a "safe, concurrent, practical language", supporting pure-functional, concurrent-actor[dubious . discuss][citation needed], imperative-procedural, and object-oriented styles.
    42904291
     
    43004301\subsubsection{D}
    43014302
    4302 The D programming language is an object-oriented, imperative, multi-paradigm system programming
     4303The \Index*{D} programming language is an object-oriented, imperative, multi-paradigm system programming
    43034304language created by Walter Bright of Digital Mars and released in 2001. [.]
    4304 Though 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.
     4305Though it originated as a re-engineering of \CC, D is a distinct language, having redesigned some core \CC features while also taking inspiration from other languages, notably \Index*{Java}, \Index*{Python}, Ruby, C\#, and Eiffel.
    43054306
    43064307D and \CFA both start with C and add productivity features.
     
    44424443\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
    44434444
    4444 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
     4445\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
    44454446Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
    44464447Given 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.
     
    44784479\index{input/output library}
    44794480
    4480 The 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.
    4481 The general case is printing out a sequence of variables separated by whitespace.
     4481The goal for the \CFA I/O is to make I/O as simple as possible in the common cases, while fully supporting polmorphism and user defined types in a consistent way.
     4482The common case is printing out a sequence of variables separated by whitespace.
    44824483\begin{quote2}
    44834484\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     
    44944495\end{tabular}
    44954496\end{quote2}
    4496 The \CFA form is half as many characters, and is similar to \Index{Python} I/O with respect to implicit separators.
     4497The \CFA form has half as many characters as the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators.
    44974498
    44984499The logical-or operator is used because it is the lowest-priority overloadable operator, other than assignment.
     
    46464647\subsection{malloc}
    46474648
    4648 \begin{lstlisting}
     4649\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    46494650forall( otype T ) T * malloc( void );§\indexc{malloc}§
    46504651forall( otype T ) T * malloc( char fill );
     
    46624663forall( otype T ) T * memset( T * ptr );                                // remove when default value available
    46634664\end{lstlisting}
    4664 
     4665\
    46654666
    46664667\subsection{ato / strto}
    46674668
    4668 \begin{lstlisting}
     4669\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    46694670int ato( const char * ptr );§\indexc{ato}§
    46704671unsigned int ato( const char * ptr );
     
    46934694long double _Complex strto( const char * sptr, char ** eptr );
    46944695\end{lstlisting}
     4696\
    46954697
    46964698
    46974699\subsection{bsearch / qsort}
    46984700
    4699 \begin{lstlisting}
     4701\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47004702forall( otype T | { int ?<?( T, T ); } )
    47014703T * bsearch( const T key, const T * arr, size_t dimension );§\indexc{bsearch}§
     
    47044706void qsort( const T * arr, size_t dimension );§\indexc{qsort}§
    47054707\end{lstlisting}
     4708\
    47064709
    47074710
    47084711\subsection{abs}
    47094712
    4710 \begin{lstlisting}
     4713\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47114714char abs( char );§\indexc{abs}§
    47124715int abs( int );
     
    47204723long double abs( long double _Complex );
    47214724\end{lstlisting}
     4725\
    47224726
    47234727
    47244728\subsection{random}
    47254729
    4726 \begin{lstlisting}
     4730\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47274731void rand48seed( long int s );§\indexc{rand48seed}§
    47284732char rand48();§\indexc{rand48}§
     
    47374741long double _Complex rand48();
    47384742\end{lstlisting}
     4743\
    47394744
    47404745
    47414746\subsection{min / max / swap}
    47424747
    4743 \begin{lstlisting}
     4748\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47444749forall( otype T | { int ?<?( T, T ); } )
    47454750T min( const T t1, const T t2 );§\indexc{min}§
     
    47514756void swap( T * t1, T * t2 );§\indexc{swap}§
    47524757\end{lstlisting}
     4758\
    47534759
    47544760
     
    47614767\subsection{General}
    47624768
    4763 \begin{lstlisting}
     4769\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47644770float fabs( float );§\indexc{fabs}§
    47654771double fabs( double );
     
    48064812long double nan( const char * );
    48074813\end{lstlisting}
     4814\
    48084815
    48094816
    48104817\subsection{Exponential}
    48114818
    4812 \begin{lstlisting}
     4819\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48134820float exp( float );§\indexc{exp}§
    48144821double exp( double );
     
    48624869long double logb( long double );
    48634870\end{lstlisting}
     4871\
    48644872
    48654873
    48664874\subsection{Power}
    48674875
    4868 \begin{lstlisting}
     4876\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48694877float sqrt( float );§\indexc{sqrt}§
    48704878double sqrt( double );
     
    48894897long double _Complex pow( long double _Complex, long double _Complex );
    48904898\end{lstlisting}
     4899\
    48914900
    48924901
    48934902\subsection{Trigonometric}
    48944903
    4895 \begin{lstlisting}
     4904\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48964905float sin( float );§\indexc{sin}§
    48974906double sin( double );
     
    49444953long double atan( long double, long double );
    49454954\end{lstlisting}
     4955\
    49464956
    49474957
    49484958\subsection{Hyperbolic}
    49494959
    4950 \begin{lstlisting}
     4960\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    49514961float sinh( float );§\indexc{sinh}§
    49524962double sinh( double );
     
    49915001long double _Complex atanh( long double _Complex );
    49925002\end{lstlisting}
     5003\
    49935004
    49945005
    49955006\subsection{Error / Gamma}
    49965007
    4997 \begin{lstlisting}
     5008\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    49985009float erf( float );§\indexc{erf}§
    49995010double erf( double );
     
    50215032long double tgamma( long double );
    50225033\end{lstlisting}
     5034\
    50235035
    50245036
    50255037\subsection{Nearest Integer}
    50265038
    5027 \begin{lstlisting}
     5039\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    50285040float floor( float );§\indexc{floor}§
    50295041double floor( double );
     
    50745086long long int llround( long double );
    50755087\end{lstlisting}
     5088\
    50765089
    50775090
    50785091\subsection{Manipulation}
    50795092
    5080 \begin{lstlisting}
     5093\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    50815094float copysign( float, float );§\indexc{copysign}§
    50825095double copysign( double, double );
     
    51145127long double scalbln( long double, long int );
    51155128\end{lstlisting}
     5129\
    51165130
    51175131
     
    51225136When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
    51235137
    5124 \begin{lstlisting}
     5138\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    51255139// implementation
    51265140struct Rational {§\indexc{Rational}§
Note: See TracChangeset for help on using the changeset viewer.