Context Navigation

-                      re2f1eeb
+                      r3dafd83
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Tue Apr 18 17:17:24 2017
 %% Update Count     : 1430
+%% Last Modified On : Mon May 15 18:29:58 2017
+%% Update Count     : 1598
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \usepackage{calc}
 \usepackage{xspace}
-\usepackage{graphicx}
 \usepackage{varioref}                                                                   % extended references
 \usepackage{listings}                                                                   % format program code
 …
 \section{Introduction}
 \CFA\footnote{Pronounced ``C-for-all'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed as an evolutionary step forward from the C programming language.
+\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.
 % Any language feature that is not described here can be assumed to be using the standard C11 syntax.
 \CFA adds many modern programming-language features that directly lead to increased \emph{safety} and \emph{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 garbage-collection.
+\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.
 The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
 …
 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 has struggled over the intervening time to incorporate modern programming-language features because of early design choices.
 \CFA has 30 years of hindsight and a clean starting point.
+\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.
+In contrast, \CFA has 30 years of hindsight and a clean starting point.
 Like \Index*[C++]{\CC}, there may be both an old and new ways to achieve the same effect.
 For example, the following programs compare the \CFA and C I/O mechanisms.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
+\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>
 int main( void ) {
         int x = 0, y = 1, z = 2;
 …
 \begin{lstlisting}
 #include <stdio.h>
 int main( void ) {
         int x = 0, y = 1, z = 2;
 …
+}
 \end{lstlisting}
+&
+\begin{lstlisting}
+#include <iostream>
+using namespace std;
+int main() {
+        int x = 0, y = 1, z = 2;
+        ®cout<<x<<" "<<y<<" "<<z<<endl;®
+}
+\end{lstlisting}
 \end{tabular}
 \end{quote2}
 Both programs output the same result.
 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 also~\VRef{s:IOLibrary}).
+The programs output the same result.
+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}).
 This document is a user manual for the \CFA programming language, targeted at \CFA programmers.
 …
 In its current state, this document covers the intended core features of the language.
 Changes to the syntax and additional features are expected to be included in later revisions.
-% For additional information, see \url{http://wiki.do-lang.org}.
-\section{History}
-The \CFA project started with 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.
-(See~\cite{Werther96} for some similar work, but for \Index*[C++]{\CC}.)
-The original \CFA project~\cite{Ditchfield92} extended the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC} approach of object-oriented extensions to the C type-system.
-A first implementation of the core Cforall language was created~\cite{Bilson03,Esteves04}, but at the 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.
 \section{Why fix C?}
+Even with all its problems, C is a very popular programming language because it allows writing software at virtually any level in a computer system without restriction.
+The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems (especially UNIX systems) to hobby projects.
+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.
+As well, there are millions of lines of C legacy code, forming the base for many software development projects (especially on UNIX systems).
+The TIOBE index (\url{http://www.tiobe.com/tiobe_index}) for March 2016 shows programming-language popularity, with \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, and all other programming languages below 3\%.
+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:
 \begin{center}
 …
 \end{tabular}
 \end{center}
 Hence, C is still an extremely important programming language, with double the usage of \Index*[C++]{\CC}, where \CC itself is largely C code.
 Finally, love it or hate it, C has been an important and influential part of computer science for 40 years and it appears it will continue to be for many more years.
+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.
 The goal of this project is to engineer modern language features into C in an evolutionary rather than revolutionary way.
+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++,ANSI14:C++} is an example of a similar project;
 however, it largely extended the language, and did not address many existing problems.\footnote{%
 …
 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 C11~\cite{C11}, but fixing some of the well known C problems and containing many modern language features.
+The result of this project is a language that is largely backwards compatible with \Index*{C11}~\cite{C11}, but fixing some of the well known C problems and containing many 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 C11 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 \Index*{C11} 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.
+(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):
+\begin{lstlisting}
+®forall( otype T )® T identity( T val ) { return val; }
+int forty_two = identity( 42 );                 §\C{// T is bound to int, forty\_two == 42}§
+\end{lstlisting}
+% extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC} approach of object-oriented extensions.
+\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.
 …
 \label{s:Interoperability}
+\CFA is designed to integrate well with existing C programs and libraries.
+The most important feature of interoperability is to use the same calling conventions, so there is no overhead to call existing C routines.
+This feature allows users of \CFA to take advantage of the existing panoply of C libraries from inside their \CFA code.
+In fact, one of the biggest issues for any new programming language is establishing a minimum level of library code to support a large body of activities.
+Language developers often state that adequate library support takes more work than designing and implementing the language itself.
+Like \Index*[C++]{\CC}, \CFA 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.
+\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.
+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.
+\begin{comment}
+A simple example is leveraging the existing type-unsafe (©void *©) C ©bsearch© to binary search a sorted floating-point array:
+\begin{lstlisting}
+void * bsearch( const void * key, const void * base, size_t nmemb, size_t size,
+                                int (* compar)( const void *, const void * ));
+int comp( const void * t1, const void * t2 ) { return *(double *)t1 < *(double *)t2 ? -1 :
+                                *(double *)t2 < *(double *)t1 ? 1 : 0; }
+double key = 5.0, vals[10] = { /* 10 sorted floating-point values */ };
+double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
+\end{lstlisting}
+which can be augmented simply with a polymorphic, type-safe, \CFA-overloaded wrappers:
+\begin{lstlisting}
+forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) {
+        int comp( const void * t1, const void * t2 ) { /* as above with double changed to T */ }
+        return (T *)bsearch( &key, arr, size, sizeof(T), comp ); }
+forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
+        T * result = bsearch( key, arr, size ); $\C{// call first version}$
+        return result ? result - arr : size; }  $\C{// pointer subtraction includes sizeof(T)}$
+double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
+int posn = bsearch( 5.0, vals, 10 );
+\end{lstlisting}
+The nested function ©comp© provides the hidden interface from typed \CFA to untyped (©void *©) C, plus the cast of the result.
+Providing a hidden ©comp© function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
+As well, an alternate kind of return is made available: position versus pointer to found element.
+\CC's type-system cannot disambiguate between the two versions of ©bsearch© because it does not use the return type in overload resolution, nor can \CC separately compile a templated ©bsearch©.
+\CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations.
+For example, it is possible to write a type-safe \CFA wrapper ©malloc© based on the C ©malloc©:
+\begin{lstlisting}
+forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
+int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
+double * dp = malloc();
+struct S {...} * sp = malloc();
+\end{lstlisting}
+where the return type supplies the type/size of the allocation, which is impossible in most type systems.
+\end{comment}
 However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
 …
 char abs( char );
 ®extern "C" {®
 int abs( int );                                 §\C{// use default C routine for int}§
+int abs( int );                                                 §\C{// use default C routine for int}§
 ®}® // extern "C"
 long int abs( long int );
 …
 \begin{cfa}
 #ifndef __CFORALL__
 #include <stdio.h>                              §\C{// C header file}§
+#include <stdio.h>                                              §\C{// C header file}§
 #else
 #include <fstream>                              §\C{// \CFA header file}§
+#include <fstream>                                              §\C{// \CFA header file}§
 #endif
 \end{cfa}
 …
 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
 \begin{cfa}
 ®_®147®_®483®_®648;                    §\C{// decimal constant}§
 _ul;                                                  §\C{// decimal unsigned long constant}§
 _377;                                                  §\C{// octal constant}§
 x_ff_ff;                                               §\C{// hexadecimal constant}§
 x_ef3d_aa5c;                                   §\C{// hexadecimal constant}§
 .141_592_654;                                  §\C{// floating point constant}§
 _e_+1_00;                                             §\C{// floating point constant}§
 x_ff_ff_p_3;                                   §\C{// hexadecimal floating point}§
 x_1.ffff_ffff_p_128_l;                 §\C{// hexadecimal floating point long constant}§
 L_"\x_ff_ee";                                   §\C{// wide character constant}§
+®_®147®_®483®_®648;                                    §\C{// decimal constant}§
+®_®ul;                                                                §\C{// decimal unsigned long constant}§
+®_®377;                                                                §\C{// octal constant}§
+x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
+x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
+.141®_®592®_®654;                                              §\C{// floating point constant}§
+®_®e®_®+1®_®00;                                               §\C{// floating point constant}§
+x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating point}§
+x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating point long constant}§
+L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
 \end{cfa}
 The rules for placement of underscores is as follows:
 …
 \label{s:BackquoteIdentifiers}
 \CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:
+\CFA accommodates keyword clashes with existing C variable-names by syntactic transformations using the \CFA backquote escape-mechanism:
 \begin{cfa}
 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
 double ®`®choose®`® = 3.5;
 \end{cfa}
+Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name.
+Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:
+Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to a  non-keyword name.
+\VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©:
+\begin{figure}
 \begin{cfa}
 // include file uses the CFA keyword "otype".
 …
 #endif // otype && __CFA_BFD_H__
 \end{cfa}
+\caption{Interposition of Header File}
+\label{f:InterpositionHeaderFile}
+\end{figure}
 …
 ... (*f())[3] += 1;
 \end{cfa}
 Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
+Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
 While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
 …
 So the type raised would be the mangled name of the exception prototype and that name would be matched at the handler clauses by comparing the strings.
 The arguments for the call would have to be packed in a message and unpacked at handler clause and then a call made to the handler.
+\section{I/O Library}
+\label{s:IOLibrary}
+\index{input/output library}
+The goal for the \CFA I/O is to make I/O as simple as possible in the common cases, while fully supporting polymorphism and user defined types in a consistent way.
+The common case is printing out a sequence of variables separated by whitespace.
+\begin{quote2}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
+\begin{cfa}
+int x = 0, y = 1, z = 2;
+sout | x ®|® y ®|® z | endl;
+\end{cfa}
+&
+\begin{cfa}
+cout << x ®<< " "® << y ®<< " "® << z << endl;
+\end{cfa}
+\end{tabular}
+\end{quote2}
+The \CFA form has half as many characters as the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators.
+The logical-or operator is used because it is the lowest-priority overloadable operator, other than assignment.
+Therefore, fewer output expressions require parenthesis.
+\begin{quote2}
+\begin{tabular}{@{}ll@{}}
+\textbf{\CFA:}
+&
+\begin{cfa}
+sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
+\end{cfa}
+\\
+\textbf{\CC:}
+&
+\begin{cfa}
+cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
+\end{cfa}
+\end{tabular}
+\end{quote2}
+Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, where data flows in the correct direction for input but the opposite direction for output.
+The implicit separator\index{I/O separator} character (space/blank) is a separator not a terminator.
+The rules for implicitly adding the separator are:
+\begin{enumerate}
+\item
+A separator does not appear at the start or end of a line.
+\begin{cfa}[belowskip=0pt]
+sout | 1 | 2 | 3 | endl;
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+2 3
+\end{cfa}
+\item
+A separator does not appear before or after a character literal or variable.
+\begin{cfa}
+sout | '1' | '2' | '3' | endl;
+\end{cfa}
+\item
+A separator does not appear before or after a null (empty) C string
+\begin{cfa}
+sout | 1 | "" | 2 | "" | 3 | endl;
+\end{cfa}
+which is a local mechanism to disable insertion of the separator character.
+\item
+A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{=$£¥¡¿«@
+%$
+\begin{cfa}[mathescape=off]
+sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
+                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
+\end{cfa}
+%$
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+x (1 x [2 x {3 x =4 x $5 x £6 x ¥7 x ¡8 x ¿9 x «10
+\end{cfa}
+%$
+\item
+{\lstset{language=CFA,deletedelim=**[is][]{¢}{¢}}
+A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.;!?)]}%¢»©
+\begin{cfa}[belowskip=0pt]
+sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
+                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+, x 2. x 3; x 4! x 5? x 6% x 7§\textcent§ x 8» x 9) x 10] x 11} x
+\end{cfa}}%
+\item
+A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[showspaces=true]@`'": \t\v\f\r\n@
+\begin{cfa}[belowskip=0pt]
+sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
+x`1`x'2'x"3"x:4:x 5 x   6       x
+\end{cfa}
+\end{enumerate}
+The following \CC-style \Index{manipulator}s allow control over implicit seperation.
+Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, i.e., the seperator is adjusted only with respect to the next printed item.
+\begin{cfa}[mathescape=off,belowskip=0pt]
+sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start of line}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+2 3
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// locally turn off implicit separator}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+3
+\end{cfa}
+Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, i.e., the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// globally turn off implicit separation}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+sout | 1 | sepOn | 2 | 3 | endl;                        §\C{// locally turn on implicit separator}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+23
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// globally turn on implicit separation}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+2 3
+\end{cfa}
+Printing a tuple outputs all the tuple's values separated by ©", "©:
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+sout | [2, 3] | [4, 5] | endl;                          §\C{// print tuple}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+, 3, 4, 5
+\end{cfa}
+The tuple separator can also be turned on and off:
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+sout | sepOn | [2, 3] | sepOff | [4, 5] | endl; §\C{// locally turn on/off implicit separation}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+, 2, 34, 5
+\end{cfa}
+Notice a tuple seperator starts the line because the next item is a tuple.
+Finally, the stream routines \Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} and \Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} get and set the basic separator-string.
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+sepSet( sout, ", $" );                                          §\C{// set separator from " " to ", \$"}§
+sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
+\end{cfa}
+%$
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
+, $2, $3 ", $"
+\end{cfa}
+%$
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+sepSet( sout, " " );                                            §\C{// reset separator to " "}§
+sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
+2 3 " "
+\end{cfa}
+and the stream routines \Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} and \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} get and set the tuple separator-string.
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+sepSetTuple( sout, " " );                                       §\C{// set tuple separator from ", " to " "}§
+sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl;
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
+3 4 5 " "
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+sepSetTuple( sout, ", " );                                      §\C{// reset tuple separator to ", "}§
+sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl;
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
+, 3, 4, 5 ", "
+\end{cfa}
+\begin{comment}
+#include <fstream>
+int main( void ) {
+        int x = 0, y = 1, z = 2;
+        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl | endl;
+        sout | 1 | 2 | 3 | endl;
+        sout | '1' | '2' | '3' | endl;
+        sout | 1 | "" | 2 | "" | 3 | endl;
+        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
+                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
+        sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
+                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
+        sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
+        sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
+        sout | 1 | sepOff | 2 | 3 | endl;                       // locally turn off implicit separator
+        sout | sepDisable | 1 | 2 | 3 | endl;           // globally turn off implicit separation
+        sout | 1 | sepOn | 2 | 3 | endl;                        // locally turn on implicit separator
+        sout | sepEnable | 1 | 2 | 3 | endl;            // globally turn on implicit separation
+        sout | [2, 3] | [4, 5] | endl;                          // print tuple
+        sout | sepOn | [2, 3] | sepOff | [4, 5] | endl; // locally turn on/off implicit separation
+        sepSet( sout, ", $" );                                          // set separator from " " to ", $"
+        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
+        sepSet( sout, " " );                                            // reset separator to " "
+        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
+        sepSetTuple( sout, " " );                                       // set tuple separator from ", " to " "
+        sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl;
+        sepSetTuple( sout, ", " );                                      // reset tuple separator to ", "
+        sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl;
+}
+// Local Variables: //
+// tab-width: 4 //
+// End: //
+\end{comment}
+%$
 …
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{Indexc{gcc}} \\
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{\textbf{\Indexc{gcc}}} \\
 \begin{cfa}
 …
 The exact set of unsafe C constructs that will be disallowed in \CFA has not yet been decided, but is sure to include pointer arithmetic, pointer casting, etc.
 Once the full set is decided, the rules will be listed here.
-\section{Syntactic Anomalies}
-The number 0 and 1 are treated specially in \CFA, and can be redefined as variables.
-One syntactic anomaly is when a field in an structure is names 0 or 1:
-\begin{cfa}
-struct S {
-        int 0, 1;
-} s;
-\end{cfa}
-The problem occurs in accessing these fields using the selection operation ``©.©'':
-\begin{cfa}
-s.0 = 0;        // ambiguity with floating constant .0
-s.1 = 1;        // ambiguity with floating constant .1
-\end{cfa}
-To make this work, a space is required after the field selection:
-\begin{cfa}
-®s.§\textvisiblespace§0® = 0;
-®s.§\textvisiblespace§1® = 1;
-\end{cfa}
-While this syntax is awkward, it is unlikely many programmers will name fields of a structure 0 or 1.
-Like 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.
-There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
-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.
-Even with this special hack, there are 5 general cases that cannot be handled.
-The first case is for the function-call identifier ©?()©:
-\begin{cfa}
-int *§\textvisiblespace§?()();  // declaration: space required after '*'
-*§\textvisiblespace§?()();              // expression: space required after '*'
-\end{cfa}
-Without the space, the string ©*?()© is ambiguous without N character look ahead;
-it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
-The 4 remaining cases occur in expressions:
-\begin{cfa}
-i++§\textvisiblespace§?i:0;             // space required before '?'
-i--§\textvisiblespace§?i:0;             // space required before '?'
-i§\textvisiblespace§?++i:0;             // space required after '?'
-i§\textvisiblespace§?--i:0;             // space required after '?'
-\end{cfa}
-In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
-it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
-In the second two cases, the string ©?++x© is ambiguous, where this string can be lexed as ©?++© / ©x© or ©?© / y©++x©;
-it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
 …
+\section{Syntactic Anomalies}
+There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©~\R{/}~©?*?© or ©*?©~\R{/}~©*?©.
+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.
+Even with this special hack, there are 5 general cases that cannot be handled.
+The first case is for the function-call identifier ©?()©:
+\begin{cfa}
+int *§\textvisiblespace§?()();  // declaration: space required after '*'
+*§\textvisiblespace§?()();              // expression: space required after '*'
+\end{cfa}
+Without the space, the string ©*?()© is ambiguous without N character look ahead;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
+The 4 remaining cases occur in expressions:
+\begin{cfa}
+i++§\textvisiblespace§?i:0;             // space required before '?'
+i--§\textvisiblespace§?i:0;             // space required before '?'
+i§\textvisiblespace§?++i:0;             // space required after '?'
+i§\textvisiblespace§?--i:0;             // space required after '?'
+\end{cfa}
+In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
+In the second two cases, the string ©?++x© is ambiguous, where this string can be lexed as ©?++© / ©x© or ©?© / y©++x©;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
 \section{Incompatible}
 …
 \section{New Keywords}
 \label{s:NewKeywords}
+\section{\protect\CFA Keywords}
+\label{s:CFAKeywords}
 \begin{quote2}
 \begin{tabular}{lll}
+©catch©                 & ©fallthrough© & ©otype©               \\
+©catchResume©   & ©fallthru©    & ©throw©               \\
+©choose©                & ©finally©             & ©throwResume© \\
+©disable©               & ©forall©              & ©trait©               \\
+©dtype©                 & ©ftype©               & ©try©                 \\
+©enable©                & ©lvalue©              &                               \\
+\begin{tabular}{@{}l@{}}
+©_AT©                   \\
+©catch©                 \\
+©catchResume©   \\
+©choose©                \\
+©coroutine©             \\
+©disable©               \\
+©dtype©                 \\
+©enable©                \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
+©fallthrough©   \\
+©fallthru©              \\
+©finally©               \\
+©forall©                \\
+©ftype©                 \\
+©lvalue©                \\
+©monitor©               \\
+©mutex©                 \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
+©one_t©                 \\
+©otype©                 \\
+©throw©                 \\
+©throwResume©   \\
+©trait©                 \\
+©try©                   \\
+©ttype©                 \\
+©zero_t©                \\
+\end{tabular}
 \end{tabular}
 \end{quote2}
 …
 \label{s:StandardHeaders}
 C prescribes the following standard header-files~\cite[\S~7.1.2]{C11}:
+C11 prescribes the following standard header-files~\cite[\S~7.1.2]{C11} and \CFA adds to this list:
 \begin{quote2}
+\begin{minipage}{\linewidth}
+\begin{tabular}{lll}
+assert.h        & math.h                & stdlib.h              \\
+complex.h       & setjmp.h              & stdnoreturn.h \\
+\begin{tabular}{lll|l}
+\multicolumn{3}{c|}{C11} & \multicolumn{1}{c}{\CFA}             \\
+\hline
+assert.h        & math.h                & stdlib.h              & unistd.h      \\
+complex.h       & setjmp.h              & stdnoreturn.h & gmp.h         \\
 ctype.h         & signal.h              & string.h              \\
 errno.h         & stdalign.h    & tgmath.h              \\
 …
 iso646.h        & stddef.h              & wchar.h               \\
 limits.h        & stdint.h              & wctype.h              \\
 locale.h        & stdio.h               & unistd.h\footnote{\CFA extension}
+locale.h        & stdio.h               &                               \\
 \end{tabular}
-\end{minipage}
 \end{quote2}
 For the prescribed head-files, \CFA implicitly wraps their includes in an ©extern "C"©;
 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
-\section{I/O Library}
-\label{s:IOLibrary}
-\index{input/output library}
-The goal for the \CFA I/O is to make I/O as simple as possible in the common cases, while fully supporting polymorphism and user defined types in a consistent way.
-The common case is printing out a sequence of variables separated by whitespace.
-\begin{quote2}
-\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
-\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
-\begin{cfa}
-int x = 0, y = 1, z = 2;
-®sout® ®|® x ®|® y ®|® z ®| endl®;
-\end{cfa}
+&
-\begin{cfa}
-cout << x << " " << y << " " << z << endl;
-\end{cfa}
-\end{tabular}
-\end{quote2}
-The \CFA form has half as many characters as the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators.
-The logical-or operator is used because it is the lowest-priority overloadable operator, other than assignment.
-Therefore, fewer output expressions require parenthesis.
-\begin{quote2}
-\begin{tabular}{@{}ll@{}}
-\textbf{\CFA:}
+&
-\begin{cfa}
-sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
-\end{cfa}
-\\
-\textbf{\CC:}
+&
-\begin{cfa}
-cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
-\end{cfa}
-\end{tabular}
-\end{quote2}
-Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, although data flows in the opposite direction.
-The implicit separator\index{I/O separator} character (space/blank) is a separator not a terminator.
-The rules for implicitly adding the separator are:
-\begin{enumerate}
-\item
-A separator does not appear at the start or end of a line.
-\begin{cfa}[belowskip=0pt]
-sout | 1 | 2 | 3 | endl;
-\end{cfa}
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
-2 3
-\end{cfa}
-\item
-A separator does not appear before or after a character literal or variable.
-\begin{cfa}
-sout | '1' | '2' | '3' | endl;
-\end{cfa}
-\item
-A separator does not appear before or after a null (empty) C string
-\begin{cfa}
-sout | 1 | "" | 2 | "" | 3 | endl;
-\end{cfa}
-which is a local mechanism to disable insertion of the separator character.
-\item
-A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{=$£¥¡¿«@
-%$
-\begin{cfa}[mathescape=off]
-sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥" | 7
-         | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
-\end{cfa}
-%$
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
-x (1 x [2 x {3 x =4 x $5 x £6 x ¥7 x ¡8 x ¿9 x «10
-\end{cfa}
-%$
-\item
-{\lstset{deletedelim=**[is][]{¢}{¢}}
-A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»©
-\begin{cfa}[belowskip=0pt]
-sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | "% x"
-         | 8 | "¢ x" | 9 | "» x" | 10 | ") x" | 11 | "] x" | 12 | "} x" | endl;
-\end{cfa}
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
-, x 2. x 3: x 4; x 5! x 6? x 7% x 8¢ x 9» x 10) x 11] x 12} x
-\end{cfa}}%
-\item
-A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[showspaces=true]@`'" \t\v\f\r\n@
-\begin{cfa}[belowskip=0pt]
-sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl;
-\end{cfa}
-\begin{cfa}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
-x`1`x'2'x"3"x x 4 x x   1       x
-\end{cfa}
-\end{enumerate}
-The following \CC-style \Index{manipulator}s allow further control over implicit seperation.
-\begin{cfa}[mathescape=off,belowskip=0pt]
-sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start of line}§
-\end{cfa}
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
-2 3
-\end{cfa}
-\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
-sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// turn off implicit separator locally}§
-\end{cfa}
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
-3
-\end{cfa}
-\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
-sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// turn off implicit separation globally}§
-\end{cfa}
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
-\end{cfa}
-\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
-sout | 1 | sepOn | 2 | 3 | endl;                        §\C{// turn on implicit separator locally}§
-\end{cfa}
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
-23
-\end{cfa}
-\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
-sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// turn on implicit separation globally}§
-\end{cfa}
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
-2 3
-\end{cfa}
-\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
-sepSet( sout, ", $" );                                          §\C{// change separator from " " to ", \$"}§
-sout | 1 | 2 | 3 | endl;
-\end{cfa}
-%$
-\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
-, $2, $3
-\end{cfa}
-%$
-\begin{comment}
-#include <fstream>
-int main() {
-        int x = 0, y = 1, z = 2;
-        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl | endl;
-        sout | 1 | 2 | 3 | endl;
-        sout | '1' | '2' | '3' | endl;
-        sout | 1 | "" | 2 | "" | 3 | endl;
-        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥" | 7
-                | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
-        sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | "% x"
-                | 8 | "¢ x" | 9 | "» x" | 10 | ") x" | 11 | "] x" | 12 | "} x" | endl;
-        sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl;
-        sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
-        sout | 1 | sepOff | 2 | 3 | endl;                       // turn off implicit separator temporarily
-        sout | sepDisable | 1 | 2 | 3 | endl;           // turn off implicit separation, affects all subsequent prints
-        sout | 1 | sepOn | 2 | 3 | endl;                        // turn on implicit separator temporarily
-        sout | sepEnable | 1 | 2 | 3 | endl;            // turn on implicit separation, affects all subsequent prints
-        sepSet( sout, ", $" );                                          // change separator from " " to ", $"
-        sout | 1 | 2 | 3 | endl;
+}
-// Local Variables: //
-// tab-width: 4 //
-// End: //
-\end{comment}
-%$

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

Context Navigation

Changeset 3dafd83 for doc/user

Legend:

doc/user/user.tex

Download in other formats: