Changeset cc7bbe6 for doc/user/user.tex

Timestamp:

Feb 23, 2022, 11:24:34 AM (4 years ago)

Author:

Michael Brooks <mlbrooks@…>

Branches:

ADT, ast-experimental, enum, master, pthread-emulation, qualifiedEnum

Children:

08ed947

Parents:

f5a51db (diff), 3a038fa (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:

• doc/user/user.tex (modified) (50 diffs)

doc/user/user.tex

@@ -11 +11 @@
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
-%% Last Modified On : Sun Oct 10 12:45:00 2021
-%% Update Count     : 5095
+%% Last Modified On : Mon Feb 14 17:20:39 2022
+%% Update Count     : 5382
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 % requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
 
-\documentclass[twoside,11pt]{article}
+\documentclass[twoside]{article}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -40 +40 @@
 % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
 % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
-% LaTex escape §...§ (section symbol) emacs: C-q M-'
+% LaTex escape ...§ (section symbol) emacs: C-q M-'
 % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
 % math escape $...$ (dollar symbol)
@@ -85 +85 @@
 \newcommand{\B}[1]{{\Textbf[blue]{#1}}}
 \newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
+\newcommand{\Sp}{\R{\textvisiblespace}}
 \newcommand{\KWC}{K-W C\xspace}
 
@@ -156 +157 @@
 One of the main design philosophies of \CFA is to ``\Index{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''.
 Programmers can cautiously add \CFA extensions to their C programs in any order and at any time to incrementally move towards safer, higher-level programming.
-A programmer is always free to reach back to C from \CFA, for any reason, and in many cases, new \CFA features can be locally switched back to there C counterpart.
-There is no notion or requirement for \emph{rewriting} a legacy C program in \CFA;
+A programmer is always free to reach back to C from \CFA, for any reason, and in many cases, new \CFA features can be locally switched back to their C counterpart.
+There is no notion or requirement for \emph{rewriting} a legacy C program to \CFA;
 instead, a programmer evolves a legacy program into \CFA by incrementally incorporating \CFA features.
 As well, new programs can be written in \CFA using a combination of C and \CFA features.
@@ -163 +164 @@
 
 \Index*[C++]{\CC{}}~\cite{c++:v1} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
-However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
+However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that are difficult to update, and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
 In contrast, \CFA has 30 years of hindsight and a clean starting point.
 
 Like \Index*[C++]{\CC{}}, there may be both old and new ways to achieve the same effect.
 For example, the following programs compare the C, \CFA, and \CC I/O mechanisms, where the programs output the same result.
-\begin{center}
+\begin{flushleft}
 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
-\multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}}   & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
-\begin{cfa}
+\multicolumn{1}{@{}c@{\hspace{1em}}}{\textbf{C}}        & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c@{}}{\textbf{\CC}}   \\
+\begin{cfa}[tabsize=3]
 #include <stdio.h>$\indexc{stdio.h}$
 
@@ -180 +181 @@
 \end{cfa}
 &
-\begin{cfa}
+\begin{cfa}[tabsize=3]
 #include <fstream>$\indexc{fstream}$
 
@@ -189 +190 @@
 \end{cfa}
 &
-\begin{cfa}
+\begin{cfa}[tabsize=3]
 #include <iostream>$\indexc{iostream}$
 using namespace std;
 int main() {
         int x = 0, y = 1, z = 2;
-        ®cout<<x<<" "<<y<<" "<<z<<endl;®
+        ®cout << x << ' ' << y << ' ' << z << endl;®
 }
 \end{cfa}
 \end{tabular}
-\end{center}
+\end{flushleft}
 While \CFA I/O \see{\VRef{s:StreamIOLibrary}} looks similar to \Index*[C++]{\CC{}}, there are important differences, such as automatic spacing between variables and an implicit newline at the end of the expression list, similar to \Index*{Python}~\cite{Python}.
 
@@ -238 +239 @@
 however, it largely extended the C language, and did not address many of C's existing problems.\footnote{%
 Two 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.}
-\Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language-features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
+\Index*{Fortran}~\cite{Fortran08}, \Index*{Cobol}~\cite{Cobol14}, and \Index*{Ada}~\cite{Ada12} are examples of programming languages that took an evolutionary approach, where modern language-features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
 \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.
 These languages have different syntax and semantics from C, do not interoperate directly with C, and are not systems languages because of restrictive memory-management or garbage collection.
@@ -333 +334 @@
 long double _Complex ®abs®( long double _Complex );
 \end{cfa}
-The problem is \Index{name clash} between the C name ©abs© and the \CFA names ©abs©, resulting in two name linkages\index{C linkage}: ©extern "C"© and ©extern "Cforall"© (default).
+The problem is a \Index{name clash} between the C name ©abs© and the \CFA names ©abs©, resulting in two name linkages\index{C linkage}: ©extern "C"© and ©extern "Cforall"© (default).
 Overloaded names must use \newterm{name mangling}\index{mangling!name} to create unique names that are different from unmangled C names.
 Hence, 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.
@@ -377 +378 @@
 The program is linked with the debugging version of the runtime system.
 The debug version performs runtime checks to aid the debugging phase of a \CFA program, but can substantially slow program execution.
-The runtime checks should only be removed after the program is completely debugged.
+The runtime checks should only be removed after a program is completely debugged.
 \textbf{This option is the default.}
 
@@ -452 +453 @@
 cfa $test$.cfa -XCFA -P -XCFA parse -XCFA -n # show program parse without prelude
 \end{lstlisting}
+Alternatively, multiple flages can be specified separated with commas and \emph{without} spaces.
+\begin{lstlisting}[language=sh,{moredelim=**[is][\protect\color{red}]{®}{®}}]
+cfa $test$.cfa -XCFA®,®-Pparse®,®-n # show program parse without prelude
+\end{lstlisting}
 \begin{description}[topsep=5pt,itemsep=0pt,parsep=0pt]
 \item
@@ -533 +538 @@
 double ®``®forall = 3.5;
 \end{cfa}
-
-Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
+Existing C programs with keyword clashes can be converted by prefixing the keyword identifiers with double backquotes, and eventually the identifier name can be changed to a non-keyword name.
 \VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files \see{\VRef{s:StandardHeaders}} can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
 Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
@@ -627 +631 @@
 \subsection{\texorpdfstring{\LstKeywordStyle{if} / \LstKeywordStyle{while} Statement}{if / while Statement}}
 
-The ©if©/©while© expression allows declarations, similar to ©for© declaration expression.\footnote{
-Declarations in the ©do©-©while© condition are not useful because they appear after the loop body.}
+The \Indexc{if}/\Indexc{while} expression allows declarations, similar to \Indexc{for} declaration expression.\footnote{
+Declarations in the \Indexc{do}-©while© condition are not useful because they appear after the loop body.}
 \begin{cfa}
 if ( ®int x = f()® ) ... $\C{// x != 0}$
@@ -640 +644 @@
 while ( ®struct S { int i; } x = { f() }; x.i < 4® ) ... $\C{// relational expression}$
 \end{cfa}
-Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if©/©while© expression, and the results are combined using the logical ©&&© operator.
-The scope of the declaration(s) is local to the ©if© statement but exist within both the \emph{then} and \emph{else} clauses.
+Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if©/©while© expression, and the results are combined using the logical \Indexc{&&} operator.
+The scope of the declaration(s) is local to the ©if©/©while© statement, \ie in both \emph{then} and \emph{else} clauses for ©if©, and loop body for ©while©.
 \CC only provides a single declaration always compared ©!=© to 0.
 
@@ -649 +653 @@
 \label{s:caseClause}
 
-C restricts the ©case© clause of a ©switch© statement to a single value.
+C restricts the \Indexc{case} clause of a \Indexc{switch} statement to a single value.
 For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
-Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
-Therefore, the ©case© clause is extended with a list of values, as in:
+Requiring a ©case© clause for each value is not in the spirit of brevity normally associated with C.
+Therefore, the ©case© clause is extended with a list of values.
 \begin{cquote}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
@@ -703 +707 @@
 \subsection{\texorpdfstring{\LstKeywordStyle{switch} Statement}{switch Statement}}
 
-C allows a number of questionable forms for the ©switch© statement:
+C allows a number of questionable forms for the \Indexc{switch} statement:
 \begin{enumerate}
 \item
-By default, the end of a ©case© clause\footnote{
+By default, the end of a \Indexc{case} clause\footnote{
 In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
 \emph{falls through} to the next ©case© clause in the ©switch© statement;
-to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
+to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly \Indexc{break}:
 \begin{cfa}
 switch ( i ) {
   case 1:
         ...
-        // fall-through
+        $\R{\LstCommentStyle{// fall-through}}$
   case 2:
         ...
-        break;  // exit switch statement
+        ®break;®        // exit switch statement
 }
 \end{cfa}
@@ -763 +767 @@
 }
 \end{cfa}
-This situation better handled without fall-through by allowing a list of case values \see{\VRef{s:caseClause}}.
+This situation is better handled by a list of case values \see{\VRef{s:caseClause}}.
 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from most programming languages with a ©switch© statement.
 Hence, default fall-through semantics results in a large number of programming errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
@@ -777 +781 @@
                 ...
         } // if
-  case 2:
-        while ( j < 5 ) {
-                ...
-          ®case 3:®             // transfer into "while" statement
-                ...
-        } // while
-} // switch
 \end{cfa}
 This usage branches into control structures, which is known to cause both comprehension and technical difficulties.
@@ -789 +786 @@
 The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
 There are few arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
-Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
+
+This C idiom is known as ``\Index*{Duff's device}''~\cite{Duff83}, from this example:
 \begin{cfa}
 register int n = (count + 7) / 8;
@@ -858 +856 @@
 still works.
 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
-Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
+Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called \Indexc{choose}, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword \Indexc{fallthrough}/\Indexc{fallthru}, \eg:
 \begin{cfa}
 ®choose® ( i ) {
@@ -885 +883 @@
 Therefore, no change is made for this issue.
 \item
-Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
+Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
 Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
@@ -908 +906 @@
 \subsection{Non-terminating and Labelled \texorpdfstring{\LstKeywordStyle{fallthrough}}{Non-terminating and Labelled fallthrough}}
 
-The ©fallthrough© clause may be non-terminating within a ©case© clause or have a target label to common code from multiple case clauses.
+The \Indexc{fallthrough} clause may be non-terminating within a \Indexc{case} clause or have a target label to common code from multiple case clauses.
 \begin{center}
 \begin{tabular}{@{}lll@{}}
@@ -960 +958 @@
 \end{tabular}
 \end{center}
-The target label must be below the ©fallthrough© and may not be nested in a control structure, and
-the target label must be at the same or higher level as the containing ©case© clause and located at
-the same level as a ©case© clause; the target label may be case ©default©, but only associated
-with the current ©switch©/©choose© statement.
+The target label must be below the \Indexc{fallthrough} and may not be nested in a control structure, and
+the target label must be at the same or higher level as the containing \Indexc{case} clause and located at
+the same level as a ©case© clause; the target label may be case \Indexc{default}, but only associated
+with the current \Indexc{switch}/\Indexc{choose} statement.
 
 \begin{figure}
@@ -1076 +1074 @@
 Looping a fixed number of times, possibly with a loop index, occurs frequently.
 \CFA condenses simply looping to facilitate coding speed and safety.
-The ©for©/©while©/©do-while© loop-control is augmented as follows \see{examples in \VRef[Figure]{f:LoopControlExamples}}:
+The \Indexc{for}, \Indexc{while}, and \Indexc{do} loop-control is augmented as follows \see{examples in \VRef[Figure]{f:LoopControlExamples}}:
 \begin{itemize}[itemsep=0pt]
 \item
@@ -1145 +1143 @@
 \subsection{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break} Statement}{Labelled continue / break Statement}}
 
-C ©continue© and ©break© statements, for altering control flow, are restricted to one level of nesting for a particular control structure.
+C \Indexc{continue} and \Indexc{break} statements, for altering control flow, are restricted to one level of nesting for a particular control structure.
 This restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
 To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@©continue©!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@©break©!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85}, as in Java.
-For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
-for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
+For both ©continue© and ©break©, the target label must be directly associated with a \Indexc{for}, \Indexc{while} or \Indexc{do} statement;
+for ©break©, the target label can also be associated with a \Indexc{switch}, \Indexc{if} or compound (©{}©) statement.
 \VRef[Figure]{f:MultiLevelExit} shows a comparison between labelled ©continue© and ©break© and the corresponding C equivalent using ©goto© and labels.
 The innermost loop has 8 exit points, which cause continuation or termination of one or more of the 7 \Index{nested control-structure}s.
@@ -1224 +1222 @@
 \end{figure}
 
-Both labelled ©continue© and ©break© are a ©goto©\index{goto@©goto©!restricted} restricted in the following ways:
+Both labelled \Indexc{continue} and \Indexc{break} are a \Indexc{goto}\index{goto@©goto©!restricted} restricted in the following ways:
 \begin{itemize}
 \item
@@ -1240 +1238 @@
 
 
+\subsection{\texorpdfstring{Extended \LstKeywordStyle{else}}{Extended else}}
+\label{s:ExtendedElse}
+\index{extended ©else©}
+
+The ©if© statement has an optional ©else© clause executed if the conditional is false.
+This concept is extended to the \Indexc{while}, \Indexc{for}, and \Indexc{do} looping constructs (like Python).
+Hence, if the loop conditional becomes false, looping stops and the corresponding ©else© clause is executed, if present.
+
+The following example is a linear search for the key 3 in an array, where finding the key is handled with a ©break© and not finding with the ©else© clause on the loop construct.
+\begin{cquote}
+\begin{cfa}
+int a[10];
+\end{cfa}
+\begin{tabular}{@{}lll@{}}
+\begin{cfa}
+
+while ( int i = 0; i < 10 ) {
+  if ( a[i] == 3 ) break; // found
+        i += 1;
+} ®else® { // i == 10
+        sout | "not found";
+}
+\end{cfa}
+&
+\begin{cfa}
+
+for ( i; 10 ) {
+  if ( a[i] == 3 ) break; // found
+
+} ®else® { // i == 10
+        sout | "not found";
+}
+\end{cfa}
+&
+\begin{cfa}
+int i = 0;
+do {
+  if ( a[i] == 3 ) break; // found
+        i += 1;
+} while( i < 10 ) ®else® { // i == 10
+        sout | "not found";
+}
+\end{cfa}
+\end{tabular}
+\end{cquote}
+Note, \Index{dangling else} now occurs with \Indexc{if}, \Indexc{while}, \Indexc{for}, \Indexc{do}, and \Indexc{waitfor}.
+
+
 %\subsection{\texorpdfstring{\protect\lstinline{with} Statement}{with Statement}}
 \subsection{\texorpdfstring{\LstKeywordStyle{with} Statement}{with Statement}}
@@ -1266 +1312 @@
 Therefore, reducing aggregate qualification is a useful language design goal.
 
-C allows unnamed nested aggregates that open their scope into the containing aggregate.
+C partially addresses the problem by eliminating qualification for enumerated types and unnamed \emph{nested} aggregates, which open their scope into the containing aggregate.
 This feature is used to group fields for attributes and/or with ©union© aggregates.
 \begin{cfa}
 struct S {
-        struct { int g,  h; } __attribute__(( aligned(64) ));
+        struct $\R{\LstCommentStyle{/* unnamed */}}$ { int g,  h; } __attribute__(( aligned(64) ));
         int tag;
-        union {
+        union $\R{\LstCommentStyle{/* unnamed */}}$ {
                 struct { char c1,  c2; } __attribute__(( aligned(128) ));
                 struct { int i1,  i2; };
                 struct { double d1,  d2; };
         };
-};
-s.g; s.h; s.tag; s.c1; s.c2; s.i1; s.i2; s.d1; s.d2;
+} s;
+enum { R, G, B };
+s.g; s.h;   s.tag = R;   s.c1; s.c2;   s.i1 = G; s.i2 = B;   s.d1; s.d2;
 \end{cfa}
 
@@ -1323 +1370 @@
 \end{cfa}
 where qualification is only necessary to disambiguate the shadowed variable ©i©.
-
-In detail, the ©with© statement may appear as the body of a function or nested within a function body.
+In detail, the ©with© statement may form a function body or be nested within a function body.
+
 The ©with© clause takes a list of expressions, where each expression provides an aggregate type and object.
 (Enumerations are already opened.)
@@ -1333 +1380 @@
 \end{cfa}
 The expression object is the implicit qualifier for the open structure-fields.
+
 \CFA's ability to overload variables \see{\VRef{s:VariableOverload}} and use the left-side of assignment in type resolution means most fields with the same name but different types are automatically disambiguated, eliminating qualification.
 All expressions in the expression list are open in parallel within the compound statement.
@@ -1362 +1410 @@
 \end{cfa}
 A cast or qualification can be used to disambiguate variables within a ©with© \emph{statement}.
-A cast can be used to disambiguate among overload variables in a ©with© \emph{expression}:
+A cast can also be used to disambiguate among overload variables in a ©with© \emph{expression}:
 \begin{cfa}
 with ( w ) { ... }                                                      $\C{// ambiguous, same name and no context}$
@@ -1371 +1419 @@
 Finally, there is an interesting problem between parameters and the function-body ©with©, \eg:
 \begin{cfa}
-void ?{}( S & s, int i ) with ( s ) { $\C{// constructor}$
-        ®s.i = i;®  j = 3;  m = 5.5; $\C{// initialize fields}$
-}
-\end{cfa}
-Here, the assignment ©s.i = i© means ©s.i = s.i©, which is meaningless, and there is no mechanism to qualify the parameter ©i©, making the assignment impossible using the function-body ©with©.
-To solve this problem, parameters are treated like an initialized aggregate:
-\begin{cfa}
-struct Params {
-        S & s;
-        int i;
+void f( S & s, char c ) with ( s ) {
+        ®s.c = c;®  i = 3;  d = 5.5;                    $\C{// initialize fields}$
+}
+\end{cfa}
+Here, the assignment ©s.c = c© means ©s.c = s.c©, which is meaningless, and there is no mechanism to qualify the parameter ©c©, making the assignment impossible using the function-body ©with©.
+To solve this problem, parameters \emph{not} explicitly opened are treated like an initialized aggregate:
+\begin{cfa}
+struct Params {                                                         $\C{// s explicitly opened so S \& s elided}$
+        char c;
 } params;
 \end{cfa}
 and implicitly opened \emph{after} a function-body open, to give them higher priority:
 \begin{cfa}
-void ?{}( S & s, int ®i® ) with ( s ) ®with( $\emph{\R{params}}$ )® { // syntax not allowed, illustration only
-        s.i = ®i®; j = 3; m = 5.5;
+void f( S & s, char ®c® ) with ( s ) ®with( $\emph{\R{params}}$ )® { // syntax not allowed, illustration only
+        s.c = ®c;®  i = 3;  d = 5.5;
 }
 \end{cfa}
 This implicit semantic matches with programmer expectation.
-
 
 
@@ -3397 +3443 @@
 This requirement is the same as for comma expressions in argument lists.
 
-Type qualifiers, \ie const and volatile, may modify a tuple type.
-The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], \ie the qualifier is distributed across all of the types in the tuple, \eg:
+Type qualifiers, \ie ©const© and ©volatile©, may modify a tuple type.
+The meaning is to distribute the qualifier across all of the types in the tuple, \eg:
 \begin{cfa}
 const volatile [ int, float, const int ] x;
@@ -3597 +3643 @@
 Stream ©exit© implicitly returns ©EXIT_FAILURE© to the shell.
 \begin{cfa}
-®exit®   | "x (" | x | ") negative value."; // terminate and return EXIT_FAILURE to shell
-®abort® | "x (" | x | ") negative value."; // terminate and generate stack trace and core file
+®exit®   | "x (" | x | ") negative value.";   // terminate and return EXIT_FAILURE to shell
+®abort® | "x (" | x | ") negative value.";   // terminate and generate stack trace and core file
 \end{cfa}
 Note, \CFA stream variables ©stdin©, ©stdout©, ©stderr©, ©exit©, and ©abort© overload C variables ©stdin©, ©stdout©, ©stderr©, and functions ©exit© and ©abort©, respectively.
@@ -4267 +4313 @@
         sout | '1' | '2' | '3';
         sout | 1 | "" | 2 | "" | 3;
-        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
-                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10;
+        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
+                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10;
         sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
-                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x";
+                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x";
         sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx";
         sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4;
@@ -4446 +4492 @@
 The common usage is the short form of the mutex statement\index{ostream@©ostream©!mutex@©mutex©} to lock a stream during a single cascaded I/O expression, \eg:
 \begin{cfa}
-$\emph{thread\(_1\)}$ : ®mutex()® sout | "abc " | "def ";
-$\emph{thread\(_2\)}$ : ®mutex()® sout | "uvw " | "xyz ";
+$\emph{thread\(_1\)}$ : ®mutex( sout )® sout | "abc " | "def ";
+$\emph{thread\(_2\)}$ : ®mutex( sout )® sout | "uvw " | "xyz ";
 \end{cfa}
 Now, the order of the thread execution is still non-deterministic, but the output is constrained to two possible lines in either order.
@@ -4470 +4516 @@
 ®mutex( sout )® {
         sout | 1;
-        ®mutex() sout® | 2 | 3;                         $\C{// unnecessary, but ok because of recursive lock}$
+        ®mutex( sout ) sout® | 2 | 3;                           $\C{// unnecessary, but ok because of recursive lock}$
         sout | 4;
 } // implicitly release sout lock
@@ -4482 +4528 @@
         int x, y, z, w;
         sin | x;
-        ®mutex() sin® | y | z;                          $\C{// unnecessary, but ok because of recursive lock}$
+        ®mutex( sin )® sin | y | z;                                     $\C{// unnecessary, but ok because of recursive lock}$
         sin | w;
 } // implicitly release sin lock
@@ -4491 +4537 @@
 \Textbf{WARNING:} The general problem of \Index{nested locking} can occur if routines are called in an I/O sequence that block, \eg:
 \begin{cfa}
-®mutex() sout® | "data:" | rtn( mon );  $\C{// mutex call on monitor}$
+®mutex( sout )® sout | "data:" | rtn( mon );    $\C{// mutex call on monitor}$
 \end{cfa}
 If the thread executing the I/O expression blocks in the monitor with the ©sout© lock, other threads writing to ©sout© also block until the thread holding the lock is unblocked and releases it.
@@ -4498 +4544 @@
 \begin{cfa}
 int ®data® = rtn( mon );
-mutex() sout | "data:" | ®data®;
-\end{cfa}
+mutex( sout ) sout | "data:" | ®data®;
+\end{cfa}
+
+
+\subsection{Locale}
+\index{stream!locale}
+\index{locale!stream}
+
+Cultures use different syntax, called a \newterm{locale}, for printing numbers so they are easier to read, \eg:
+\begin{cfa}
+12®,®345®.®123          $\C[1.25in]{// comma separator, period decimal-point}$
+12®.®345®,®123          $\C{// period separator, comma decimal-point}$
+12$\Sp$345®,®123®.®     $\C{// space separator, comma decimal-point, period terminator}\CRT$
+\end{cfa}
+A locale is selected with function ©setlocale©, and the corresponding locale package \emph{must} be installed on the underlying system;
+©setlocale© returns ©0p© if the requested locale is unavailable.
+Furthermore, a locale covers the syntax for many cultural items, \eg address, measurement, money, etc.
+This discussion applies to item ©LC_NUMERIC© for formatting non-monetary integral and floating-point values.
+\VRef[Figure]{f:StreamLocale} shows selecting different cultural syntax, which may be associated with one or more countries.
+
+\begin{figure}
+\begin{cfa}
+#include <fstream.hfa>
+#include <locale.h>                                                     $\C{// setlocale}$
+#include <stdlib.h>                                                     $\C{// getenv}$
+
+int main() {
+        void print() {
+                sout | 12 | 123 | 1234 | 12345 | 123456 | 1234567;
+                sout | 12. | 123.1 | 1234.12 | 12345.123 | 123456.1234 | 1234567.12345;
+                sout | nl;
+        }
+        sout | "Default locale off";
+        print();
+        sout | "Locale on" | ®setlocale( LC_NUMERIC, getenv( "LANG" ) )®;  // enable local locale
+        print();
+        sout | "German" | ®setlocale( LC_NUMERIC, "de_DE.UTF-8" )®;  // enable German locale
+        print();
+        sout | "Ukraine" | ®setlocale( LC_NUMERIC, "uk_UA.utf8" )®;  // enable Ukraine locale
+        print();
+        sout | "Default locale off" | ®setlocale( LC_NUMERIC, "C" )®;  // disable locale
+        print();
+}
+
+Default locale off
+12 123 1234 12345 123456 1234567
+12. 123.1 1234.12 12345.123 123456.1234 1234567.12345
+
+Locale on en_US.UTF-8
+12 123 1®,®234 12®,®345 123®,®456 1®,®234®,®567
+12®.® 123®.®1 1®,®234®.®12 12®,®345®.®123 123®,®456®.®1234 1®,®234®,®567®.®12345
+
+German de_DE.UTF-8
+12 123 1®.®234 12®.®345 123®.®456 1®.®234®.®567
+12®.® 123®,®1®.® 1®.®234®,®12 12®.®345®,®123 123®.®456®,®1234 1®.®234®.®567®,®12345
+
+Ukraine uk_UA.utf8
+12 123 1 234 12 345 123 456 1 234 567
+12®.® 123®,®1®.® 1$\Sp$234®,®12®.® 12$\Sp$ 345®,®123®.® 123$\Sp$ 456®,®1234®.® 1$\Sp$ 234$\Sp$567®,®12345®.®
+
+Default locale off C
+12 123 1234 12345 123456 1234567
+12. 123.1 1234.12 12345.123 123456.1234 1234567.12345
+\end{cfa}
+\caption{Stream Locale}
+\label{f:StreamLocale}
+\end{figure}
 
 
@@ -4555 +4666 @@
 \end{figure}
 
+
 \begin{comment}
 \section{Types}
@@ -4637 +4749 @@
 
 
-\subsection{Structures}
+\section{Structures}
 
 Structures in \CFA are basically the same as structures in C.
@@ -5270 +5382 @@
 \subsection{Coroutine}
 
-\Index{Coroutines} are the precursor to tasks.
+\Index{Coroutines} are the precursor to threads.
 \VRef[Figure]{f:FibonacciCoroutine} shows a coroutine that computes the \Index*{Fibonacci} numbers.
 
@@ -5372 +5484 @@
 
 
-\subsection{Tasks}
+\subsection{Threads}
 
 \CFA also provides a simple mechanism for creating and utilizing user level threads.
-A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
-Similar to a monitor, a task is defined like a structure:
+A thread provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
+Similar to a monitor, a thread is defined like a structure:
 
 \begin{figure}
@@ -5420 +5532 @@
 }
 \end{cfa}
-\caption{Simple Tasks}
-\label{f:SimpleTasks}
+\caption{Simple Threads}
+\label{f:SimpleThreads}
 \end{figure}
 
@@ -6788 +6900 @@
 In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be interpreted as:
 \begin{cfa}
-*?$\R{\textvisiblespace}$*? $\C{// dereference operator, dereference operator}$
-*$\R{\textvisiblespace}$?*? $\C{// dereference, multiplication operator}$
+*?$\Sp$*? $\C{// dereference operator, dereference operator}$
+*$\Sp$?*? $\C{// dereference, multiplication operator}$
 \end{cfa}
 By default, the first interpretation is selected, which does not yield a meaningful parse.
@@ -6813 +6925 @@
 Therefore, it is necessary to disambiguate these cases with a space:
 \begin{cfa}
-i++$\R{\textvisiblespace}$? i : 0;
-i?$\R{\textvisiblespace}$++i : 0;
+i++$\Sp$? i : 0;
+i?$\Sp$++i : 0;
 \end{cfa}
 
@@ -7430 +7542 @@
 char random( void );$\indexc{random}$
 char random( char u ); $\C{// [0,u)}$
-char random( char l, char u ); $\C{// [l,u)}$
+char random( char l, char u ); $\C{// [l,u]}$
 int random( void );
 int random( int u ); $\C{// [0,u)}$
-int random( int l, int u ); $\C{// [l,u)}$
+int random( int l, int u ); $\C{// [l,u]}$
 unsigned int random( void );
 unsigned int random( unsigned int u ); $\C{// [0,u)}$
-unsigned int random( unsigned int l, unsigned int u ); $\C{// [l,u)}$
+unsigned int random( unsigned int l, unsigned int u ); $\C{// [l,u]}$
 long int random( void );
 long int random( long int u ); $\C{// [0,u)}$
-long int random( long int l, long int u ); $\C{// [l,u)}$
+long int random( long int l, long int u ); $\C{// [l,u]}$
 unsigned long int random( void );
 unsigned long int random( unsigned long int u ); $\C{// [0,u)}$
-unsigned long int random( unsigned long int l, unsigned long int u ); $\C{// [l,u)}$
+unsigned long int random( unsigned long int l, unsigned long int u ); $\C{// [l,u]}$
 float random( void );                                            $\C{// [0.0, 1.0)}$
 double random( void );                                           $\C{// [0.0, 1.0)}$
@@ -8106 +8218 @@
 
 
+\section{Pseudo Random Number Generator}
+\label{s:PRNG}
+
+Random numbers are values generated independently, i.e., new values do not depend on previous values (independent trials), \eg lottery numbers, shuffled cards, dice roll, coin flip.
+While a primary goal of programming is computing values that are \emph{not} random, random values are useful in simulation, cryptography, games, etc.
+A random-number generator is an algorithm that computes independent values.
+If the algorithm uses deterministic computation (a predictable sequence of values), it generates \emph{pseudo} random numbers versus \emph{true} random numbers.
+
+All \newterm{pseudo random-number generators} (\newterm{PRNG}) involve some technique to scramble bits of a value, \eg multiplicative recurrence:
+\begin{cfa}
+rand = 36973 * (rand & 65535) + (rand >> 16); // scramble bits
+\end{cfa}
+Multiplication of large values adds new least-significant bits and drops most-significant bits.
+\begin{quote}
+\begin{tabular}{@{}r|l@{}}
+bits 63--32 (most)      & bits 31--0 (least)    \\
+\hline
+0x0                                     & 0x3e8e36                              \\
+0x5f                            & 0x718c25e1                    \\
+0xad3e                          & 0x7b5f1dbe                    \\
+0xbc3b                          & 0xac69ff19                    \\
+0x1070f                         & 0x2d258dc6                    \\
+\end{tabular}
+\end{quote}
+By dropping bits 63--32, bits 31--0 become scrambled after each multiply.
+The least-significant bits \emph{appear} random but the same bits are always generated given a fixed starting value, called the \newterm{seed} (value 0x3e8e36 above).
+Hence, if a program uses the same seed, the same sequence of pseudo-random values is generated from the PRNG.
+Often the seed is set to another random value like a program's process identifier (©getpid©\index{getpid@©getpid©}) or time when the program is run;
+hence, one random value bootstraps another.
+Finally, a PRNG usually generates a range of large values, \eg ©[0, UINT_MAX]©, which are scaled using the modulus operator, \eg ©prng() % 5© produces random values in the range 0--4.
+
+\CFA provides a sequential PRNG type only accessible by a single thread (not thread-safe) and a set of global and companion thread PRNG functions accessible by multiple threads without contention.
+\begin{itemize}
+\item
+The ©PRNG© type is for sequential programs, like coroutining:
+\begin{cfa}
+struct PRNG { ... }; $\C[3.75in]{// opaque type}$
+void ?{}( PRNG & prng ); $\C{// random seed}$
+void ?{}( PRNG & prng, uint32_t seed ); $\C{// fixed seed}$
+void set_seed( PRNG & prng, uint32_t seed ); $\C{// set seed}$
+uint32_t get_seed( PRNG & prng ); $\C{// get seed}$
+uint32_t prng( PRNG & prng ); $\C{// [0,UINT\_MAX]}$
+uint32_t prng( PRNG & prng, uint32_t u ); $\C{// [0,u)}$
+uint32_t prng( PRNG & prng, uint32_t l, uint32_t u ); $\C{// [l,u]}$
+uint32_t calls( PRNG & prng ); $\C{// number of calls}\CRT$
+\end{cfa}
+A ©PRNG© object is used to randomize behaviour or values during execution, \eg in games, a character makes a random move or an object takes on a random value.
+In this scenario, it is useful to have multiple ©PRNG© objects, \eg one per player or object.
+However, sequential execution is still repeatable given the same starting seeds for all ©PRNG©s. 
+\VRef[Figure]{f:SequentialPRNG} shows an example that creates two sequential ©PRNG©s, sets both to the same seed (1009), and illustrates the three forms for generating random values, where both ©PRNG©s generate the same sequence of values.
+
+\begin{figure}
+\begin{cfa}
+PRNG prng1, prng2;
+®set_seed( prng1, 1009 )®;   ®set_seed( prng2, 1009 )®;
+for ( 10 ) {
+        // Do not cascade prng calls because side-effect functions called in arbitrary order.
+        sout | nlOff | ®prng( prng1 )®;  sout | ®prng( prng1, 5 )®;  sout | ®prng( prng1, 0, 5 )® | '\t';
+        sout | ®prng( prng2 )®;  sout | ®prng( prng2, 5 )®;  sout | ®prng( prng2, 0, 5 )® | nlOn;
+}
+\end{cfa}
+\begin{cquote}
+\begin{tabular}{@{}ll@{}}
+\begin{cfa}
+37301721 2 2
+1681308562 1 3
+290112364 3 2
+1852700364 4 3
+733221210 1 3
+1775396023 2 3
+123981445 2 3
+2062557687 2 0
+283934808 1 0
+672325890 1 3
+\end{cfa}
+&
+\begin{cfa}
+37301721 2 2
+1681308562 1 3
+290112364 3 2
+1852700364 4 3
+733221210 1 3
+1775396023 2 3
+123981445 2 3
+2062557687 2 0
+283934808 1 0
+672325890 1 3
+\end{cfa}
+\end{tabular}
+\end{cquote}
+\caption{Sequential PRNG}
+\label{f:SequentialPRNG}
+\end{figure}
+
+\item
+The PRNG global and companion thread functions are for concurrent programming, such as randomizing execution in short-running programs, \eg ©yield( prng() % 5 )©.
+\begin{cfa}
+void set_seed( uint32_t seed ); $\C[3.75in]{// set global seed}$
+uint32_t get_seed(); $\C{// get global seed}$
+// SLOWER
+uint32_t prng(); $\C{// [0,UINT\_MAX]}$
+uint32_t prng( uint32_t u ); $\C{// [0,u)}$
+uint32_t prng( uint32_t l, uint32_t u ); $\C{// [l,u]}$
+// FASTER
+uint32_t prng( $thread\LstStringStyle{\textdollar}$ & th );     $\C{// [0,UINT\_MAX]}$
+uint32_t prng( $thread\LstStringStyle{\textdollar}$ & th, uint32_t u ); $\C{// [0,u)}$
+uint32_t prng( $thread\LstStringStyle{\textdollar}$ & th, uint32_t l, uint32_t u );     $\C{// [l,u]}\CRT$
+\end{cfa}
+The only difference between the two sets of ©prng© routines is performance.
+
+Because concurrent execution is non-deterministic, seeding the concurrent PRNG is less important, as repeatable execution is impossible.
+Hence, there is one system-wide PRNG (global seed) but each \CFA thread has its own non-contended PRNG state.
+If the global seed is set, threads start with this seed, until it is reset and then threads start with the reset seed.
+Hence, these threads generate the same sequence of random numbers from their specific starting seed.
+If the global seed is \emph{not} set, threads start with a random seed, until the global seed is set.
+Hence, these threads generate different sequences of random numbers.
+If each thread needs its own seed, use a sequential ©PRNG© in each thread.
+The slower ©prng© functions \emph{without} a thread argument call ©active_thread© internally to indirectly access the current thread's PRNG state, while the faster ©prng© functions \emph{with} a thread argument directly access the thread through the thread parameter.
+If a thread pointer is available, \eg in thread main, eliminating the call to ©active_thread© significantly reduces the cost of accessing the thread's PRNG state.
+\VRef[Figure]{f:ConcurrentPRNG} shows an example using the slower/faster concurrent PRNG in the program main and a thread.
+
+\begin{figure}
+\begin{cfa}
+thread T {};
+void main( ®T & th® ) {  // thread address
+        for ( i; 10 ) {
+                sout | nlOff | ®prng()®;  sout | ®prng( 5 )®;  sout | ®prng( 0, 5 )® | '\t';  // SLOWER
+                sout | nlOff | ®prng( th )®;  sout | ®prng( th, 5 )®;  sout | ®prng( th, 0, 5 )® | nlOn;  // FASTER
+        }
+}
+int main() {
+        set_seed( 1009 );
+        $\R{thread\LstStringStyle{\textdollar}}$ ®& th = *active_thread()®;  // program-main thread-address
+        for ( i; 10 ) {
+                sout | nlOff | ®prng()®; sout | ®prng( 5 )®; sout | ®prng( 0, 5 )® | '\t';  // SLOWER
+                sout | nlOff | ®prng( th )®; sout | ®prng( th, 5 )®; sout | ®prng( th, 0, 5 )® | nlOn;  // FASTER
+        }
+        sout | nl;
+        T t; // run thread
+}
+\end{cfa}
+\begin{cquote}
+\begin{tabular}{@{}ll@{}}
+\begin{cfa}
+37301721 2 2
+290112364 3 2
+733221210 1 3
+123981445 2 3
+283934808 1 0
+1414344101 1 3
+871831898 3 4
+2142057611 4 4
+802117363 0 4
+2346353643 1 3
+\end{cfa}
+&
+\begin{cfa}
+1681308562 1 3
+1852700364 4 3
+1775396023 2 3
+2062557687 2 0
+672325890 1 3
+873424536 3 4
+866783532 0 1
+17310256 2 5
+492964499 0 0
+2143013105 3 2
+\end{cfa}
+\end{tabular}
+\begin{cfa}
+// same output as above from thread t
+\end{cfa}
+\end{cquote}
+\caption{Concurrent PRNG}
+\label{f:ConcurrentPRNG}
+\end{figure}
+\end{itemize}
+
+
 \section{Multi-precision Integers}
 \label{s:MultiPrecisionIntegers}
@@ -8310 +8601 @@
 \end{tabular}
 \end{cquote}
-\small
+
 \begin{cfa}
 Factorial Numbers