Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/user/user.tex

    re80ebe5 r5479e63  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Tue Aug  2 17:39:02 2016
    14 %% Update Count     : 1286
     13%% Last Modified On : Wed Jul 13 08:14:39 2016
     14%% Update Count     : 1247
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    211211however, it largely extended the language, and did not address many existing problems.\footnote{%
    212212Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
    213 \Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
     213\Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (e.g., objects, concurrency) are added and problems fixed within the framework of the existing language.
    214214\Index*{Java}~\cite{Java8}, \Index*{Go}~\cite{Go}, \Index*{Rust}~\cite{Rust} and \Index*{D}~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
    215215These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
    … …  
    226226
    227227\section{Interoperability}
    228 \label{s:Interoperability}
    229228
    230229\CFA is designed to integrate well with existing C programs and libraries.
    … …  
    266265\section[Compiling CFA Program]{Compiling \CFA Program}
    267266
    268 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
     267The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, e.g.:
    269268\begin{lstlisting}
    270269cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
    … …  
    315314The \CFA compilation message is printed at the beginning of a compilation.
    316315\textbf{This option is the default.}
    317 
    318 \item
    319 \Indexc{-no-include-std}\index{compilation option!-no-include-std@©-no-include-std©}
    320 Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
    321 \textbf{This option is \emph{not} the default.}
    322316\end{description}
    323317
    … …  
    356350\section{Underscores in Constants}
    357351
    358 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
     352Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.:
    359353\begin{lstlisting}
    3603542®_®147®_®483®_®648;                    §\C{// decimal constant}§
    … …  
    372366\begin{enumerate}
    373367\item
    374 A sequence of underscores is disallowed, \eg ©12__34© is invalid.
     368A sequence of underscores is disallowed, e.g., ©12__34© is invalid.
    375369\item
    376370Underscores may only appear within a sequence of digits (regardless of the digit radix).
    377 In other words, an underscore cannot start or end a sequence of digits, \eg ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).
     371In other words, an underscore cannot start or end a sequence of digits, e.g., ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).
    378372\item
    379373A numeric prefix may end with an underscore;
    … …  
    504498\end{quote2}
    505499
    506 All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
     500All type qualifiers, e.g., ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, e.g.:
    507501\begin{quote2}
    508502\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
    … …  
    524518\end{tabular}
    525519\end{quote2}
    526 All declaration qualifiers, \eg ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
    527 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg:
     520All declaration qualifiers, e.g., ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
     521The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} e.g.:
    528522\begin{quote2}
    529523\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    … …  
    548542Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{
    549543At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}}
    550 \eg:
     544e.g.:
    551545\begin{lstlisting}
    552546x;                                                              §\C{// int x}§
    … …  
    618612A \Index{pointer}/\Index{reference} is a generalization of a variable name, i.e., a mutable address that can point to more than one memory location during its lifetime.
    619613(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and may not occupy storage as the literal is embedded directly into instructions.)
    620 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
     614Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.:
    621615\begin{quote2}
    622616\begin{tabular}{@{}ll@{}}
    … …  
    675669Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
    676670Hence, a reference behaves like the variable name for the current variable it is pointing-to.
    677 The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg:
     671The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, e.g.:
    678672\begin{lstlisting}
    679673r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);
    … …  
    683677®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
    684678\end{lstlisting}
    685 When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{
     679When a reference operation appears beside a dereference operation, e.g., ©&*©, they cancel out.\footnote{
    686680The unary ©&© operator yields the address of its operand.
    687681If the operand has type ``type'', the result has type ``pointer to type''.
    … …  
    727721®&®crc = &cx;                                   §\C{// error, cannot change crc}§
    728722\end{lstlisting}
    729 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg:
     723Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, e.g.:
    730724\begin{lstlisting}
    731725int & const r = *0;                             §\C{// where 0 is the int * zero}§
    732726\end{lstlisting}
    733727Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented.
    734 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
    735 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
    736 \CFA-style declarations attempt to address this issue:
    737 \begin{quote2}
    738 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    739 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    740 \begin{lstlisting}
    741 ®const® * ®const® * const int ccp;
    742 ®const® & ®const® & const int ccr;
    743 \end{lstlisting}
    744 &
    745 \begin{lstlisting}
    746 const int * ®const® * ®const® ccp;
    747 
    748 \end{lstlisting}
    749 \end{tabular}
    750 \end{quote2}
    751 where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).
    752728
    753729\Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object.
    … …  
    809785\section{Type Operators}
    810786
    811 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
     787The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine ©sizeof©:
    812788\begin{quote2}
    813789\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    … …  
    829805
    830806\CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
    831 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
     807The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, e.g.:
    832808\begin{lstlisting}
    833809®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
    … …  
    841817\Index*{Michael Tiemann}, with help from \Index*{Doug Lea}, provided named return values in g++, circa 1989.}
    842818The value of each local return variable is automatically returned at routine termination.
    843 Declaration qualifiers can only appear at the start of a routine definition, \eg:
     819Declaration qualifiers can only appear at the start of a routine definition, e.g.:
    844820\begin{lstlisting}
    845821®extern® [ int x ] g( int y ) {§\,§}
    … …  
    873849The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts.
    874850
    875 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
     851C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.:
    876852\begin{lstlisting}
    877853[ int ] f( * int, int * );              §\C{// returns an integer, accepts 2 pointers to integers}§
    … …  
    922898
    923899The syntax of the new routine prototype declaration follows directly from the new routine definition syntax;
    924 as well, parameter names are optional, \eg:
     900as well, parameter names are optional, e.g.:
    925901\begin{lstlisting}
    926902[ int x ] f ();                                 §\C{// returning int with no parameters}§
    … …  
    930906\end{lstlisting}
    931907This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
    932 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg:
     908It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), e.g.:
    933909\begin{quote2}
    934910\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    … …  
    943919\end{tabular}
    944920\end{quote2}
    945 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
     921Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} e.g.:
    946922\begin{lstlisting}
    947923extern [ int ] f (int);
    … …  
    952928\section{Routine Pointers}
    953929
    954 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
     930The syntax for pointers to \CFA routines specifies the pointer name on the right, e.g.:
    955931\begin{lstlisting}
    956932* [ int x ] () fp;                      §\C{// pointer to routine returning int with no parameters}§
    … …  
    10701046p( /* positional */, /* named */, . . . );
    10711047\end{lstlisting}
    1072 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:
     1048While it is possible to implement both approaches, the first possibly is more complex than the second, e.g.:
    10731049\begin{lstlisting}
    10741050p( int x, int y, int z, . . . );
    … …  
    10801056In the second call, the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
    10811057
    1082 The problem is exacerbated with default arguments, \eg:
     1058The problem is exacerbated with default arguments, e.g.:
    10831059\begin{lstlisting}
    10841060void p( int x, int y = 2, int z = 3. . . );
    … …  
    12881264
    12891265As mentioned, tuples can appear in contexts requiring a list of value, such as an argument list of a routine call.
    1290 In unambiguous situations, the tuple brackets may be omitted, \eg a tuple that appears as an argument may have its
     1266In unambiguous situations, the tuple brackets may be omitted, e.g., a tuple that appears as an argument may have its
    12911267square brackets omitted for convenience; therefore, the following routine invocations are equivalent:
    12921268\begin{lstlisting}
    … …  
    13271303
    13281304Type qualifiers, i.e., const and volatile, may modify a tuple type.
    1329 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, \eg:
     1305The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, e.g.:
    13301306\begin{lstlisting}
    13311307const volatile [ int, float, const int ] x;
    … …  
    13351311[ const volatile int, const volatile float, const volatile int ] x;
    13361312\end{lstlisting}
    1337 Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg:
     1313Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, e.g.:
    13381314\begin{lstlisting}
    13391315extern [ int, int ] w1;
    … …  
    13431319Unfortunately, C's syntax for subscripts precluded treating them as tuples.
    13441320The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©.
    1345 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg ©f[g()]© always means a single subscript value because there is only one set of brackets.
     1321Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., ©f[g()]© always means a single subscript value because there is only one set of brackets.
    13461322Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression.
    13471323\end{rationale}
    … …  
    14041380Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
    14051381
    1406 Mass assignment has parallel semantics, \eg the statement:
     1382Mass assignment has parallel semantics, e.g., the statement:
    14071383\begin{lstlisting}
    14081384[ x, y, z ] = 1.5;
    … …  
    14931469\section{Unnamed Structure Fields}
    14941470
    1495 C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg:
     1471C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.:
    14961472\begin{lstlisting}
    14971473struct {
    1498         int f1;                                 §\C{// named field}§
    1499         int f2 : 4;                             §\C{// named field with bit field size}§
    1500         int : 3;                                §\C{// unnamed field for basic type with bit field size}§
    1501         int ;                                   §\C{// disallowed, unnamed field}§
    1502         int *;                                  §\C{// disallowed, unnamed field}§
    1503         int (*)(int);                   §\C{// disallowed, unnamed field}§
     1474        int f1;                 // named field
     1475        int f2 : 4;             // named field with bit field size
     1476        int : 3;                // unnamed field for basic type with bit field size
     1477        int ;                   // disallowed, unnamed field
     1478        int *;                  // disallowed, unnamed field
     1479        int (*)(int);   // disallowed, unnamed field
    15041480};
    15051481\end{lstlisting}
    15061482This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
    15071483As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
    1508 A list of unnamed fields is also supported, \eg:
     1484A list of unnamed fields is also supported, e.g.:
    15091485\begin{lstlisting}
    15101486struct {
    1511         int , , ;                               §\C{// 3 unnamed fields}§
     1487        int , , ;               // 3 unnamed fields
    15121488}
    15131489\end{lstlisting}
    … …  
    15221498§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
    15231499\end{lstlisting}
    1524 \emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©.
     1500\emph{expr} is any expression yielding a value of type record, e.g., ©struct©, ©union©.
    15251501Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
    15261502A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
    … …  
    17841760}
    17851761\end{lstlisting}
    1786 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.
    1787 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.
    1788 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.
    1789 The key observation is that the ©switch© statement branches into control structure, i.e., there are multiple entry points into its statement body.
     1762While the declaration of the local variable ©y© is useful and its scope is across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
     1763Furthermore, 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©.
     1764As mentioned, transfer into control structures should be forbidden;
     1765transfers from within the ©switch© body using a ©goto© are equally unpalatable.
     1766As well, the declaration of ©z© is 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.
    17901767\end{enumerate}
    17911768
    … …  
    18011778and 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.
    18021779\end{itemize}
    1803 These observations help to put the \CFA changes to the ©switch© into perspective.
     1780These observations help to put the suggested changes to the ©switch© into perspective.
    18041781\begin{enumerate}
    18051782\item
    18061783Eliminating default fall-through has the greatest potential for affecting existing code.
    1807 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, i.e., a list of ©case© clauses executing common code, \eg:
    1808  \begin{lstlisting}
     1784However, 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, i.e., a list of ©case© clauses executing common code, e.g.:
     1785\begin{lstlisting}
    18091786case 1:  case 2:  case 3: ...
    18101787\end{lstlisting}
    18111788still work.
    18121789Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
    1813 <<<<<<< HEAD
    1814 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 ©fallthru©, \eg:
    1815 =======
    1816 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©, e.g.:
    1817 >>>>>>> 080615890f586cb9954c252b55cab47f52c25758
     1790Therefore, 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 ©fallthru©, e.g.:
    18181791\begin{lstlisting}
    18191792®choose® ( i ) {
    … …  
    18421815Therefore, no change is made for this issue.
    18431816\item
    1844 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{
    1845 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.
    1846 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
     1817Dealing 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{
     1818Essentially, these declarations are hoisted before the statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
     1819Further declaration in the statement body are disallowed.
    18471820\begin{lstlisting}
    18481821switch ( x ) {
    1849         ®int i = 0;®                            §\C{// allowed only at start}§
     1822        ®int i = 0;®                            §\C{// allowed}§
    18501823  case 0:
    18511824        ...
    1852         ®int j = 0;®                            §\C{// disallowed}§
     1825        ®int i = 0;®                            §\C{// disallowed}§
    18531826  case 1:
    18541827    {
    1855                 ®int k = 0;®                    §\C{// allowed at different nesting levels}§
     1828                ®int i = 0;®                    §\C{// allowed in any compound statement}§
    18561829                ...
    18571830        }
    … …  
    27342707Like the \Index*[C++]{\CC} lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
    27352708
    2736 There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
    2737 Since it is common practise to put a unary operator juxtaposed to an identifier, \eg ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.
     2709There are several ambiguous cases with operator identifiers, e.g., ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
     2710Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.
    27382711Even with this special hack, there are 5 general cases that cannot be handled.
    27392712The first case is for the function-call identifier ©?()©:
    … …  
    28002773This means that a function requiring mutual exclusion could block if the lock is already held by another thread.
    28012774Blocking on a monitor lock does not block the kernel thread, it simply blocks the user thread, which yields its kernel thread while waiting to obtain the lock.
    2802 If multiple mutex parameters are specified, they will be locked in parameter order (\ie first parameter is locked first) and unlocked in the
     2775If multiple mutex parameters are specified, they will be locked in parameter order (i.e. first parameter is locked first) and unlocked in the
    28032776reverse order.
    28042777\begin{lstlisting}
    … …  
    43694342
    43704343
    4371 \section{New Keywords}
    4372 \label{s:NewKeywords}
    4373 
    4374 \begin{quote2}
    4375 \begin{tabular}{ll}
    4376 ©catch©                 & ©lvalue©              \\
    4377 ©catchResume©   &                               \\
    4378 ©choose©                & ©otype©               \\
    4379                                 &                               \\
    4380 ©disable©               & ©throw©               \\
    4381 ©dtype©                 & ©throwResume© \\
    4382                                 & ©trait©               \\
    4383 ©enable©                & ©try©                 \\
    4384                                 &                               \\
    4385 ©fallthrough©                                   \\
    4386 ©fallthru©                                              \\
    4387 ©finally©                                               \\
    4388 ©forall©                                                \\
    4389 ©ftype©                                                 \\
    4390 \end{tabular}
    4391 \end{quote2}
    4392 
    4393 
    4394 \section{Standard Headers}
    4395 \label{s:StandardHeaders}
    4396 
    4397 C prescribes the following standard header-files:
    4398 \begin{quote2}
    4399 \begin{minipage}{\linewidth}
    4400 \begin{tabular}{lll}
    4401 assert.h        & math.h                & stdlib.h              \\
    4402 complex.h       & setjmp.h              & stdnoreturn.h \\
    4403 ctype.h         & signal.h              & string.h              \\
    4404 errno.h         & stdalign.h    & tgmath.h              \\
    4405 fenv.h          & stdarg.h              & threads.h             \\
    4406 float.h         & stdatomic.h   & time.h                \\
    4407 inttypes.h      & stdbool.h             & uchar.h               \\
    4408 iso646.h        & stddef.h              & wchar.h               \\
    4409 limits.h        & stdint.h              & wctype.h              \\
    4410 locale.h        & stdio.h               & unistd.h\footnote{\CFA extension}
    4411 \end{tabular}
    4412 \end{minipage}
    4413 \end{quote2}
    4414 For the prescribed head-files, \CFA implicit wraps their includes in an ©extern "C"©;
    4415 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
    4416 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
    4417 
    4418 
    44194344\section{Incompatible}
    44204345
    … …  
    44244349\item
    44254350\begin{description}
    4426 \item[Change:] add new keywords (see~\VRef{s:NewKeywords}) \\
     4351\item[Change:] add new keywords \\
    44274352New keywords are added to \CFA.
    44284353\item[Rationale:] keywords added to implement new semantics of \CFA.
    … …  
    45224447\begin{description}
    45234448\item[Change:] have ©struct© introduce a scope for nested types
    4524 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing
     4449In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing 
    45254450Example:
    45264451\begin{lstlisting}
    … …  
    45464471\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
    45474472Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
    4548 Given that nested types in C are equivalent to not using them, \ie they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
     4473Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
    45494474\end{description}
    45504475
    … …  
    46454570%$
    46464571\begin{lstlisting}[mathescape=off]
    4647 sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¡" | 7
    4648          | "x ¿" | 8 | "x «" | 9 | endl;
     4572sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¡" | 7 | "x ¿" | 8 | "x «" | 9 | endl;
    46494573\end{lstlisting}
    46504574%$
    … …  
    46564580A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»©
    46574581\begin{lstlisting}[belowskip=0pt]
    4658 sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7
    4659          | ") x" | 8 | "] x" | 9 | "} x" | 10 | "% x" | 11 | "¢ x" | 12 | "» x" | endl;
     4582sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"
     4583         | 10 | "% x" | 11 | "¢ x" | 12 | "» x" | endl;
    46604584\end{lstlisting}
    46614585\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46734597The following \CC-style \Index{manipulator}s allow further control over implicit seperation.
    46744598\begin{lstlisting}[mathescape=off,belowskip=0pt]
    4675 sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start of line}§
     4599sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
    46764600\end{lstlisting}
    46774601\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46794603\end{lstlisting}
    46804604\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    4681 sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// turn off implicit separator temporarily}§
     4605sout | 1 | sepOff | 2 | 3 | endl;                       // turn off implicit separator temporarily
    46824606\end{lstlisting}
    46834607\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46854609\end{lstlisting}
    46864610\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    4687 sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// turn off implicit separation, affects all subsequent prints}§
     4611sout | sepDisable | 1 | 2 | 3 | endl;           // turn off implicit separation, affects all subsequent prints
    46884612\end{lstlisting}
    46894613\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46914615\end{lstlisting}
    46924616\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    4693 sout | 1 | sepOn | 2 | 3 | endl;                        §\C{// turn on implicit separator temporarily}§
     4617sout | 1 | sepOn | 2 | 3 | endl;                        // turn on implicit separator temporarily
    46944618\end{lstlisting}
    46954619\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46974621\end{lstlisting}
    46984622\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    4699 sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// turn on implicit separation, affects all subsequent prints}§
     4623sout | sepEnable | 1 | 2 | 3 | endl;            // turn on implicit separation, affects all subsequent prints
    47004624\end{lstlisting}
    47014625\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    47034627\end{lstlisting}
    47044628\begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
    4705 sepSet( sout, ", $" );                                          §\C{// change separator from " " to ", \$"}§
     4629sepSet( sout, ", $" );                                          // change separator from " " to ", $"
    47064630sout | 1 | 2 | 3 | endl;
    47074631\end{lstlisting}
    … …  
    52385162\label{s:RationalNumbers}
    52395163
    5240 Rational numbers are numbers written as a ratio, \ie as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.
     5164Rational numbers are numbers written as a ratio, i.e., as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.
    52415165When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
    52425166
Note: See TracChangeset for help on using the changeset viewer.