Changeset aeec6b7 for doc/user/user.tex


Ignore:
Timestamp:
Jul 10, 2018, 8:20:50 AM (6 years ago)
Author:
Rob Schluntz <rschlunt@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, no_list, persistent-indexer, pthread-emulation, qualifiedEnum
Children:
3d7e53b
Parents:
036dd5f (diff), 97be800 (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:/u/cforall/software/cfa/cfa-cc

File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/user/user.tex

    r036dd5f raeec6b7  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Sun May  6 10:33:53 2018
    14 %% Update Count     : 3319
     13%% Last Modified On : Mon Jul  9 10:49:52 2018
     14%% Update Count     : 3361
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    146146\CFA adds many modern programming-language features that directly lead to increased \emph{\Index{safety}} and \emph{\Index{productivity}}, while maintaining interoperability with existing C programs and achieving similar performance.
    147147Like C, \CFA is a statically typed, procedural (non-\Index{object-oriented}) language with a low-overhead runtime, meaning there is no global \Index{garbage-collection}, but \Index{regional garbage-collection}\index{garbage-collection!regional} is possible.
    148 The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
     148The primary new features include polymorphic routines and types, exceptions, concurrency, and modules.
    149149
    150150One 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''.
    … …  
    155155As well, new programs can be written in \CFA using a combination of C and \CFA features.
    156156
    157 \Index*[C++]{\CC{}} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
    158 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, all of which requires significant effort and training to incrementally add \CC to a C-based project.
     157\Index*[C++]{\CC{}}~\cite{c++:v1} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
     158However, \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.
    159159In contrast, \CFA has 30 years of hindsight and a clean starting point.
    160160
    161161Like \Index*[C++]{\CC{}}, there may be both an old and new ways to achieve the same effect.
    162 For example, the following programs compare the \CFA, C, and \CC I/O mechanisms, where the programs output the same result.
    163 \begin{cquote}
     162For example, the following programs compare the C, \CFA, and \CC I/O mechanisms, where the programs output the same result.
     163\begin{center}
    164164\begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}}
    165165\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{C}} & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
    … …  
    191191\end{cfa}
    192192\end{tabular}
    193 \end{cquote}
     193\end{center}
    194194While the \CFA I/O looks similar to the \Index*[C++]{\CC{}} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}).
    195195
    … …  
    197197
    198198This document is a programmer reference-manual for the \CFA programming language.
    199 The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of each feature.
     199The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of features.
    200200The manual does not teach programming, \ie how to combine the new constructs to build complex programs.
    201 A reader should already have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
     201The reader must have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
    202202Implementers should refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
    203203Changes to the syntax and additional features are expected to be included in later revisions.
    … …  
    206206\section{Why fix C?}
    207207
    208 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems (especially UNIX systems) to hobby projects.
     208The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems.
    209209This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
    210210Even with all its problems, C continues to be popular because it allows writing software at virtually any level in a computer system without restriction.
    211211For system programming, where direct access to hardware, storage management, and real-time issues are a requirement, C is usually the only language of choice.
    212 The TIOBE index~\cite{TIOBE} for March 2016 showed the following programming-language popularity: \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC{}} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, where the next 50 languages are less than 3\% each with a long tail.
    213 As well, for 30 years, C has been the number 1 and 2 most popular programming language:
     212The TIOBE index~\cite{TIOBE} for July 2018 ranks the top 5 most \emph{popular} programming languages as: \Index*{Java} 16\%, C 14\%, \Index*[C++]{\CC{}} 7.5\%, Python 6\%, Visual Basic 4\% = 47.5\%, where the next 50 languages are less than 4\% each, with a long tail.
     213The top 3 rankings over the past 30 years are:
    214214\begin{center}
    215 \setlength{\tabcolsep}{1.5ex}
    216 \begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
    217 Ranking & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986          \\
    218 \hline
    219 Java    & 1             & 1             & 1             & 3             & 29    & -             & -                     \\
    220 \hline
    221 \R{C}   & \R{2} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} & \R{1}         \\
    222 \hline
    223 \CC             & 3             & 3             & 3             & 2             & 2             & 2             & 7                     \\
     215\setlength{\tabcolsep}{10pt}
     216\begin{tabular}{@{}rccccccc@{}}
     217                & 2018  & 2013  & 2008  & 2003  & 1998  & 1993  & 1988  \\ \hline
     218Java    & 1             & 2             & 1             & 1             & 16    & -             & -             \\
     219\R{C}   & \R{2} & \R{1} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} \\
     220\CC             & 3             & 4             & 3             & 3             & 2             & 2             & 5             \\
    224221\end{tabular}
    225222\end{center}
    226223Hence, C is still an extremely important programming language, with double the usage of \Index*[C++]{\CC{}}; in many cases, \CC is often used solely as a better C.
    227224Love it or hate it, C has been an important and influential part of computer science for 40 years and its appeal is not diminishing.
    228 Unfortunately, C has many problems and omissions that make it an unacceptable programming language for modern needs.
     225Nevertheless, C has many problems and omissions that make it an unacceptable programming language for modern needs.
    229226
    230227As stated, the goal of the \CFA project is to engineer modern language-features into C in an evolutionary rather than revolutionary way.
    … …  
    236233These 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.
    237234As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
    238 These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining to the new programming language.
    239 
    240 The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while containing modern language-features.
    241 Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
     235These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining in the new programming language.
     236
     237The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while adding modern language-features.
     238To achieve these goals required a significant engineering exercise, where we had to ``think inside the existing C box''.
     239Without these significant extension to C, it is unable to cope with the needs of modern programming problems and programmers;
    242240as a result, it will fade into disuse.
    243241Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
    … …  
    255253\begin{lstlisting}
    256254®forall( otype T )® T identity( T val ) { return val; }
    257 int forty_two = identity( 42 );                 §\C{// T is bound to int, forty\_two == 42}§
     255int forty_two = identity( 42 );                         §\C{// T is bound to int, forty\_two == 42}§
    258256\end{lstlisting}
    259257% extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
    … …  
    307305\begin{lstlisting}
    308306forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
    309 int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
     307int * ip = malloc();                                            §\C{// select type and size from left-hand side}§
    310308double * dp = malloc();
    311309struct S {...} * sp = malloc();
    … …  
    318316Whereas, \CFA wraps each of these routines into ones with the overloaded name ©abs©:
    319317\begin{cfa}
    320 char abs( char );
    321 ®extern "C" {® int abs( int ); ®}®              §\C{// use default C routine for int}§
    322 long int abs( long int );
    323 long long int abs( long long int );
    324 float abs( float );
    325 double abs( double );
    326 long double abs( long double );
    327 float _Complex abs( float _Complex );
    328 double _Complex abs( double _Complex );
    329 long double _Complex abs( long double _Complex );
     318char ®abs®( char );
     319extern "C" { int ®abs®( int ); }                        §\C{// use default C routine for int}§
     320long int ®abs®( long int );
     321long long int ®abs®( long long int );
     322float ®abs®( float );
     323double ®abs®( double );
     324long double ®abs®( long double );
     325float _Complex ®abs®( float _Complex );
     326double _Complex ®abs®( double _Complex );
     327long double _Complex ®abs®( long double _Complex );
    330328\end{cfa}
    331329The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
    332330Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
    333331Then 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.
    334 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.
    335 There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
     332Hence, 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.
     333There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and types.
    336334
    337335This example strongly illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
    … …  
    350348\begin{description}
    351349\item
    352 \Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
    353 The 1999 C standard plus GNU extensions.
     350\Indexc{-std=gnu11}\index{compilation option!-std=gnu11@{©-std=gnu11©}}
     351The 2011 C standard plus GNU extensions.
    354352\item
    355353\Indexc[deletekeywords=inline]{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{\lstinline[deletekeywords=inline]@-fgnu89-inline@}}
    356 Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
     354Use the traditional GNU semantics for inline routines in C11 mode, which allows inline routines in header files.
    357355\end{description}
    358356The following new \CFA options are available:
    … …  
    427425\begin{cfa}
    428426#ifndef __CFORALL__
    429 #include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
     427#include <stdio.h>§\indexc{stdio.h}§            §\C{// C header file}§
    430428#else
    431 #include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
     429#include <fstream>§\indexc{fstream}§            §\C{// \CFA header file}§
    432430#endif
    433431\end{cfa}
    … …  
    435433
    436434
     435\section{Backquote Identifiers}
     436\label{s:BackquoteIdentifiers}
     437
     438\CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
     439Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
     440\begin{cfa}
     441int ®`®otype®`® = 3;                                            §\C{// make keyword an identifier}§
     442double ®`®forall®`® = 3.5;
     443\end{cfa}
     444
     445Existing 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.
     446\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©.
     447Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
     448
     449\begin{figure}
     450\begin{cfa}
     451// include file uses the CFA keyword "with".
     452#if ! defined( with )                                           §\C{// nesting ?}§
     453#define with ®`®with®`®                                         §\C{// make keyword an identifier}§
     454#define __CFA_BFD_H__
     455#endif
     456
     457®#include_next <bfdlink.h>                                      §\C{// must have internal check for multiple expansion}§
     458®
     459#if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
     460#undef with
     461#undef __CFA_BFD_H__
     462#endif
     463\end{cfa}
     464\caption{Header-File Interposition}
     465\label{f:HeaderFileInterposition}
     466\end{figure}
     467
     468
    437469\section{Constant Underscores}
    438470
    439471Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore}, \eg:
    440472\begin{cfa}
    441 2®_®147®_®483®_®648;                                    §\C{// decimal constant}§
    442 56®_®ul;                                                                §\C{// decimal unsigned long constant}§
    443 0®_®377;                                                                §\C{// octal constant}§
    444 0x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
    445 0x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
    446 3.141®_®592®_®654;                                              §\C{// floating constant}§
    447 10®_®e®_®+1®_®00;                                               §\C{// floating constant}§
    448 0x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating}§
    449 0x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating long constant}§
     4732®_®147®_®483®_®648;                                            §\C{// decimal constant}§
     47456®_®ul;                                                                        §\C{// decimal unsigned long constant}§
     4750®_®377;                                                                        §\C{// octal constant}§
     4760x®_®ff®_®ff;                                                           §\C{// hexadecimal constant}§
     4770x®_®ef3d®_®aa5c;                                                       §\C{// hexadecimal constant}§
     4783.141®_®592®_®654;                                                      §\C{// floating constant}§
     47910®_®e®_®+1®_®00;                                                       §\C{// floating constant}§
     4800x®_®ff®_®ff®_®p®_®3;                                           §\C{// hexadecimal floating}§
     4810x®_®1.ffff®_®ffff®_®p®_®128®_®l;                       §\C{// hexadecimal floating long constant}§
    450482L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
    451483\end{cfa}
    … …  
    469501
    470502
    471 \section{Backquote Identifiers}
    472 \label{s:BackquoteIdentifiers}
    473 
    474 \CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
    475 Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
    476 \begin{cfa}
    477 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
    478 double ®`®forall®`® = 3.5;
    479 \end{cfa}
    480 
    481 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.
    482 \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©.
    483 Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
    484 
    485 \begin{figure}
    486 \begin{cfa}
    487 // include file uses the CFA keyword "with".
    488 #if ! defined( with )                   §\C{// nesting ?}§
    489 #define with ®`®with®`®                 §\C{// make keyword an identifier}§
    490 #define __CFA_BFD_H__
    491 #endif
    492 
    493 ®#include_next <bfdlink.h>              §\C{// must have internal check for multiple expansion}§
    494 ®
    495 #if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
    496 #undef with
    497 #undef __CFA_BFD_H__
    498 #endif
    499 \end{cfa}
    500 \caption{Header-File Interposition}
    501 \label{f:HeaderFileInterposition}
    502 \end{figure}
    503 
    504 
    505503\section{Exponentiation Operator}
    506504
    … …  
    518516256 64 -64 0.015625 -0.015625 18.3791736799526 0.264715-1.1922i
    519517\end{cfa}
    520 Parenthesis are necessary for the complex constants or the expresion is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
     518Parenthesis are necessary for the complex constants or the expression is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
    521519The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation versions are available.
    522520For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©;
    … …  
    524522
    525523
    526 \section{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
     524\section{Control Structures}
     525
     526\CFA identifies inconsistent, problematic, and missing control structures in C, and extends, modifies, and adds control structures to increase functionality and safety.
     527
     528
     529%\subsection{\texorpdfstring{\protect\lstinline@if@ Statement}{if Statement}}
     530\subsection{\texorpdfstring{\LstKeywordStyle{if} Statement}{if Statement}}
     531
     532The ©if© expression allows declarations, similar to ©for© declaration expression:
     533\begin{cfa}
     534if ( int x = f() ) ...                                          §\C{// x != 0}§
     535if ( int x = f(), y = g() ) ...                         §\C{// x != 0 \&\& y != 0}§
     536if ( int x = f(), y = g(); ®x < y® ) ...        §\C{// relational expression}§
     537\end{cfa}
     538Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if© expression, and the results are combined using the logical ©&&© operator.\footnote{\CC only provides a single declaration always compared not equal to 0.}
     539The scope of the declaration(s) is local to the @if@ statement but exist within both the ``then'' and ``else'' clauses.
     540
     541
     542%\section{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}
     543\subsection{\texorpdfstring{\LstKeywordStyle{switch} Statement}{switch Statement}}
     544
     545C allows a number of questionable forms for the ©switch© statement:
     546\begin{enumerate}
     547\item
     548By default, the end of a ©case© clause\footnote{
     549In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
     550\emph{falls through} to the next ©case© clause in the ©switch© statement;
     551to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
     552\begin{cfa}
     553switch ( i ) {
     554  case 1:
     555        ...
     556        // fall-through
     557  case 2:
     558        ...
     559        break;  // exit switch statement
     560}
     561\end{cfa}
     562The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
     563\begin{cquote}
     564\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     565\begin{cfa}
     566switch ( argc ) {
     567  case 3:
     568        // open output file
     569        // fall-through
     570  case 2:
     571        // open input file
     572        break;  // exit switch statement
     573  default:
     574        // usage message
     575}
     576\end{cfa}
     577&
     578\begin{cfa}
     579
     580if ( argc == 3 ) {
     581        // open output file
     582        ®// open input file
     583®} else if ( argc == 2 ) {
     584        ®// open input file (duplicate)
     585
     586®} else {
     587        // usage message
     588}
     589\end{cfa}
     590\end{tabular}
     591\end{cquote}
     592In this example, case 2 is always done if case 3 is done.
     593This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
     594C also uses fall-through to handle multiple case-values resulting in the same action:
     595\begin{cfa}
     596switch ( i ) {
     597  ®case 1: case 3: case 5:®     // odd values
     598        // odd action
     599        break;
     600  ®case 2: case 4: case 6:®     // even values
     601        // even action
     602        break;
     603}
     604\end{cfa}
     605However, this situation is handled in other languages without fall-through by allowing a list of case values.
     606While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
     607Hence, 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.
     608
     609\item
     610It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
     611\begin{cfa}
     612switch ( i ) {
     613  case 0:
     614        if ( j < k ) {
     615                ...
     616          ®case 1:®             // transfer into "if" statement
     617                ...
     618        } // if
     619  case 2:
     620        while ( j < 5 ) {
     621                ...
     622          ®case 3:®             // transfer into "while" statement
     623                ...
     624        } // while
     625} // switch
     626\end{cfa}
     627The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
     628The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
     629The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
     630There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
     631Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
     632\begin{cfa}
     633register int n = (count + 7) / 8;
     634switch ( count % 8 ) {
     635case 0: do{ *to = *from++;
     636case 7:         *to = *from++;
     637case 6:         *to = *from++;
     638case 5:         *to = *from++;
     639case 4:         *to = *from++;
     640case 3:         *to = *from++;
     641case 2:         *to = *from++;
     642case 1:         *to = *from++;
     643                } while ( --n > 0 );
     644}
     645\end{cfa}
     646which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
     647While efficient, this sort of special purpose usage is questionable:
     648\begin{quote}
     649Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
     650discovery.~\cite{Duff83}
     651\end{quote}
     652\item
     653It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
     654Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
     655The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
     656hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
     657This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
     658
     659\item
     660It is possible to place unreachable code at the start of a ©switch© statement, as in:
     661\begin{cfa}
     662switch ( x ) {
     663        ®int y = 1;®                                                    §\C{// unreachable initialization}§
     664        ®x = 7;®                                                                §\C{// unreachable code without label/branch}§
     665  case 0: ...
     666        ...
     667        ®int z = 0;®                                                    §\C{// unreachable initialization, cannot appear after case}§
     668        z = 2;
     669  case 1:
     670        ®x = z;®                                                                §\C{// without fall through, z is uninitialized}§
     671}
     672\end{cfa}
     673While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
     674Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
     675As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
     676The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
     677\end{enumerate}
     678
     679Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
     680\begin{itemize}
     681\item
     682the number of ©switch© statements is small,
     683\item
     684most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
     685\item
     686the ©default© clause is usually written as the last case-clause,
     687\item
     688and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
     689\end{itemize}
     690These observations put into perspective the \CFA changes to the ©switch©.
     691\begin{enumerate}
     692\item
     693Eliminating default fall-through has the greatest potential for affecting existing code.
     694However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
     695\begin{cfa}
     696case 1:  case 2:  case 3: ...
     697\end{cfa}
     698still works.
     699Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
     700Therefore, 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:
     701\begin{cfa}
     702®choose® ( i ) {
     703  case 1:  case 2:  case 3:
     704        ...
     705        ®// implicit end of switch (break)
     706  ®case 5:
     707        ...
     708        ®fallthru®;                                                             §\C{// explicit fall through}§
     709  case 7:
     710        ...
     711        ®break®                                                                 §\C{// explicit end of switch (redundant)}§
     712  default:
     713        j = 3;
     714}
     715\end{cfa}
     716Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
     717An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
     718An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
     719As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
     720\item
     721\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
     722Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
     723\item
     724The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
     725Therefore, no change is made for this issue.
     726\item
     727Dealing 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{
     728Essentially, 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.
     729Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
     730\begin{cfa}
     731switch ( x ) {
     732        ®int i = 0;®                                                    §\C{// allowed only at start}§
     733  case 0:
     734        ...
     735        ®int j = 0;®                                                    §\C{// disallowed}§
     736  case 1:
     737        {
     738                ®int k = 0;®                                            §\C{// allowed at different nesting levels}§
     739                ...
     740          ®case 2:®                                                             §\C{// disallow case in nested statements}§
     741        }
     742  ...
     743}
     744\end{cfa}
     745\end{enumerate}
     746
     747
     748%\section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
     749\subsection{\texorpdfstring{\LstKeywordStyle{case} Statement}{case Statement}}
     750
     751C restricts the ©case© clause of a ©switch© statement to a single value.
     752For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
     753Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
     754Therefore, the ©case© clause is extended with a list of values, as in:
     755\begin{cquote}
     756\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
     757\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
     758\begin{cfa}
     759switch ( i ) {
     760  case ®1, 3, 5®:
     761        ...
     762  case ®2, 4, 6®:
     763        ...
     764}
     765\end{cfa}
     766&
     767\begin{cfa}
     768switch ( i ) {
     769  case 1: case 3 : case 5:
     770        ...
     771  case 2: case 4 : case 6:
     772        ...
     773}
     774\end{cfa}
     775&
     776\begin{cfa}
     777
     778// odd values
     779
     780// even values
     781
     782
     783\end{cfa}
     784\end{tabular}
     785\end{cquote}
     786In addition, subranges are allowed to specify case values.\footnote{
     787gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, because a space is required after a number, otherwise the period is a decimal point.}
     788\begin{cfa}
     789switch ( i ) {
     790  case ®1~5:®                                   §\C{// 1, 2, 3, 4, 5}§
     791        ...
     792  case ®10~15:®                                 §\C{// 10, 11, 12, 13, 14, 15}§
     793        ...
     794}
     795\end{cfa}
     796Lists of subranges are also allowed.
     797\begin{cfa}
     798case ®1~5, 12~21, 35~42®:
     799\end{cfa}
     800
     801
     802%\subsection{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
     803\subsection{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break} Statement}{Labelled continue / break Statement}}
    527804
    528805While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
    … …  
    626903With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
    627904Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
    628 The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
    629 
    630 
    631 \section{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}
    632 
    633 C allows a number of questionable forms for the ©switch© statement:
    634 \begin{enumerate}
    635 \item
    636 By default, the end of a ©case© clause\footnote{
    637 In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
    638 \emph{falls through} to the next ©case© clause in the ©switch© statement;
    639 to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
    640 \begin{cfa}
    641 switch ( i ) {
    642   case 1:
    643         ...
    644         // fall-through
    645   case 2:
    646         ...
    647         break;  // exit switch statement
    648 }
    649 \end{cfa}
    650 The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
    651 \begin{cquote}
    652 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    653 \begin{cfa}
    654 switch ( argc ) {
    655   case 3:
    656         // open output file
    657         // fall-through
    658   case 2:
    659         // open input file
    660         break;  // exit switch statement
    661   default:
    662         // usage message
    663 }
    664 \end{cfa}
    665 &
    666 \begin{cfa}
    667 
    668 if ( argc == 3 ) {
    669         // open output file
    670         ®// open input file
    671 ®} else if ( argc == 2 ) {
    672         ®// open input file (duplicate)
    673 
    674 ®} else {
    675         // usage message
    676 }
    677 \end{cfa}
    678 \end{tabular}
    679 \end{cquote}
    680 In this example, case 2 is always done if case 3 is done.
    681 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
    682 C also uses fall-through to handle multiple case-values resulting in the same action:
    683 \begin{cfa}
    684 switch ( i ) {
    685   ®case 1: case 3: case 5:®     // odd values
    686         // odd action
    687         break;
    688   ®case 2: case 4: case 6:®     // even values
    689         // even action
    690         break;
    691 }
    692 \end{cfa}
    693 However, this situation is handled in other languages without fall-through by allowing a list of case values.
    694 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 virtually all other programming languages with a ©switch© statement.
    695 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.
    696 
    697 \item
    698 It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
    699 \begin{cfa}
    700 switch ( i ) {
    701   case 0:
    702         if ( j < k ) {
    703                 ...
    704           ®case 1:®             // transfer into "if" statement
    705                 ...
    706         } // if
    707   case 2:
    708         while ( j < 5 ) {
    709                 ...
    710           ®case 3:®             // transfer into "while" statement
    711                 ...
    712         } // while
    713 } // switch
    714 \end{cfa}
    715 The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
    716 The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
    717 The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
    718 There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
    719 Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
    720 \begin{cfa}
    721 register int n = (count + 7) / 8;
    722 switch ( count % 8 ) {
    723 case 0: do{ *to = *from++;
    724 case 7:         *to = *from++;
    725 case 6:         *to = *from++;
    726 case 5:         *to = *from++;
    727 case 4:         *to = *from++;
    728 case 3:         *to = *from++;
    729 case 2:         *to = *from++;
    730 case 1:         *to = *from++;
    731                 } while ( --n > 0 );
    732 }
    733 \end{cfa}
    734 which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
    735 While efficient, this sort of special purpose usage is questionable:
    736 \begin{quote}
    737 Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
    738 discovery.~\cite{Duff83}
    739 \end{quote}
    740 \item
    741 It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
    742 Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
    743 The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
    744 hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
    745 This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
    746 
    747 \item
    748 It is possible to place unreachable code at the start of a ©switch© statement, as in:
    749 \begin{cfa}
    750 switch ( x ) {
    751         ®int y = 1;®                            §\C{// unreachable initialization}§
    752         ®x = 7;®                                        §\C{// unreachable code without label/branch}§
    753   case 0: ...
    754         ...
    755         ®int z = 0;®                            §\C{// unreachable initialization, cannot appear after case}§
    756         z = 2;
    757   case 1:
    758         ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
    759 }
    760 \end{cfa}
    761 While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
    762 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
    763 As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
    764 The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
    765 \end{enumerate}
    766 
    767 Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
    768 \begin{itemize}
    769 \item
    770 the number of ©switch© statements is small,
    771 \item
    772 most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
    773 \item
    774 the ©default© clause is usually written as the last case-clause,
    775 \item
    776 and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
    777 \end{itemize}
    778 These observations put into perspective the \CFA changes to the ©switch©.
    779 \begin{enumerate}
    780 \item
    781 Eliminating default fall-through has the greatest potential for affecting existing code.
    782 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
    783 \begin{cfa}
    784 case 1:  case 2:  case 3: ...
    785 \end{cfa}
    786 still works.
    787 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.
    788 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:
    789 \begin{cfa}
    790 ®choose® ( i ) {
    791   case 1:  case 2:  case 3:
    792         ...
    793         ®// implicit end of switch (break)
    794   ®case 5:
    795         ...
    796         ®fallthru®;                                     §\C{// explicit fall through}§
    797   case 7:
    798         ...
    799         ®break®                                         §\C{// explicit end of switch (redundant)}§
    800   default:
    801         j = 3;
    802 }
    803 \end{cfa}
    804 Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
    805 An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
    806 An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
    807 As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
    808 \item
    809 \Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
    810 Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
    811 \item
    812 The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
    813 Therefore, no change is made for this issue.
    814 \item
    815 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{
    816 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.
    817 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
    818 \begin{cfa}
    819 switch ( x ) {
    820         ®int i = 0;®                            §\C{// allowed only at start}§
    821   case 0:
    822         ...
    823         ®int j = 0;®                            §\C{// disallowed}§
    824   case 1:
    825         {
    826                 ®int k = 0;®                    §\C{// allowed at different nesting levels}§
    827                 ...
    828           ®case 2:®                                     §\C{// disallow case in nested statements}§
    829         }
    830   ...
    831 }
    832 \end{cfa}
    833 \end{enumerate}
    834 
    835 
    836 \section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
    837 
    838 C restricts the ©case© clause of a ©switch© statement to a single value.
    839 For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
    840 Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
    841 Therefore, the ©case© clause is extended with a list of values, as in:
    842 \begin{cquote}
    843 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    844 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    845 \begin{cfa}
    846 switch ( i ) {
    847   case ®1, 3, 5®:
    848         ...
    849   case ®2, 4, 6®:
    850         ...
    851 }
    852 \end{cfa}
    853 &
    854 \begin{cfa}
    855 switch ( i ) {
    856   case 1: case 3 : case 5:
    857         ...
    858   case 2: case 4 : case 6:
    859         ...
    860 }
    861 \end{cfa}
    862 &
    863 \begin{cfa}
    864 
    865 // odd values
    866 
    867 // even values
    868 
    869 
    870 \end{cfa}
    871 \end{tabular}
    872 \end{cquote}
    873 In addition, subranges are allowed to specify case values.\footnote{
    874 gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, because a space is required after a number, otherwise the period is a decimal point.}
    875 \begin{cfa}
    876 switch ( i ) {
    877   case ®1~5:®                                   §\C{// 1, 2, 3, 4, 5}§
    878         ...
    879   case ®10~15:®                                 §\C{// 10, 11, 12, 13, 14, 15}§
    880         ...
    881 }
    882 \end{cfa}
    883 Lists of subranges are also allowed.
    884 \begin{cfa}
    885 case ®1~5, 12~21, 35~42®:
    886 \end{cfa}
    887 
    888 
    889 \section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
     905Otherwise, the implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
     906
     907
     908%\section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
     909\section{\texorpdfstring{\LstKeywordStyle{with} Statement}{with Statement}}
    890910\label{s:WithStatement}
    891911
    … …  
    902922\begin{cfa}
    903923void f( S s ) {
    904         `s.`c; `s.`i; `s.`d;                                    §\C{// access containing fields}§
     924        ®s.®c; ®s.®i; ®s.®d;                                    §\C{// access containing fields}§
    905925}
    906926\end{cfa}
    … …  
    913933        double d;
    914934        void f() {                                                              §\C{// implicit ``this'' aggregate}§
    915                 `this->`c; `this->`i; `this->`d;        §\C{// access containing fields}§
     935                ®this->®c; ®this->®i; ®this->®d;        §\C{// access containing fields}§
    916936        }
    917937}
    918938\end{C++}
    919 Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]$this->$ because of lexical scoping.
     939Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
    920940However, for other aggregate parameters, qualification is necessary:
    921941\begin{cfa}
    … …  
    923943int S::f( T & t ) {                                                     §\C{// multiple aggregate parameters}§
    924944        c; i; d;                                                                §\C{\color{red}// this--{\textgreater}.c, this--{\textgreater}.i, this--{\textgreater}.d}§
    925         `t.`m; `t.`n;                                                   §\C{// must qualify}§
    926 }
    927 \end{cfa}
    928 
    929 To simplify the programmer experience, \CFA provides a @with@ statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
     945        ®t.®m; ®t.®n;                                                   §\C{// must qualify}§
     946}
     947\end{cfa}
     948
     949To simplify the programmer experience, \CFA provides a ©with© statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
    930950Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block.
    931951\begin{cfa}
    932 void f( S & this ) `with ( this )` {            §\C{// with statement}§
     952void f( S & this ) ®with ( this )® {            §\C{// with statement}§
    933953        c; i; d;                                                                §\C{\color{red}// this.c, this.i, this.d}§
    934954}
    … …  
    936956with the generality of opening multiple aggregate-parameters:
    937957\begin{cfa}
    938 void f( S & s, T & t ) `with ( s, t )` {                §\C{// multiple aggregate parameters}§
     958void f( S & s, T & t ) ®with ( s, t )® {        §\C{// multiple aggregate parameters}§
    939959        c; i; d;                                                                §\C{\color{red}// s.c, s.i, s.d}§
    940960        m; n;                                                                   §\C{\color{red}// t.m, t.n}§
    … …  
    942962\end{cfa}
    943963
    944 In detail, the @with@ statement has the form:
     964In detail, the ©with© statement has the form:
    945965\begin{cfa}
    946966§\emph{with-statement}§:
    … …  
    957977The difference between parallel and nesting occurs for fields with the same name and type:
    958978\begin{cfa}
    959 struct S { int `i`; int j; double m; } s, w;
    960 struct T { int `i`; int k; int m; } t, w;
     979struct S { int ®i®; int j; double m; } s, w;
     980struct T { int ®i®; int k; int m; } t, w;
    961981with ( s, t ) {
    962982        j + k;                                                                  §\C{// unambiguous, s.j + t.k}§
    … …  
    969989}
    970990\end{cfa}
    971 For parallel semantics, both @s.i@ and @t.i@ are visible, so @i@ is ambiguous without qualification;
    972 for nested semantics, @t.i@ hides @s.i@, so @i@ implies @t.i@.
     991For parallel semantics, both ©s.i© and ©t.i© are visible, so ©i© is ambiguous without qualification;
     992for nested semantics, ©t.i© hides ©s.i©, so ©i© implies ©t.i©.
    973993\CFA's ability to overload variables means fields with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates.
    974994Qualification or a cast is used to disambiguate.
    975995
    976 There is an interesting problem between parameters and the function-body @with@, \eg:
     996There is an interesting problem between parameters and the function-body ©with©, \eg:
    977997\begin{cfa}
    978998void ?{}( S & s, int i ) with ( s ) {           §\C{// constructor}§
    979         `s.i = i;`  j = 3;  m = 5.5;                    §\C{// initialize fields}§
    980 }
    981 \end{cfa}
    982 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@.
     999        ®s.i = i;®  j = 3;  m = 5.5;                    §\C{// initialize fields}§
     1000}
     1001\end{cfa}
     1002Here, 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©.
    9831003To solve this problem, parameters are treated like an initialized aggregate:
    9841004\begin{cfa}
    … …  
    9901010and implicitly opened \emph{after} a function-body open, to give them higher priority:
    9911011\begin{cfa}
    992 void ?{}( S & s, int `i` ) with ( s ) `with( §\emph{\color{red}params}§ )` {
    993         s.i = `i`; j = 3; m = 5.5;
    994 }
    995 \end{cfa}
    996 Finally, a cast may be used to disambiguate among overload variables in a @with@ expression:
     1012void ?{}( S & s, int ®i® ) with ( s ) ®with( §\emph{\color{red}params}§ )® {
     1013        s.i = ®i®; j = 3; m = 5.5;
     1014}
     1015\end{cfa}
     1016Finally, a cast may be used to disambiguate among overload variables in a ©with© expression:
    9971017\begin{cfa}
    9981018with ( w ) { ... }                                                      §\C{// ambiguous, same name and no context}§
    9991019with ( (S)w ) { ... }                                           §\C{// unambiguous, cast}§
    10001020\end{cfa}
    1001 and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
     1021and ©with© expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
    10021022% \begin{cfa}
    10031023% struct S { int i, j; } sv;
    … …  
    10191039class C {
    10201040        int i, j;
    1021         int mem() {                                     §\C{\color{red}// implicit "this" parameter}§
    1022                 i = 1;                                  §\C{\color{red}// this->i}§
    1023                 j = 2;                                  §\C{\color{red}// this->j}§
     1041        int mem() {                                                             §\C{\color{red}// implicit "this" parameter}§
     1042                i = 1;                                                          §\C{\color{red}// this->i}§
     1043                j = 2;                                                          §\C{\color{red}// this->j}§
    10241044        }
    10251045}
    … …  
    10281048\begin{cfa}
    10291049struct S { int i, j; };
    1030 int mem( S & ®this® ) {                 §\C{// explicit "this" parameter}§
    1031         ®this.®i = 1;                           §\C{// "this" is not elided}§
     1050int mem( S & ®this® ) {                                         §\C{// explicit "this" parameter}§
     1051        ®this.®i = 1;                                                   §\C{// "this" is not elided}§
    10321052        ®this.®j = 2;
    10331053}
    … …  
    10371057\CFA provides a ©with© clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided the "©this.©" by opening a scope containing field identifiers, changing the qualified fields into variables and giving an opportunity for optimizing qualified references.
    10381058\begin{cfa}
    1039 int mem( S & this ) ®with( this )® { §\C{// with clause}§
    1040         i = 1;                                          §\C{\color{red}// this.i}§
    1041         j = 2;                                          §\C{\color{red}// this.j}§
     1059int mem( S & this ) ®with( this )® {            §\C{// with clause}§
     1060        i = 1;                                                                  §\C{\color{red}// this.i}§
     1061        j = 2;                                                                  §\C{\color{red}// this.j}§
    10421062}
    10431063\end{cfa}
    … …  
    10561076        struct S1 { ... } s1;
    10571077        struct S2 { ... } s2;
    1058         ®with( s1 )® {                          §\C{// with statement}§
     1078        ®with( s1 )® {                                                  §\C{// with statement}§
    10591079                // access fields of s1 without qualification
    1060                 ®with s2® {                             §\C{// nesting}§
     1080                ®with s2® {                                                     §\C{// nesting}§
    10611081                        // access fields of s1 and s2 without qualification
    10621082                }
    … …  
    11131133Non-local transfer can cause stack unwinding, \ie non-local routine termination, depending on the kind of raise.
    11141134\begin{cfa}
    1115 exception_t E {};                               §\C{// exception type}§
     1135exception_t E {};                                                       §\C{// exception type}§
    11161136void f(...) {
    1117         ... throw E{}; ...                      §\C{// termination}§
    1118         ... throwResume E{}; ...        §\C{// resumption}§
     1137        ... throw E{}; ...                                              §\C{// termination}§
     1138        ... throwResume E{}; ...                                §\C{// resumption}§
    11191139}
    11201140try {
    11211141        f(...);
    1122 } catch( E e ; §boolean-predicate§ ) {                  §\C[8cm]{// termination handler}§
     1142} catch( E e ; §boolean-predicate§ ) {          §\C[8cm]{// termination handler}§
    11231143        // recover and continue
    1124 } catchResume( E e ; §boolean-predicate§ ) {    §\C{// resumption handler}\CRT§
     1144} catchResume( E e ; §boolean-predicate§ ) { §\C{// resumption handler}\CRT§
    11251145        // repair and return
    11261146} finally {
    … …  
    16421662\begin{itemize}
    16431663\item
    1644 if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) then ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
    1645 
    1646 \item
    1647 if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
     1664if ©R© is an \Index{rvalue} of type ©T &©$_1\cdots$ ©&©$_r$, where $r \ge 1$ references (©&© symbols), than ©&R© has type ©T ®*®&©$_{\color{red}2}\cdots$ ©&©$_{\color{red}r}$, \ie ©T© pointer with $r-1$ references (©&© symbols).
     1665
     1666\item
     1667if ©L© is an \Index{lvalue} of type ©T &©$_1\cdots$ ©&©$_l$, where $l \ge 0$ references (©&© symbols), than ©&L© has type ©T ®*®&©$_{\color{red}1}\cdots$ ©&©$_{\color{red}l}$, \ie ©T© pointer with $l$ references (©&© symbols).
    16481668\end{itemize}
    16491669The following example shows the first rule applied to different \Index{rvalue} contexts:
    … …  
    59996019
    60006020
    6001 \subsection{Conversion}
     6021\subsection{String to Value Conversion}
    60026022
    60036023\leavevmode
    … …  
    60696089\leavevmode
    60706090\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    6071 void rand48seed( long int s );§\indexc{rand48seed}§
    6072 char rand48();§\indexc{rand48}§
    6073 int rand48();
    6074 unsigned int rand48();
    6075 long int rand48();
    6076 unsigned long int rand48();
    6077 float rand48();
    6078 double rand48();
    6079 float _Complex rand48();
    6080 double _Complex rand48();
    6081 long double _Complex rand48();
     6091void srandom( unsigned int seed );§\indexc{srandom}§
     6092char random( void );§\indexc{random}§
     6093char random( char u );                                          §\C{// [0,u)}§
     6094char random( char l, char u );                          §\C{// [l,u)}§
     6095int random( void );
     6096int random( int u );                                            §\C{// [0,u)}§
     6097int random( int l, int u );                                     §\C{// [l,u)}§
     6098unsigned int random( void );
     6099unsigned int random( unsigned int u );          §\C{// [0,u)}§
     6100unsigned int random( unsigned int l, unsigned int u ); §\C{// [l,u)}§
     6101long int random( void );
     6102long int random( long int u );                          §\C{// [0,u)}§
     6103long int random( long int l, long int u );      §\C{// [l,u)}§
     6104unsigned long int random( void );
     6105unsigned long int random( unsigned long int u ); §\C{// [0,u)}§
     6106unsigned long int random( unsigned long int l, unsigned long int u ); §\C{// [l,u)}§
     6107float random( void );                                            §\C{// [0.0, 1.0)}§
     6108double random( void );                                           §\C{// [0.0, 1.0)}§
     6109float _Complex random( void );                           §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
     6110double _Complex random( void );                          §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
     6111long double _Complex random( void );             §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
    60826112\end{cfa}
    60836113
    … …  
    64586488
    64596489
    6460 \section{Time}
    6461 \label{s:TimeLib}
     6490\section{Time Keeping}
     6491\label{s:TimeKeeping}
    64626492
    64636493
    64646494%\subsection{\texorpdfstring{\protect\lstinline@Duration@}{Duration}}
    6465 \subsection{\texorpdfstring{\LstKeywordStyle{\textmd{Duration}}}{Duration}}
     6495\subsection{\texorpdfstring{\LstBasicStyle{Duration}}{Duration}}
    64666496\label{s:Duration}
    64676497
    … …  
    65126542
    65136543Duration abs( Duration rhs );
    6514 
    6515 forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Duration dur );
    65166544
    65176545Duration ?`ns( int64_t nsec );
    … …  
    65376565int64_t ?`d( Duration dur );
    65386566int64_t ?`w( Duration dur );
     6567
     6568Duration max( Duration lhs, Duration rhs );
     6569Duration min( Duration lhs, Duration rhs );
    65396570\end{cfa}
    65406571
    65416572
    65426573%\subsection{\texorpdfstring{\protect\lstinline@\timeval@}{timeval}}
    6543 \subsection{\texorpdfstring{\LstKeywordStyle{\textmd{timeval}}}{timeval}}
     6574\subsection{\texorpdfstring{\LstBasicStyle{timeval}}{timeval}}
    65446575\label{s:timeval}
    65456576
    … …  
    65606591
    65616592
    6562 \subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
     6593%\subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
     6594\subsection{\texorpdfstring{\LstBasicStyle{timespec}}{timespec}}
    65636595\label{s:timespec}
    65646596
    … …  
    65796611
    65806612
    6581 \subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
     6613%\subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
     6614\subsection{\texorpdfstring{\LstBasicStyle{itimerval}}{itimerval}}
    65826615\label{s:itimerval}
    65836616
    … …  
    65896622
    65906623
    6591 \subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
     6624%\subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
     6625\subsection{\texorpdfstring{\LstBasicStyle{Time}}{Time}}
    65926626\label{s:Time}
    65936627
    … …  
    66006634void ?{}( Time & time );
    66016635void ?{}( Time & time, zero_t );
    6602 void ?{}( Time & time, int year, int month = 0, int day = 0, int hour = 0, int min = 0, int sec = 0, int nsec = 0 );
     6636
    66036637Time ?=?( Time & time, zero_t );
    66046638
    … …  
    66096643Time ?=?( Time & time, timespec t );
    66106644
    6611 Time ?+?( Time & lhs, Duration rhs ) { return (Time)@{ lhs.tv + rhs.tv }; }
    6612 Time ?+?( Duration lhs, Time rhs ) { return rhs + lhs; }
    6613 Time ?+=?( Time & lhs, Duration rhs ) { lhs = lhs + rhs; return lhs; }
    6614 
    6615 Duration ?-?( Time lhs, Time rhs ) { return (Duration)@{ lhs.tv - rhs.tv }; }
    6616 Time ?-?( Time lhs, Duration rhs ) { return (Time)@{ lhs.tv - rhs.tv }; }
    6617 Time ?-=?( Time & lhs, Duration rhs ) { lhs = lhs - rhs; return lhs; }
    6618 _Bool ?==?( Time lhs, Time rhs ) { return lhs.tv == rhs.tv; }
    6619 _Bool ?!=?( Time lhs, Time rhs ) { return lhs.tv != rhs.tv; }
    6620 _Bool ?<?( Time lhs, Time rhs ) { return lhs.tv < rhs.tv; }
    6621 _Bool ?<=?( Time lhs, Time rhs ) { return lhs.tv <= rhs.tv; }
    6622 _Bool ?>?( Time lhs, Time rhs ) { return lhs.tv > rhs.tv; }
    6623 _Bool ?>=?( Time lhs, Time rhs ) { return lhs.tv >= rhs.tv; }
    6624 
    6625 forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
     6645Time ?+?( Time & lhs, Duration rhs );
     6646Time ?+?( Duration lhs, Time rhs );
     6647Time ?+=?( Time & lhs, Duration rhs );
     6648
     6649Duration ?-?( Time lhs, Time rhs );
     6650Time ?-?( Time lhs, Duration rhs );
     6651Time ?-=?( Time & lhs, Duration rhs );
     6652_Bool ?==?( Time lhs, Time rhs );
     6653_Bool ?!=?( Time lhs, Time rhs );
     6654_Bool ?<?( Time lhs, Time rhs );
     6655_Bool ?<=?( Time lhs, Time rhs );
     6656_Bool ?>?( Time lhs, Time rhs );
     6657_Bool ?>=?( Time lhs, Time rhs );
    66266658
    66276659char * yy_mm_dd( Time time, char * buf );
    … …  
    66416673
    66426674size_t strftime( char * buf, size_t size, const char * fmt, Time time );
     6675forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
    66436676\end{cfa}
    66446677
    … …  
    66616694
    66626695%\subsection{\texorpdfstring{\protect\lstinline@Clock@}{Clock}}
    6663 \subsection{\texorpdfstring{\LstKeywordStyle{\textmd{Clock}}}{Clock}}
     6696\subsection{\texorpdfstring{\LstBasicStyle{Clock}}{Clock}}
    66646697\label{s:Clock}
    66656698
    … …  
    66756708void ?{}( Clock & clk );
    66766709void ?{}( Clock & clk, Duration adj );
    6677 Duration getRes();
     6710
     6711Duration getResNsec();                                  §\C{// with nanoseconds}§
     6712Duration getRes();                                              §\C{// without nanoseconds}§
     6713
    66786714Time getTimeNsec();                                             §\C{// with nanoseconds}§
    66796715Time getTime();                                                 §\C{// without nanoseconds}§
Note: See TracChangeset for help on using the changeset viewer.