Context Navigation

-                      r4438281
+                      re9bb0e5
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Fri Jul  7 10:36:39 2017
 %% Update Count     : 2547
+%% Last Modified On : Thu Jul 13 07:08:58 2017
+%% Update Count     : 2673
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \CFAStyle                                                                                               % use default CFA format-style
+\lstnewenvironment{C++}[1][]
+{\lstset{language=C++,moredelim=**[is][\protect\color{red}]{®}{®}#1}}
+{}
 % inline code ©...© (copyright symbol) emacs: C-q M-)
 % red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
 …
 \CFA{}\index{cforall@\CFA}\footnote{Pronounced ``\Index*{C-for-all}'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed as an evolutionary step forward for the C programming language.
 The syntax of the \CFA language builds from C, and should look immediately familiar to C/\Index*[C++]{\CC{}} programmers.
+The syntax of \CFA builds from C and should look immediately familiar to C/\Index*[C++]{\CC{}} programmers.
 % Any language feature that is not described here can be assumed to be using the standard \Celeven syntax.
 \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 C performance.
 Like C, \CFA is a statically typed, procedural 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.
+\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.
+Like 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.
 The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
+One of the main design philosophies of \CFA is to ``describe not prescribe'', which means \CFA tries to provide a pathway from low-level C programming to high-level \CFA programming, but it does not force programmers to ``do the right thing''.
+Programmers can cautiously add \CFA extensions to their C programs in any order and at any time to incrementally move towards safer, higher-level programming features.
+A programmer is always free to reach back to C from \CFA for any reason, and in many cases, new \CFA features have a fallback to a C mechanism.
+There is no notion or requirement for rewriting a legacy C program in \CFA;
+instead, a programmer evolves an existing C program into \CFA by incrementally incorporating \CFA features.
+New programs can be written in \CFA using a combination of C and \CFA features.
+\Index*[C++]{\CC{}} had a similar goal 30 years ago, but currently has the disadvantages of 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.
+One of the main design philosophies of \CFA is to ``\Index{describe not prescribe}'', which means \CFA tries to provide a pathway from low-level C programming to high-level \CFA programming, but it does not force programmers to ``do the right thing''.
+Programmers can cautiously add \CFA extensions to their C programs in any order and at any time to incrementally move towards safer, higher-level programming.
+A programmer is always free to reach back to C from \CFA, for any reason, and in many cases, new \CFA features can be locally switched back to there C counterpart.
+There is no notion or requirement for \emph{rewriting} a legacy C program in \CFA;
+instead, a programmer evolves a legacy program into \CFA by incrementally incorporating \CFA features.
+As well, new programs can be written in \CFA using a combination of C and \CFA features.
+\Index*[C++]{\CC{}} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
+However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, all of which requires significant effort and training to incrementally add \CC to a C-based project.
 In contrast, \CFA has 30 years of hindsight and a clean starting point.
 …
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}}
+\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
+\begin{cfa}
+#include <fstream>§\indexc{fstream}§
+int main( void ) {
+        int x = 0, y = 1, z = 2;
+        ®sout | x | y | z | endl;®
+}
+\end{cfa}
+&
+\begin{lstlisting}
+\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{C}} & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
+\begin{cfa}
 #include <stdio.h>§\indexc{stdio.h}§
 …
         ®printf( "%d %d %d\n", x, y, z );®
+}
 \end{lstlisting}
+\end{cfa}
+&
+\begin{lstlisting}
+\begin{cfa}
+#include <fstream>§\indexc{fstream}§
+int main( void ) {
+        int x = 0, y = 1, z = 2;
+        ®sout | x | y | z | endl;®§\indexc{sout}§
+}
+\end{cfa}
+&
+\begin{cfa}
 #include <iostream>§\indexc{iostream}§
 using namespace std;
 …
         ®cout<<x<<" "<<y<<" "<<z<<endl;®
+}
 \end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
 While 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}).
+\subsection{Background}
 This document is a programmer reference-manual for the \CFA programming language.
 The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of each feature.
 The manual does not teach programming, i.e., how to combine the new constructs to build complex programs.
 A reader should already have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented as well as some experience programming in C/\CC.
 Implementers may refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
+A reader should already have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
+Implementers should refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
 Changes to the syntax and additional features are expected to be included in later revisions.
 …
 This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
 Even with all its problems, C continues to be popular because it allows writing software at virtually any level in a computer system without restriction.
 For system programming, where direct access to hardware and dealing with real-time issues is a requirement, C is usually the language of choice.
+For system programming, where direct access to hardware, storage management, and real-time issues are a requirement, C is usually the only language of choice.
 The TIOBE index~\cite{TIOBE} for March 2016 showed the following programming-language popularity: \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC{}} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, where the next 50 languages are less than 3\% each with a long tail.
 As well, for 30 years, C has been the number 1 and 2 most popular programming language:
 …
 \end{center}
 Hence, 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.
 Love it or hate it, C has been an important and influential part of computer science for 40 years and sit appeal is not diminishing.
 Unfortunately, C has too many problems and omissions to make it an acceptable programming language for modern needs.
 As stated, the goal of the \CFA project is to engineer modern language features into C in an evolutionary rather than revolutionary way.
+Love it or hate it, C has been an important and influential part of computer science for 40 years and its appeal is not diminishing.
+Unfortunately, C has many problems and omissions that make it an unacceptable programming language for modern needs.
+As stated, the goal of the \CFA project is to engineer modern language-features into C in an evolutionary rather than revolutionary way.
 \CC~\cite{C++14,C++} is an example of a similar project;
 however, it largely extended the language, and did not address many existing problems.\footnote{%
+however, it largely extended the C language, and did not address most of C's existing problems.\footnote{%
 Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
 \Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
+\Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language-features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
 \Index*{Java}~\cite{Java8}, \Index*{Go}~\cite{Go}, \Index*{Rust}~\cite{Rust} and \Index*{D}~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
 These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
+These languages have different syntax and semantics from C, do not interoperate directly with C, and are not systems languages because of restrictive memory-management or garbage collection.
 As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
 These costs can be prohibitive for many companies with a large software base in C/\CC, and a significant number of programmers requiring retraining to a new programming language.
 The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixing some of the well known C problems and containing many modern language features.
+These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining to the new programming language.
+The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while containing modern language-features.
 Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
 as a result, it will fade into disuse.
 Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
 While \Index*[C11]{\Celeven{}} made a few simple extensions to the language, nothing was added to address existing problems in the language or to augment the language with modern language features.
 While some may argue that modern language features may make C complex and inefficient, it is clear a language without modern capabilities is insufficient for the advanced programming problems existing today.
+While \Index*[C11]{\Celeven{}} made a few simple extensions to the language, nothing was added to address existing problems in the language or to augment the language with modern language-features.
+While some may argue that modern language-features may make C complex and inefficient, it is clear a language without modern capabilities is insufficient for the advanced programming problems existing today.
 \section{History}
 The \CFA project started with \Index*{K-W C}~\cite{Buhr94a,Till89}, which extended C with new declaration syntax, multiple return values from routines, and extended assignment capabilities using the notion of tuples.
+The \CFA project started with \Index*{K-W C}~\cite{Buhr94a,Till89}, which extended C with new declaration syntax, multiple return values from routines, and advanced assignment capabilities using the notion of tuples.
 (See~\cite{Werther96} for similar work in \Index*[C++]{\CC{}}.)
+A first \CFA implementation of these extensions was by Esteves~\cite{Esteves04}.
+The signature feature of \CFA is parametric-polymorphic functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a ©forall© clause (giving the language its name):
+The first \CFA implementation of these extensions was by Esteves~\cite{Esteves04}.
+The signature feature of \CFA is \Index{overload}able \Index{parametric-polymorphic} functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a ©forall© clause (giving the language its name):
 \begin{lstlisting}
 ®forall( otype T )® T identity( T val ) { return val; }
 …
 \CFA{}\hspace{1pt}'s polymorphism was originally formalized by Ditchfiled~\cite{Ditchfield92}, and first implemented by Bilson~\cite{Bilson03}.
 However, at that time, there was little interesting in extending C, so work did not continue.
 As the saying goes, ``What goes around, comes around.'', and there is now renewed interest in the C programming language because of legacy code-bases, so the \CFA project has been restarted.
+As the saying goes, ``\Index*{What goes around, comes around.}'', and there is now renewed interest in the C programming language because of legacy code-bases, so the \CFA project has been restarted.
 …
 \CFA is designed to integrate directly with existing C programs and libraries.
 The most important feature of \Index{interoperability} is using the same \Index{calling convention}s, so there is no overhead to call existing C routines.
+The most important feature of \Index{interoperability} is using the same \Index{calling convention}s, so there is no complex interface or overhead to call existing C routines.
 This feature allows \CFA programmers to take advantage of the existing panoply of C libraries to access thousands of external software features.
 Language developers often state that adequate \Index{library support} takes more work than designing and implementing the language itself.
 Fortunately, \CFA, like \Index*[C++]{\CC{}}, starts with immediate access to all exiting C libraries, and in many cases, can easily wrap library routines with simpler and safer interfaces, at very low cost.
 Hence, \CFA begins by leveraging the large repository of C libraries with little cost.
+Hence, \CFA begins by leveraging the large repository of C libraries at little cost.
 \begin{comment}
 …
 \end{comment}
 However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
+However, it is necessary to differentiate between C and \CFA code because of name \Index{overload}ing, as for \CC.
 For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
 Whereas, \CFA wraps each of these routines into ones with the common name ©abs©:
+Whereas, \CFA wraps each of these routines into ones with the overloaded name ©abs©:
 \begin{cfa}
 char abs( char );
 …
 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.
 There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
 This example strongly illustrates a core idea in \CFA: \emph{the power of a name}.
+This example strongly illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
 The name ``©abs©'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
 Hence, knowing the name ©abs© should be sufficient to apply it to any type where it is applicable.
 The time savings and safety of using one name uniformly versus $N$ unique names should not be underestimated.
 \section[Compiling CFA Program]{Compiling \CFA Program}
+Hence, knowing the name ©abs© is sufficient to apply it to any type where it is applicable.
+The time savings and safety of using one name uniformly versus $N$ unique names cannot be underestimated.
+\section[Compiling a CFA Program]{Compiling a \CFA Program}
 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
 \begin{cfa}
 cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
+cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA{}§-files [ assembler/loader-files ]
 \end{cfa}
 \CFA programs having the following ©gcc© flags turned on:
 …
 \Indexc{-debug}\index{compilation option!-debug@©-debug©}
 The program is linked with the debugging version of the runtime system.
 The debug version performs runtime checks to help during the debugging phase of a \CFA program, but substantially slows the execution of the program.
+The debug version performs runtime checks to help during the debugging phase of a \CFA program, but can substantially slow program execution.
 The runtime checks should only be removed after the program is completely debugged.
 \textbf{This option is the default.}
 …
 \end{description}
 These preprocessor variables allow conditional compilation of programs that must work differently in these situations.
 For example, to toggle between C and \CFA extensions, using the following:
+For example, to toggle between C and \CFA extensions, use the following:
 \begin{cfa}
 #ifndef __CFORALL__
 …
 \section{Constants Underscores}
 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
+\section{Constant Underscores}
+Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore}, \eg:
 \begin{cfa}
 ®_®147®_®483®_®648;                                    §\C{// decimal constant}§
 …
 L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
 \end{cfa}
 The rules for placement of underscores is as follows:
 \begin{enumerate}
+The rules for placement of underscores are:
+\begin{enumerate}[topsep=5pt,itemsep=5pt,parsep=0pt]
 \item
 A sequence of underscores is disallowed, \eg ©12__34© is invalid.
 …
 \label{s:BackquoteIdentifiers}
+\CFA accommodates keyword clashes with existing C variable-names by syntactic transformations using the \CFA backquote escape-mechanism:
+\CFA introduces in new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
+Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
 \begin{cfa}
 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
 …
 While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
 Unfortunately, this restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
 To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@\lstinline $continue$!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@\lstinline $break$!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}.
+To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@\lstinline $continue$!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@\lstinline $break$!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85}.
 For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
 for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
 \VRef[Figure]{f:MultiLevelResumeTermination} shows the labelled ©continue© and ©break©, specifying which control structure is the target for exit, and the corresponding C program using only ©goto©.
 The innermost loop has 7 exit points, which cause resumption or termination of one or more of the 7 \Index{nested control-structure}s.
+Java supports both labelled ©continue© and ©break© statements.
 \begin{figure}
 …
         ®// open input file
 ®} else if ( argc == 2 ) {
         ®// open input file
+        ®// open input file (duplicate)
 ®} else {
 …
 \begin{cfa}
 switch ( i ) {
   case 1: case 3: case 5:       // odd values
         // same action
+  ®case 1: case 3: case 5:®     // odd values
+        // odd action
         break;
   case 2: case 4: case 6:       // even values
         // same action
+  ®case 2: case 4: case 6:®     // even values
+        // even action
         break;
+}
 …
 However, this situation is handled in other languages without fall-through by allowing a list of case values.
 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.
 Hence, default fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
+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.
 \item
 …
 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.
 \end{itemize}
 These observations help to put the \CFA changes to the ©switch© into perspective.
+These observations put into perspective the \CFA changes to the ©switch©.
 \begin{enumerate}
 \item
 …
   case 7:
         ...
         ®break®                                         §\C{// explicit end of switch}§
+        ®break®                                         §\C{// redundant explicit end of switch}§
   default:
         j = 3;
 …
 \end{cfa}
 Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
 the implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
 The 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.
+An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
+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.
 As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
 \item
 …
 \end{cfa}
+\section{\protect\lstinline{with} Clause / Statement}
+\label{s:WithClauseStatement}
+In \Index{object-oriented} programming, there is an implicit first parameter, often names \textbf{©self©} or \textbf{©this©}, which is elided.
+\begin{C++}
+class C {
+        int i, j;
+        int mem() {
+                i = 1;          ®// this->i
+®               j = 3;          ®// this->j
+®       }
+}
+\end{C++}
+Since CFA is non-object-oriented, the equivalent object-oriented program looks like:
+\begin{cfa}
+struct C {
+        int i, j;
+};
+int mem( C &this ) {
+        ®this.®i = 1;   // "this" is not elided
+        ®this.®j = 2;
+}
+\end{cfa}
+but it is cumbersome having to write "©this.©" many times in a member.
+\CFA provides a ©with© clause/statement to elided the "©this.©".
+\begin{cfa}
+int mem( C &this ) ®with this® {
+        i = 1;                  ®// this.i
+®       j = 2;                  ®// this.j
+®}
+\end{cfa}
+which extends to multiple routine parameters:
+\begin{cfa}
+struct D {
+        double m, n;
+};
+int mem2( C &this1, D &this2 ) ®with this1, this2® {
+        i = 1; j = 2;
+        m = 1.0; n = 2.0;
+}
+\end{cfa}
+The ©with© clause/statement comes from Pascal~\cite[\S~4.F]{Pascal}.
+The statement form is used within a block:
+\begin{cfa}
+int foo() {
+        struct S1 { ... } s1;
+        struct S2 { ... } s2;
+        ®with s1® {
+                // access fields of s1 without qualification
+                ®with s2® { // nesting
+                        // access fields of s2 without qualification
+                }
+        }
+        ®with s1, s2® {
+                // access unambiguous fields of s1 and s2 without qualification
+        }
+}
+\end{cfa}
+Names clashes when opening multiple structures are ambiguous.
+\begin{cfa}
+struct A { int i; int j; } a, c;
+struct B { int i; int k; } b, c;
+®with a, b® {
+        j + k;                                          §\C{// unambiguous}§
+        i;                                                      §\C{// ambiguous}§
+        a.i + b.i;                                      §\C{// unambiguous}§
+}
+®with c® {                                              §\C{// ambiguous}§
+        // ...
+}
+\end{cfa}
 \section{Exception Handling}
 …
 \label{s:CFAKeywords}
+\CFA introduces the following new keywords.
 \begin{quote2}
 \begin{tabular}{llll}
+\begin{tabular}{lllll}
 \begin{tabular}{@{}l@{}}
 ©_AT©                   \\
+©_At©                   \\
 ©catch©                 \\
 ©catchResume©   \\
 ©choose©                \\
 ©coroutine©             \\
-©disable©               \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
+©disable©               \\
 ©dtype©                 \\
 ©enable©                \\
 ©fallthrough©   \\
 ©fallthru©              \\
-©finally©               \\
-©forall©                \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
+©finally©               \\
+©forall©                \\
 ©ftype©                 \\
 ©lvalue©                \\
 ©monitor©               \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
 ©mutex©                 \\
 ©one_t©                 \\
 ©otype©                 \\
+©throw©                 \\
+©throwResume©   \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
-©throw©                 \\
-©throwResume©   \\
 ©trait©                 \\
 ©try©                   \\
 ©ttype©                 \\
 ©zero_t©                \\
+                                \\
 \end{tabular}
 \end{tabular}

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset e9bb0e5

Legend:

doc/user/user.tex

Download in other formats: