Changes in doc/user/user.tex [5479e63:07bc165]

File:

• doc/user/user.tex (modified) (26 diffs)

doc/user/user.tex

@@ -11 +11 @@
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
-%% Last Modified On : Wed Jul 13 08:14:39 2016
-%% Update Count     : 1247
+%% Last Modified On : Sun Jul 10 12:52:09 2016
+%% Update Count     : 1200
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -294 +294 @@
 \item
 \Indexc{-nodebug}\index{compilation option!-nodebug@©-nodebug©}
-The program is linked with the non-debugging version of the runtime system, so the execution of the program is faster.
+The program is linked with the non-debugging version of the unikernel or multikernel, so the execution of the program is faster.
 \Emph{However, no runtime checks or ©assert©s are performed so errors usually result in abnormal program termination.}
 
@@ -721 +721 @@
 ®&®crc = &cx;                                   §\C{// error, cannot change crc}§
 \end{lstlisting}
-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}, e.g.:
-\begin{lstlisting}
-int & const r = *0;                             §\C{// where 0 is the int * zero}§
-\end{lstlisting}
-Otherwise, 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.
+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}.
+In effect, 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.
 
 \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.
@@ -738 +735 @@
 \begin{lstlisting}
 int & f( int & rp );                    §\C{// reference parameter and return}§
-z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
+z = f( x ) + f( y );                    §\C{// reference operator added}§
 \end{lstlisting}
 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©.
-Since ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references.
+The return reference from ©f© is copied into a compiler generated temporary, which is treated as an initialization.
 
 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
@@ -1649 +1646 @@
 \end{lstlisting}
 The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
-\begin{quote2}
-\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \begin{lstlisting}
 switch ( argc ) {
@@ -1663 +1658 @@
 }
 \end{lstlisting}
-&
-\begin{lstlisting}
-
-if ( argc == 3 ) {
-        // open output file
-        ®// open input file
-®} else if ( argc == 2 ) {
-        ®// open input file
-
-®} else {
-        // usage message
-}
-\end{lstlisting}
-\end{tabular}
-\end{quote2}
 In this example, case 2 is always done if case 3 is done.
 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
@@ -1692 +1672 @@
 \end{lstlisting}
 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.
+While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is not intuitive to most 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.
 
@@ -1702 +1682 @@
         if ( j < k ) {
                 ...
-          ®case 1:®             // transfer into "if" statement
-                ...
-        } // if
-  case 2:
+          case 1:               // transfer into "if" statement
+                if ( j < m ) {
+                        ...
+                  case 2:       // transfer into "if" statement
+                        ...
+                }
+        }
+  case 3:
         while ( j < 5 ) {
                 ...
-          ®case 3:®             // transfer into "while" statement
+          case 4:               // transfer into "while" statement
                 ...
-        } // while
-} // switch
+        }
+}
 \end{lstlisting}
 The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
@@ -1750 +1734 @@
 \begin{lstlisting}
 switch ( x ) {
-        ®int y = 1;®                            §\C{// unreachable initialization}§
-        ®x = 7;®                                        §\C{// unreachable code without label/branch}§
+        int y = 1;                      §\C{// unreachable initialization}§
+        x = 7;                          §\C{// unreachable code}§
   case 3: ...
+        y = 3;
         ...
-        ®int z = 0;®                            §\C{// unreachable initialization, cannot appear after case}§
-        z = 2;
-  case 3:
-        ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
 }
 \end{lstlisting}
 While 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.
-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©.
-As mentioned, transfer into control structures should be forbidden;
-transfers from within the ©switch© body using a ©goto© are equally unpalatable.
-As 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.
+Furthermore, any statements before the first ©case© clause can only be executed if labelled and transfered to using a ©goto©, either from outside or inside of the ©switch©.
+As mentioned, transfer into control structures should be forbidden.
+Transfers from within the ©switch© body using a ©goto© are equally unpalatable.
 \end{enumerate}
-
 Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
 \begin{itemize}
@@ -1778 +1757 @@
 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 suggested changes to the ©switch© into perspective.
+These observations help to put the effects of suggested changes into perspective.
 \begin{enumerate}
 \item
@@ -1788 +1767 @@
 still work.
 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
-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©, e.g.:
+Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no fall-through semantics.
+The ©choose© statement is identical to the new ©switch© statement, except there is no implicit fall-through between case-clauses and the ©break© statement applies to the enclosing loop construct (as for the ©continue© statement in a ©switch© statement).
+It is still possible to fall-through if a case-clause ends with the new keyword ©fallthru©, e.g.:
 \begin{lstlisting}
 ®choose® ( i ) {
-  case 1:  case 2:  case 3:
+  case 3:
         ...
-        ®// implicit end of switch (break)
-  ®case 5:
-        ...
-        ®fallthru®;                                     §\C{// explicit fall through}§
+        ®fallthru®;             §\C{// explicit fall through}§
+  case 5:
+        ...                             §\C{// implicit end of switch}§
   case 7:
         ...
-        ®break®                                         §\C{// explicit end of switch}§
+        ®break®                 §\C{// transfer to end of enclosing loop / switch}§
   default:
         j = 3;
 }
 \end{lstlisting}
-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.
-As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
-\item
-\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
-Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
+The ability to fall-through is retained because it is a sufficient C-idiom that most C programmers simply expect it, and its absence might discourage these programmers from using the ©choose© statement.
+\item
+Eliminating \Index*{Duff's device} is straightforward and only invalidates a small amount of very questionable code.
+The solution is to allow ©case© clauses to only appear at the same nesting level as the ©switch© body, as is done in most other programming languages with ©switch© statements.
 \item
 The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
-Therefore, no change is made for this issue.
-\item
-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{
-Essentially, 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.
-Further declaration in the statement body are disallowed.
-\begin{lstlisting}
-switch ( x ) {
-        ®int i = 0;®                            §\C{// allowed}§
+Therefore, no language change is made for this issue.
+\item
+Dealing with unreachable code at the start of a ©switch© statement is solved by defining the declaration-list, including any associated initialization, at the start of a ©switch© statement body to be executed \emph{before} the transfer to the appropriate ©case© clause.
+This semantics is the same as for declarations at the start of a loop body, which are executed before each iteration of the loop body.
+As well, statements cannot appear before the first ©case© clause.
+The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred.
+The change is incompatible for statements, but any existing code using it is highly questionable, as in:
+\begin{lstlisting}
+switch ( i ) {
+        L: x = 5;               §\C{// questionable code}§
   case 0:
         ...
-        ®int i = 0;®                            §\C{// disallowed}§
-  case 1:
-    {
-                ®int i = 0;®                    §\C{// allowed in any compound statement}§
-                ...
-        }
-  ...
-}
-\end{lstlisting}
+}
+\end{lstlisting}
+The statement after the ©switch© can never be executed unless it is labelled.
+If it is labelled, it must be transfered to from outside or inside the ©switch© statement, neither of which is acceptable control flow.
 \end{enumerate}
 
@@ -1913 +1887 @@
 \section{Exception Handling}
 
-Exception handling provides two mechanism: change of control flow from a raise to a handler, and communication from the raise to the handler.
+Exception handling provides two mechanim: change of control flow from a raise to a handler, and commumication from the riase to the handler.
 \begin{lstlisting}
 exception void h( int i );
@@ -2166 +2140 @@
 A facility that let programmers declare specific constants..const Rational 12., for instance. would not be much of an improvement.
 Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
-The complexity of such a feature does not seem worth the gain.
+The complexity of such a feature doesn.t seem worth the gain.
 
 For example, to define the constants for a complex type, the programmer would define the following:
@@ -2694 +2668 @@
 } s;
 \end{lstlisting}
-The problem occurs in accessing these fields using the selection operation ``©.©'':
+The problem occurs in accesing these fields using the selection operation ``©.©'':
 \begin{lstlisting}
 s.0 = 0;        // ambiguity with floating constant .0
@@ -2704 +2678 @@
 ®s.§\textvisiblespace§1® = 1;
 \end{lstlisting}
-While this syntax is awkward, it is unlikely many programmers will name fields of a structure 0 or 1.
+While this sytact is awkward, it is unlikely many programers 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.
 
@@ -3016 +2990 @@
 In \CFA, multiple definitions are not necessary.
 Within a module, all of the module's global definitions are visible throughout the module.
-For example, the following code compiles, even though ©isOdd© was not declared before being called:
+For example, the following code compiles, even though isOdd was not declared before being called:
 \begin{lstlisting}
 bool isEven(unsigned int x) {
@@ -4356 +4330 @@
 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
 \begin{lstlisting}
-int `otype` = 3;                                // make keyword an identifier
+int `otype` = 3;                                // make keyword an indentifier
 double `choose` = 3.5;
 \end{lstlisting}
@@ -4493 +4467 @@
 \begin{description}
 \item[Change:] comma expression is disallowed as subscript
-\item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays.
+\item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new styple arrays.
 \item[Effect on original feature:] change to semantics of well-defined feature.
 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
@@ -4505 +4479 @@
 \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 goal for the \CFA I/O is to make I/O as simple as possible in the common cases, while fully supporting polmorphism and user defined types in a consistent way.
 The common case is printing out a sequence of variables separated by whitespace.
 \begin{quote2}
@@ -4542 +4516 @@
 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 implicit seperator\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.
+A seperator does not appear at the start or end of a line.
 \begin{lstlisting}[belowskip=0pt]
 sout | 1 | 2 | 3 | endl;
@@ -4554 +4528 @@
 \end{lstlisting}
 \item
-A separator does not appear before or after a character literal or variable.
+A seperator does not appear before or after a character literal or variable.
 \begin{lstlisting}
 sout | '1' | '2' | '3' | endl;
@@ -4560 +4534 @@
 \end{lstlisting}
 \item
-A separator does not appear before or after a null (empty) C string
+A seperator does not appear before or after a null (empty) C string
 \begin{lstlisting}
 sout | 1 | "" | 2 | "" | 3 | endl;
@@ -4567 +4541 @@
 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]@([{$£¥¡¿«@
+A seperator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{$£¥¡¿«@
 %$
 \begin{lstlisting}[mathescape=off]
@@ -4770 +4744 @@
 
 
-\subsection{min / max / clamp / swap}
+\subsection{min / max / swap}
 
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
@@ -4778 +4752 @@
 forall( otype T | { int ?>?( T, T ); } )
 T max( const T t1, const T t2 );§\indexc{max}§
-
-forall( otype T | { T min( T, T ); T max( T, T ); } )
-T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
 
 forall( otype T )
@@ -5165 +5136 @@
 When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
 
-\begin{lstlisting}[belowskip=0pt]
+\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 // implementation
 struct Rational {§\indexc{Rational}§