Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/user/user.tex

    ra74503ff r48b9b36  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Mon Jul  9 10:49:52 2018
    14 %% Update Count     : 3361
     13%% Last Modified On : Sun May  6 10:33:53 2018
     14%% Update Count     : 3319
    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 polymorphic routines and types, exceptions, concurrency, and modules.
     148The primary new features include parametric-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{}}~\cite{c++:v1} 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, requiring significant effort and training to incrementally add \CC to a C-based project.
     157\Index*[C++]{\CC{}} 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, all of which requires 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 C, \CFA, and \CC I/O mechanisms, where the programs output the same result.
    163 \begin{center}
     162For example, the following programs compare the \CFA, C, and \CC I/O mechanisms, where the programs output the same result.
     163\begin{cquote}
    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{center}
     193\end{cquote}
    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 features.
     199The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of each feature.
    200200The manual does not teach programming, \ie how to combine the new constructs to build complex programs.
    201 The 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.
     201A 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.
    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 hobby projects to commercial operating-systems.
     208The 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.
    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 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.
    213 The top 3 rankings over the past 30 years are:
     212The 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.
     213As well, for 30 years, C has been the number 1 and 2 most popular programming language:
    214214\begin{center}
    215 \setlength{\tabcolsep}{10pt}
    216 \begin{tabular}{@{}rccccccc@{}}
    217                 & 2018  & 2013  & 2008  & 2003  & 1998  & 1993  & 1988  \\ \hline
    218 Java    & 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             \\
     215\setlength{\tabcolsep}{1.5ex}
     216\begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
     217Ranking & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986          \\
     218\hline
     219Java    & 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                     \\
    221224\end{tabular}
    222225\end{center}
    223226Hence, 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.
    224227Love it or hate it, C has been an important and influential part of computer science for 40 years and its appeal is not diminishing.
    225 Nevertheless, C has many problems and omissions that make it an unacceptable programming language for modern needs.
     228Unfortunately, C has many problems and omissions that make it an unacceptable programming language for modern needs.
    226229
    227230As stated, the goal of the \CFA project is to engineer modern language-features into C in an evolutionary rather than revolutionary way.
    … …  
    233236These 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.
    234237As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
    235 These 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 
    237 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 adding modern language-features.
    238 To achieve these goals required a significant engineering exercise, where we had to ``think inside the existing C box''.
    239 Without these significant extension to C, it is unable to cope with the needs of modern programming problems and programmers;
     238These 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
     240The 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.
     241Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
    240242as a result, it will fade into disuse.
    241243Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
    … …  
    253255\begin{lstlisting}
    254256®forall( otype T )® T identity( T val ) { return val; }
    255 int forty_two = identity( 42 );                         §\C{// T is bound to int, forty\_two == 42}§
     257int forty_two = identity( 42 );                 §\C{// T is bound to int, forty\_two == 42}§
    256258\end{lstlisting}
    257259% extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
    … …  
    305307\begin{lstlisting}
    306308forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
    307 int * ip = malloc();                                            §\C{// select type and size from left-hand side}§
     309int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
    308310double * dp = malloc();
    309311struct S {...} * sp = malloc();
    … …  
    316318Whereas, \CFA wraps each of these routines into ones with the overloaded name ©abs©:
    317319\begin{cfa}
    318 char ®abs®( char );
    319 extern "C" { int ®abs®( int ); }                        §\C{// use default C routine for int}§
    320 long int ®abs®( long int );
    321 long long int ®abs®( long long int );
    322 float ®abs®( float );
    323 double ®abs®( double );
    324 long double ®abs®( long double );
    325 float _Complex ®abs®( float _Complex );
    326 double _Complex ®abs®( double _Complex );
    327 long double _Complex ®abs®( long double _Complex );
     320char abs( char );
     321®extern "C" {® int abs( int ); ®}®              §\C{// use default C routine for int}§
     322long int abs( long int );
     323long long int abs( long long int );
     324float abs( float );
     325double abs( double );
     326long double abs( long double );
     327float _Complex abs( float _Complex );
     328double _Complex abs( double _Complex );
     329long double _Complex abs( long double _Complex );
    328330\end{cfa}
    329331The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
    330332Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
    331333Then 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.
    332 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.
    333 There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and types.
     334Hence, 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.
     335There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
    334336
    335337This example strongly illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
    … …  
    348350\begin{description}
    349351\item
    350 \Indexc{-std=gnu11}\index{compilation option!-std=gnu11@{©-std=gnu11©}}
    351 The 2011 C standard plus GNU extensions.
     352\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
     353The 1999 C standard plus GNU extensions.
    352354\item
    353355\Indexc[deletekeywords=inline]{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{\lstinline[deletekeywords=inline]@-fgnu89-inline@}}
    354 Use the traditional GNU semantics for inline routines in C11 mode, which allows inline routines in header files.
     356Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
    355357\end{description}
    356358The following new \CFA options are available:
    … …  
    425427\begin{cfa}
    426428#ifndef __CFORALL__
    427 #include <stdio.h>§\indexc{stdio.h}§            §\C{// C header file}§
     429#include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
    428430#else
    429 #include <fstream>§\indexc{fstream}§            §\C{// \CFA header file}§
     431#include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
    430432#endif
    431433\end{cfa}
    … …  
    433435
    434436
    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.
    439 Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
    440 \begin{cfa}
    441 int ®`®otype®`® = 3;                                            §\C{// make keyword an identifier}§
    442 double ®`®forall®`® = 3.5;
    443 \end{cfa}
    444 
    445 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.
    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©.
    447 Several 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 
    469437\section{Constant Underscores}
    470438
    471439Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore}, \eg:
    472440\begin{cfa}
    473 2®_®147®_®483®_®648;                                            §\C{// decimal constant}§
    474 56®_®ul;                                                                        §\C{// decimal unsigned long constant}§
    475 0®_®377;                                                                        §\C{// octal constant}§
    476 0x®_®ff®_®ff;                                                           §\C{// hexadecimal constant}§
    477 0x®_®ef3d®_®aa5c;                                                       §\C{// hexadecimal constant}§
    478 3.141®_®592®_®654;                                                      §\C{// floating constant}§
    479 10®_®e®_®+1®_®00;                                                       §\C{// floating constant}§
    480 0x®_®ff®_®ff®_®p®_®3;                                           §\C{// hexadecimal floating}§
    481 0x®_®1.ffff®_®ffff®_®p®_®128®_®l;                       §\C{// hexadecimal floating long constant}§
     4412®_®147®_®483®_®648;                                    §\C{// decimal constant}§
     44256®_®ul;                                                                §\C{// decimal unsigned long constant}§
     4430®_®377;                                                                §\C{// octal constant}§
     4440x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
     4450x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
     4463.141®_®592®_®654;                                              §\C{// floating constant}§
     44710®_®e®_®+1®_®00;                                               §\C{// floating constant}§
     4480x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating}§
     4490x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating long constant}§
    482450L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
    483451\end{cfa}
    … …  
    501469
    502470
     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.
     475Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
     476\begin{cfa}
     477int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
     478double ®`®forall®`® = 3.5;
     479\end{cfa}
     480
     481Existing 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©.
     483Several 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
    503505\section{Exponentiation Operator}
    504506
    … …  
    516518256 64 -64 0.015625 -0.015625 18.3791736799526 0.264715-1.1922i
    517519\end{cfa}
    518 Parenthesis are necessary for the complex constants or the expression is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
     520Parenthesis are necessary for the complex constants or the expresion is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
    519521The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation versions are available.
    520522For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©;
    … …  
    522524
    523525
    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 
    532 The ©if© expression allows declarations, similar to ©for© declaration expression:
    533 \begin{cfa}
    534 if ( int x = f() ) ...                                          §\C{// x != 0}§
    535 if ( int x = f(), y = g() ) ...                         §\C{// x != 0 \&\& y != 0}§
    536 if ( int x = f(), y = g(); ®x < y® ) ...        §\C{// relational expression}§
    537 \end{cfa}
    538 Unless 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.}
    539 The 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 
    545 C allows a number of questionable forms for the ©switch© statement:
    546 \begin{enumerate}
    547 \item
    548 By default, the end of a ©case© clause\footnote{
    549 In 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;
    551 to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
    552 \begin{cfa}
    553 switch ( i ) {
    554   case 1:
    555         ...
    556         // fall-through
    557   case 2:
    558         ...
    559         break;  // exit switch statement
    560 }
    561 \end{cfa}
    562 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:
    563 \begin{cquote}
    564 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    565 \begin{cfa}
    566 switch ( 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 
    580 if ( 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}
    592 In this example, case 2 is always done if case 3 is done.
    593 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.
    594 C also uses fall-through to handle multiple case-values resulting in the same action:
    595 \begin{cfa}
    596 switch ( 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}
    605 However, this situation is handled in other languages without fall-through by allowing a list of case values.
    606 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.
    607 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.
    608 
    609 \item
    610 It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
    611 \begin{cfa}
    612 switch ( 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}
    627 The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
    628 The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
    629 The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
    630 There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
    631 Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
    632 \begin{cfa}
    633 register int n = (count + 7) / 8;
    634 switch ( count % 8 ) {
    635 case 0: do{ *to = *from++;
    636 case 7:         *to = *from++;
    637 case 6:         *to = *from++;
    638 case 5:         *to = *from++;
    639 case 4:         *to = *from++;
    640 case 3:         *to = *from++;
    641 case 2:         *to = *from++;
    642 case 1:         *to = *from++;
    643                 } while ( --n > 0 );
    644 }
    645 \end{cfa}
    646 which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
    647 While efficient, this sort of special purpose usage is questionable:
    648 \begin{quote}
    649 Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
    650 discovery.~\cite{Duff83}
    651 \end{quote}
    652 \item
    653 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.
    654 Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
    655 The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
    656 hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
    657 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.
    658 
    659 \item
    660 It is possible to place unreachable code at the start of a ©switch© statement, as in:
    661 \begin{cfa}
    662 switch ( 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}
    673 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.
    674 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.
    675 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.
    676 The 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 
    679 Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
    680 \begin{itemize}
    681 \item
    682 the number of ©switch© statements is small,
    683 \item
    684 most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
    685 \item
    686 the ©default© clause is usually written as the last case-clause,
    687 \item
    688 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.
    689 \end{itemize}
    690 These observations put into perspective the \CFA changes to the ©switch©.
    691 \begin{enumerate}
    692 \item
    693 Eliminating default fall-through has the greatest potential for affecting existing code.
    694 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:
    695 \begin{cfa}
    696 case 1:  case 2:  case 3: ...
    697 \end{cfa}
    698 still works.
    699 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.
    700 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:
    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}
    716 Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
    717 An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
    718 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.
    719 As 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.
    722 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.
    723 \item
    724 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.
    725 Therefore, no change is made for this issue.
    726 \item
    727 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{
    728 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.
    729 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
    730 \begin{cfa}
    731 switch ( 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 
    751 C restricts the ©case© clause of a ©switch© statement to a single value.
    752 For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
    753 Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
    754 Therefore, 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}
    759 switch ( i ) {
    760   case ®1, 3, 5®:
    761         ...
    762   case ®2, 4, 6®:
    763         ...
    764 }
    765 \end{cfa}
    766 &
    767 \begin{cfa}
    768 switch ( 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}
    786 In addition, subranges are allowed to specify case values.\footnote{
    787 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.}
    788 \begin{cfa}
    789 switch ( 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}
    796 Lists of subranges are also allowed.
    797 \begin{cfa}
    798 case ®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}}
     526\section{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
    804527
    805528While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
    … …  
    903626With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
    904627Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
    905 Otherwise, 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}}
     628The 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
     633C allows a number of questionable forms for the ©switch© statement:
     634\begin{enumerate}
     635\item
     636By default, the end of a ©case© clause\footnote{
     637In 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;
     639to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
     640\begin{cfa}
     641switch ( i ) {
     642  case 1:
     643        ...
     644        // fall-through
     645  case 2:
     646        ...
     647        break;  // exit switch statement
     648}
     649\end{cfa}
     650The 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}
     654switch ( 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
     668if ( 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}
     680In this example, case 2 is always done if case 3 is done.
     681This 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.
     682C also uses fall-through to handle multiple case-values resulting in the same action:
     683\begin{cfa}
     684switch ( 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}
     693However, this situation is handled in other languages without fall-through by allowing a list of case values.
     694While 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.
     695Hence, 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
     698It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
     699\begin{cfa}
     700switch ( 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}
     715The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
     716The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
     717The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
     718There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
     719Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
     720\begin{cfa}
     721register int n = (count + 7) / 8;
     722switch ( count % 8 ) {
     723case 0: do{ *to = *from++;
     724case 7:         *to = *from++;
     725case 6:         *to = *from++;
     726case 5:         *to = *from++;
     727case 4:         *to = *from++;
     728case 3:         *to = *from++;
     729case 2:         *to = *from++;
     730case 1:         *to = *from++;
     731                } while ( --n > 0 );
     732}
     733\end{cfa}
     734which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
     735While efficient, this sort of special purpose usage is questionable:
     736\begin{quote}
     737Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
     738discovery.~\cite{Duff83}
     739\end{quote}
     740\item
     741It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
     742Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
     743The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
     744hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
     745This 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
     748It is possible to place unreachable code at the start of a ©switch© statement, as in:
     749\begin{cfa}
     750switch ( 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}
     761While 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.
     762Furthermore, 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.
     763As 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.
     764The 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
     767Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
     768\begin{itemize}
     769\item
     770the number of ©switch© statements is small,
     771\item
     772most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
     773\item
     774the ©default© clause is usually written as the last case-clause,
     775\item
     776and 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}
     778These observations put into perspective the \CFA changes to the ©switch©.
     779\begin{enumerate}
     780\item
     781Eliminating default fall-through has the greatest potential for affecting existing code.
     782However, 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}
     784case 1:  case 2:  case 3: ...
     785\end{cfa}
     786still works.
     787Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
     788Therefore, 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}
     804Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
     805An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
     806An 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.
     807As 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.
     810Hence, 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
     812The 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.
     813Therefore, no change is made for this issue.
     814\item
     815Dealing 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{
     816Essentially, 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.
     817Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
     818\begin{cfa}
     819switch ( 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
     838C restricts the ©case© clause of a ©switch© statement to a single value.
     839For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
     840Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
     841Therefore, 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}
     846switch ( i ) {
     847  case ®1, 3, 5®:
     848        ...
     849  case ®2, 4, 6®:
     850        ...
     851}
     852\end{cfa}
     853&
     854\begin{cfa}
     855switch ( 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}
     873In addition, subranges are allowed to specify case values.\footnote{
     874gcc 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}
     876switch ( 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}
     883Lists of subranges are also allowed.
     884\begin{cfa}
     885case ®1~5, 12~21, 35~42®:
     886\end{cfa}
     887
     888
     889\section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
    910890\label{s:WithStatement}
    911891
    … …  
    922902\begin{cfa}
    923903void f( S s ) {
    924         ®s.®c; ®s.®i; ®s.®d;                                    §\C{// access containing fields}§
     904        `s.`c; `s.`i; `s.`d;                                    §\C{// access containing fields}§
    925905}
    926906\end{cfa}
    … …  
    933913        double d;
    934914        void f() {                                                              §\C{// implicit ``this'' aggregate}§
    935                 ®this->®c; ®this->®i; ®this->®d;        §\C{// access containing fields}§
     915                `this->`c; `this->`i; `this->`d;        §\C{// access containing fields}§
    936916        }
    937917}
    938918\end{C++}
    939 Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
     919Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]$this->$ because of lexical scoping.
    940920However, for other aggregate parameters, qualification is necessary:
    941921\begin{cfa}
    … …  
    943923int S::f( T & t ) {                                                     §\C{// multiple aggregate parameters}§
    944924        c; i; d;                                                                §\C{\color{red}// this--{\textgreater}.c, this--{\textgreater}.i, this--{\textgreater}.d}§
    945         ®t.®m; ®t.®n;                                                   §\C{// must qualify}§
    946 }
    947 \end{cfa}
    948 
    949 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.
     925        `t.`m; `t.`n;                                                   §\C{// must qualify}§
     926}
     927\end{cfa}
     928
     929To 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.
    950930Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block.
    951931\begin{cfa}
    952 void f( S & this ) ®with ( this )® {            §\C{// with statement}§
     932void f( S & this ) `with ( this )` {            §\C{// with statement}§
    953933        c; i; d;                                                                §\C{\color{red}// this.c, this.i, this.d}§
    954934}
    … …  
    956936with the generality of opening multiple aggregate-parameters:
    957937\begin{cfa}
    958 void f( S & s, T & t ) ®with ( s, t )® {        §\C{// multiple aggregate parameters}§
     938void f( S & s, T & t ) `with ( s, t )` {                §\C{// multiple aggregate parameters}§
    959939        c; i; d;                                                                §\C{\color{red}// s.c, s.i, s.d}§
    960940        m; n;                                                                   §\C{\color{red}// t.m, t.n}§
    … …  
    962942\end{cfa}
    963943
    964 In detail, the ©with© statement has the form:
     944In detail, the @with@ statement has the form:
    965945\begin{cfa}
    966946§\emph{with-statement}§:
    … …  
    977957The difference between parallel and nesting occurs for fields with the same name and type:
    978958\begin{cfa}
    979 struct S { int ®i®; int j; double m; } s, w;
    980 struct T { int ®i®; int k; int m; } t, w;
     959struct S { int `i`; int j; double m; } s, w;
     960struct T { int `i`; int k; int m; } t, w;
    981961with ( s, t ) {
    982962        j + k;                                                                  §\C{// unambiguous, s.j + t.k}§
    … …  
    989969}
    990970\end{cfa}
    991 For parallel semantics, both ©s.i© and ©t.i© are visible, so ©i© is ambiguous without qualification;
    992 for nested semantics, ©t.i© hides ©s.i©, so ©i© implies ©t.i©.
     971For parallel semantics, both @s.i@ and @t.i@ are visible, so @i@ is ambiguous without qualification;
     972for nested semantics, @t.i@ hides @s.i@, so @i@ implies @t.i@.
    993973\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.
    994974Qualification or a cast is used to disambiguate.
    995975
    996 There is an interesting problem between parameters and the function-body ©with©, \eg:
     976There is an interesting problem between parameters and the function-body @with@, \eg:
    997977\begin{cfa}
    998978void ?{}( S & s, int i ) with ( s ) {           §\C{// constructor}§
    999         ®s.i = i;®  j = 3;  m = 5.5;                    §\C{// initialize fields}§
    1000 }
    1001 \end{cfa}
    1002 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©.
     979        `s.i = i;`  j = 3;  m = 5.5;                    §\C{// initialize fields}§
     980}
     981\end{cfa}
     982Here, 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@.
    1003983To solve this problem, parameters are treated like an initialized aggregate:
    1004984\begin{cfa}
    … …  
    1010990and implicitly opened \emph{after} a function-body open, to give them higher priority:
    1011991\begin{cfa}
    1012 void ?{}( S & s, int ®i® ) with ( s ) ®with( §\emph{\color{red}params}§ )® {
    1013         s.i = ®i®; j = 3; m = 5.5;
    1014 }
    1015 \end{cfa}
    1016 Finally, a cast may be used to disambiguate among overload variables in a ©with© expression:
     992void ?{}( S & s, int `i` ) with ( s ) `with( §\emph{\color{red}params}§ )` {
     993        s.i = `i`; j = 3; m = 5.5;
     994}
     995\end{cfa}
     996Finally, a cast may be used to disambiguate among overload variables in a @with@ expression:
    1017997\begin{cfa}
    1018998with ( w ) { ... }                                                      §\C{// ambiguous, same name and no context}§
    1019999with ( (S)w ) { ... }                                           §\C{// unambiguous, cast}§
    10201000\end{cfa}
    1021 and ©with© expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
     1001and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
    10221002% \begin{cfa}
    10231003% struct S { int i, j; } sv;
    … …  
    10391019class C {
    10401020        int i, 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}§
     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}§
    10441024        }
    10451025}
    … …  
    10481028\begin{cfa}
    10491029struct S { int i, j; };
    1050 int mem( S & ®this® ) {                                         §\C{// explicit "this" parameter}§
    1051         ®this.®i = 1;                                                   §\C{// "this" is not elided}§
     1030int mem( S & ®this® ) {                 §\C{// explicit "this" parameter}§
     1031        ®this.®i = 1;                           §\C{// "this" is not elided}§
    10521032        ®this.®j = 2;
    10531033}
    … …  
    10571037\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.
    10581038\begin{cfa}
    1059 int mem( S & this ) ®with( this )® {            §\C{// with clause}§
    1060         i = 1;                                                                  §\C{\color{red}// this.i}§
    1061         j = 2;                                                                  §\C{\color{red}// this.j}§
     1039int mem( S & this ) ®with( this )® { §\C{// with clause}§
     1040        i = 1;                                          §\C{\color{red}// this.i}§
     1041        j = 2;                                          §\C{\color{red}// this.j}§
    10621042}
    10631043\end{cfa}
    … …  
    10761056        struct S1 { ... } s1;
    10771057        struct S2 { ... } s2;
    1078         ®with( s1 )® {                                                  §\C{// with statement}§
     1058        ®with( s1 )® {                          §\C{// with statement}§
    10791059                // access fields of s1 without qualification
    1080                 ®with s2® {                                                     §\C{// nesting}§
     1060                ®with s2® {                             §\C{// nesting}§
    10811061                        // access fields of s1 and s2 without qualification
    10821062                }
    … …  
    11331113Non-local transfer can cause stack unwinding, \ie non-local routine termination, depending on the kind of raise.
    11341114\begin{cfa}
    1135 exception_t E {};                                                       §\C{// exception type}§
     1115exception_t E {};                               §\C{// exception type}§
    11361116void f(...) {
    1137         ... throw E{}; ...                                              §\C{// termination}§
    1138         ... throwResume E{}; ...                                §\C{// resumption}§
     1117        ... throw E{}; ...                      §\C{// termination}§
     1118        ... throwResume E{}; ...        §\C{// resumption}§
    11391119}
    11401120try {
    11411121        f(...);
    1142 } catch( E e ; §boolean-predicate§ ) {          §\C[8cm]{// termination handler}§
     1122} catch( E e ; §boolean-predicate§ ) {                  §\C[8cm]{// termination handler}§
    11431123        // recover and continue
    1144 } catchResume( E e ; §boolean-predicate§ ) { §\C{// resumption handler}\CRT§
     1124} catchResume( E e ; §boolean-predicate§ ) {    §\C{// resumption handler}\CRT§
    11451125        // repair and return
    11461126} finally {
    … …  
    16621642\begin{itemize}
    16631643\item
    1664 if ©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
    1667 if ©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).
     1644if ©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
     1647if ©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).
    16681648\end{itemize}
    16691649The following example shows the first rule applied to different \Index{rvalue} contexts:
    … …  
    60195999
    60206000
    6021 \subsection{String to Value Conversion}
     6001\subsection{Conversion}
    60226002
    60236003\leavevmode
    … …  
    60896069\leavevmode
    60906070\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    6091 void srandom( unsigned int seed );§\indexc{srandom}§
    6092 char random( void );§\indexc{random}§
    6093 char random( char u );                                          §\C{// [0,u)}§
    6094 char random( char l, char u );                          §\C{// [l,u)}§
    6095 int random( void );
    6096 int random( int u );                                            §\C{// [0,u)}§
    6097 int random( int l, int u );                                     §\C{// [l,u)}§
    6098 unsigned int random( void );
    6099 unsigned int random( unsigned int u );          §\C{// [0,u)}§
    6100 unsigned int random( unsigned int l, unsigned int u ); §\C{// [l,u)}§
    6101 long int random( void );
    6102 long int random( long int u );                          §\C{// [0,u)}§
    6103 long int random( long int l, long int u );      §\C{// [l,u)}§
    6104 unsigned long int random( void );
    6105 unsigned long int random( unsigned long int u ); §\C{// [0,u)}§
    6106 unsigned long int random( unsigned long int l, unsigned long int u ); §\C{// [l,u)}§
    6107 float random( void );                                            §\C{// [0.0, 1.0)}§
    6108 double random( void );                                           §\C{// [0.0, 1.0)}§
    6109 float _Complex random( void );                           §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
    6110 double _Complex random( void );                          §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
    6111 long double _Complex random( void );             §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
     6071void rand48seed( long int s );§\indexc{rand48seed}§
     6072char rand48();§\indexc{rand48}§
     6073int rand48();
     6074unsigned int rand48();
     6075long int rand48();
     6076unsigned long int rand48();
     6077float rand48();
     6078double rand48();
     6079float _Complex rand48();
     6080double _Complex rand48();
     6081long double _Complex rand48();
    61126082\end{cfa}
    61136083
    … …  
    64886458
    64896459
    6490 \section{Time Keeping}
    6491 \label{s:TimeKeeping}
     6460\section{Time}
     6461\label{s:TimeLib}
    64926462
    64936463
    64946464%\subsection{\texorpdfstring{\protect\lstinline@Duration@}{Duration}}
    6495 \subsection{\texorpdfstring{\LstBasicStyle{Duration}}{Duration}}
     6465\subsection{\texorpdfstring{\LstKeywordStyle{\textmd{Duration}}}{Duration}}
    64966466\label{s:Duration}
    64976467
    … …  
    65426512
    65436513Duration abs( Duration rhs );
     6514
     6515forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Duration dur );
    65446516
    65456517Duration ?`ns( int64_t nsec );
    … …  
    65656537int64_t ?`d( Duration dur );
    65666538int64_t ?`w( Duration dur );
    6567 
    6568 Duration max( Duration lhs, Duration rhs );
    6569 Duration min( Duration lhs, Duration rhs );
    65706539\end{cfa}
    65716540
    65726541
    65736542%\subsection{\texorpdfstring{\protect\lstinline@\timeval@}{timeval}}
    6574 \subsection{\texorpdfstring{\LstBasicStyle{timeval}}{timeval}}
     6543\subsection{\texorpdfstring{\LstKeywordStyle{\textmd{timeval}}}{timeval}}
    65756544\label{s:timeval}
    65766545
    … …  
    65916560
    65926561
    6593 %\subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
    6594 \subsection{\texorpdfstring{\LstBasicStyle{timespec}}{timespec}}
     6562\subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
    65956563\label{s:timespec}
    65966564
    … …  
    66116579
    66126580
    6613 %\subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
    6614 \subsection{\texorpdfstring{\LstBasicStyle{itimerval}}{itimerval}}
     6581\subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
    66156582\label{s:itimerval}
    66166583
    … …  
    66226589
    66236590
    6624 %\subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
    6625 \subsection{\texorpdfstring{\LstBasicStyle{Time}}{Time}}
     6591\subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
    66266592\label{s:Time}
    66276593
    … …  
    66346600void ?{}( Time & time );
    66356601void ?{}( Time & time, zero_t );
    6636 
     6602void ?{}( Time & time, int year, int month = 0, int day = 0, int hour = 0, int min = 0, int sec = 0, int nsec = 0 );
    66376603Time ?=?( Time & time, zero_t );
    66386604
    … …  
    66436609Time ?=?( Time & time, timespec t );
    66446610
    6645 Time ?+?( Time & lhs, Duration rhs );
    6646 Time ?+?( Duration lhs, Time rhs );
    6647 Time ?+=?( Time & lhs, Duration rhs );
    6648 
    6649 Duration ?-?( Time lhs, Time rhs );
    6650 Time ?-?( Time lhs, Duration rhs );
    6651 Time ?-=?( 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 );
     6611Time ?+?( Time & lhs, Duration rhs ) { return (Time)@{ lhs.tv + rhs.tv }; }
     6612Time ?+?( Duration lhs, Time rhs ) { return rhs + lhs; }
     6613Time ?+=?( Time & lhs, Duration rhs ) { lhs = lhs + rhs; return lhs; }
     6614
     6615Duration ?-?( Time lhs, Time rhs ) { return (Duration)@{ lhs.tv - rhs.tv }; }
     6616Time ?-?( Time lhs, Duration rhs ) { return (Time)@{ lhs.tv - rhs.tv }; }
     6617Time ?-=?( 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
     6625forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
    66586626
    66596627char * yy_mm_dd( Time time, char * buf );
    … …  
    66736641
    66746642size_t strftime( char * buf, size_t size, const char * fmt, Time time );
    6675 forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
    66766643\end{cfa}
    66776644
    … …  
    66946661
    66956662%\subsection{\texorpdfstring{\protect\lstinline@Clock@}{Clock}}
    6696 \subsection{\texorpdfstring{\LstBasicStyle{Clock}}{Clock}}
     6663\subsection{\texorpdfstring{\LstKeywordStyle{\textmd{Clock}}}{Clock}}
    66976664\label{s:Clock}
    66986665
    … …  
    67086675void ?{}( Clock & clk );
    67096676void ?{}( Clock & clk, Duration adj );
    6710 
    6711 Duration getResNsec();                                  §\C{// with nanoseconds}§
    6712 Duration getRes();                                              §\C{// without nanoseconds}§
    6713 
     6677Duration getRes();
    67146678Time getTimeNsec();                                             §\C{// with nanoseconds}§
    67156679Time getTime();                                                 §\C{// without nanoseconds}§
Note: See TracChangeset for help on using the changeset viewer.