Context Navigation

-                      reaa1759
+                      r4ada74e
 \usepackage{listings}                                           % format program code
 \usepackage{enumitem}
+\setlist[itemize]{topsep=3pt,itemsep=2pt,parsep=0pt}% global
 \usepackage[flushmargin]{footmisc}                      % support label/reference in footnote
 \usepackage{rotating}
 …
 Both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:
 \begin{itemize}[topsep=3pt,itemsep=2pt,parsep=0pt]
+\begin{itemize}
 \item
 They cannot create a loop, which means only the looping constructs cause looping.
 …
 \subsection{Exception Handling}
 \CFA provides two forms of exception handling: \newterm{resumption} (fix-up) and \newterm{recovery}.
+\CFA provides two forms of exception handling: \newterm{resumption} (fix-up) and \newterm{recovery} (see Figure~\ref{f:CFAExceptionHandling}).
 Both mechanisms provide dynamic call to a handler using dynamic name-lookup, where fix-up has dynamic return and recovery has static return from the handler.
+\CFA restricts exception types to those defined by aggregate type @_Exception@.
+The form of the raise dictates the set of handlers examined during propagation: \newterm{resumption propagation} (@resume@) only examines resumption handlers (@catchResume@); \newterm{terminating propagation} (@throw@) only examines termination handlers (@catch@).
+If @resume@ or @throw@ have no exception type, it is a reresume/rethrow, meaning the currently exception continues propagation.
+If there is no current exception, the reresume/rethrow results in an error.
+\begin{figure}
 \begin{cquote}
 \lstDeleteShortInline@%
 …
 \multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{Resumption}}       & \multicolumn{1}{c}{\textbf{Recovery}} \\
 \begin{cfa}
+_Exception E { int fix; };
+`_Exception R { int fix; };`
 void f() {
         E e;
         ... _Resume e;
         ... e.fix // control returns here after handler
 try {
         f();
 } catchResume( E e ) {
         ... e.fix = ...; // return correction to raise
+        R r;
+        ... `resume( r );` ...
+        ... r.fix // control does return here after handler
+`try` {
+        ... f(); ...
+} `catchResume( R r )` {
+        ... r.fix = ...; // return correction to raise
 } // dynamic return to _Resume
 \end{cfa}
+&
 \begin{cfa}
+_Exception E {};
+`_Exception T {};`
 void f() {
         ... _Throw E{};
+        ... `throw( T{} );` ...
         // control does NOT return here after handler
 try {
         f();
 } catch( E e ) {
+`try` {
+        ... f(); ...
+} `catch( T t )` {
         ... // recover and continue
 } // static return to next statement
 …
 \lstMakeShortInline@%
 \end{cquote}
+\caption{\CFA Exception Handling}
+\label{f:CFAExceptionHandling}
+\end{figure}
+The set of exception types in a list of catch clause may include both a resumption and termination handler:
+\begin{cfa}
+try {
+        ... resume( `R{}` ); ...
+} catchResume( `R` r ) { ... throw( R{} ); ... } $\C{\color{red}// H1}$
+   catch( `R` r ) { ... }                                       $\C{\color{red}// H2}$
+\end{cfa}
+The resumption propagation raises @R@ and the stack is not unwound;
+the exception is caught by the @catchResume@ clause and handler H1 is invoked.
+The termination propagation in handler H1 raises @R@ and the stack is unwound;
+the exception is caught by the @catch@ clause and handler H2 is invoked.
+The termination handler is available because the resumption propagation did not unwind the stack.
+An additional feature is conditional matching in a catch clause:
+\begin{cfa}
+try {
+        ... write( `datafile`, ... ); ...               $\C{// may throw IOError}$
+        ... write( `logfile`, ... ); ...
+} catch ( IOError err; `err == datafile` ) { ... } $\C{// handle datafile error}$
+   catch ( IOError err; `err == logfile` ) { ... } $\C{// handle logfile error}$
+   catch ( IOError err ) { ... }                        $\C{// handler error from other files}$
+\end{cfa}
+where the throw inserts the failing file-handle in the I/O exception.
+Conditional catch cannot be trivially mimicked by other mechanisms because once an exception is caught, handler clauses in that @try@ statement are no longer eligible..
+The resumption raise can specify an alternate stack on which to raise an exception, called a \newterm{nonlocal raise}:
+\begin{cfa}
+resume [ $\emph{exception-type}$ ] [ _At $\emph{alternate-stack}$ ] ;
+\end{cfa}
+The @_At@ clause raises the specified exception or the currently propagating exception (reresume) at another coroutine or task~\cite{Delisle18}.
+Nonlocal raise is restricted to resumption to provide the exception handler the greatest flexibility because processing the exception does not unwind its stack, allowing it to continue after the handle returns.
+To facilitate nonlocal exception, \CFA provides dynamic enabling and disabling of nonlocal exception-propagation.
+The constructs for controlling propagation of nonlocal exceptions are the @enable@ and the @disable@ blocks:
+\begin{cquote}
+\lstDeleteShortInline@%
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\begin{cfa}
+enable $\emph{exception-type-list}$ {
+        // allow non-local resumption
+}
+\end{cfa}
+&
+\begin{cfa}
+disable $\emph{exception-type-list}$ {
+        // disallow non-local resumption
+}
+\end{cfa}
+\end{tabular}
+\lstMakeShortInline@%
+\end{cquote}
+The arguments for @enable@/@disable@ specify the exception types allowed to be propagated or postponed, respectively.
+Specifying no exception type is shorthand for specifying all exception types.
+Both @enable@ and @disable@ blocks can be nested, turning propagation on/off on entry, and on exit, the specified exception types are restored to their prior state.
+Finally, \CFA provides a Java like  @finally@ clause after the catch clauses:
+\begin{cfa}
+try {
+        ... f(); ...
+// catchResume or catch clauses
+} `finally` {
+        // house keeping
+}
+\end{cfa}
+The finally clause is always executed, i.e., if the try block ends normally or if an exception is raised.
+If an exception is raised and caught, the handler is run before the finally clause.
+Like a destructor (see Section~\ref{s:ConstructorsDestructors}), a finally clause can raise an exception but not if there is an exception being propagated.
+Mimicking the @finally@ clause with mechanisms like RAII is non-trivially when there are multiple types and local accesses.
 …
 For example, a routine returning a pointer to an array of integers is defined and used in the following way:
 \begin{cfa}
 int `(*`f`())[`5`]` {...};                              $\C{// definition}$
  ... `(*`f`())[`3`]` += 1;                              $\C{// usage}$
+int `(*`f`())[`5`]` {...};                                      $\C{// definition}$
+ ... `(*`f`())[`3`]` += 1;                                      $\C{// usage}$
 \end{cfa}
 Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
 …
 as well, parameter names are optional, \eg:
 \begin{cfa}
 [ int x ] f ( /* void */ );                             $\C{// returning int with no parameters}$
 [ int x ] f (...);                                              $\C{// returning int with unknown parameters}$
 [ * int ] g ( int y );                                  $\C{// returning pointer to int with int parameter}$
 [ void ] h ( int, char );                               $\C{// returning no result with int and char parameters}$
 [ * int, int ] j ( int );                               $\C{// returning pointer to int and int, with int parameter}$
+[ int x ] f ( /* void */ );                                     $\C{// returning int with no parameters}$
+[ int x ] f (...);                                                      $\C{// returning int with unknown parameters}$
+[ * int ] g ( int y );                                          $\C{// returning pointer to int with int parameter}$
+[ void ] h ( int, char );                                       $\C{// returning no result with int and char parameters}$
+[ * int, int ] j ( int );                                       $\C{// returning pointer to int and int, with int parameter}$
 \end{cfa}
 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
 …
 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
 \begin{cfa}
 * [ int x ] () fp;                                              $\C{// pointer to routine returning int with no parameters}$
 * [ * int ] ( int y ) gp;                               $\C{// pointer to routine returning pointer to int with int parameter}$
 * [ ] ( int, char ) hp;                                 $\C{// pointer to routine returning no result with int and char parameters}$
 * [ * int, int ] ( int ) jp;                    $\C{// pointer to routine returning pointer to int and int, with int parameter}$
+* [ int x ] () fp;                                                      $\C{// pointer to routine returning int with no parameters}$
+* [ * int ] ( int y ) gp;                                       $\C{// pointer to routine returning pointer to int with int parameter}$
+* [ ] ( int, char ) hp;                                         $\C{// pointer to routine returning no result with int and char parameters}$
+* [ * int, int ] ( int ) jp;                            $\C{// pointer to routine returning pointer to int and int, with int parameter}$
 \end{cfa}
 Note, \emph{a routine name cannot be specified}:
 \begin{cfa}
 * [ int x ] f () fp;                                    $\C{// routine name "f" is disallowed}$
+* [ int x ] f () fp;                                            $\C{// routine name "f" is disallowed}$
 \end{cfa}
 …
 \begin{cfa}
 int x = 1, y = 2, * p1, * p2, ** p3;
 p1 = &x;                                                                $\C{// p1 points to x}$
 p2 = &y;                                                                $\C{// p2 points to y}$
 p3 = &p1;                                                               $\C{// p3 points to p1}$
+p1 = &x;                                                                        $\C{// p1 points to x}$
+p2 = &y;                                                                        $\C{// p2 points to y}$
+p3 = &p1;                                                                       $\C{// p3 points to p1}$
 *p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
 \end{cfa}
 …
 \begin{cfa}
 int x = 1, y = 2, & r1, & r2, && r3;
 &r1 = &x;  $\C{// r1 points to x}$
 &r2 = &y;  $\C{// r2 points to y}$
 &&r3 = &&r1;  $\C{// r3 points to r2}$
+&r1 = &x;                                                                       $\C{// r1 points to x}$
+&r2 = &y;                                                                       $\C{// r2 points to y}$
+&&r3 = &&r1;                                                            $\C{// r3 points to r2}$
 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);       $\C{// implicit dereferencing}$
 \end{cfa}
 …
 \begin{cfa}
 int & r = *new( int );
 ...
+...                                                                                     $\C{// non-null reference}$
 delete &r;
 r += 1;                 // undefined reference
+r += 1;                                                                         $\C{// undefined reference}$
 \end{cfa}
 \end{lrbox}
 Rebinding allows \CFA references to be default-initialized (\eg to a null pointer\footnote{
 While effort has been put into non-null reference checking in \CC and Java, the exercise seems moot for any non-managed languages (C/\CC), given that it only handles one of many different error situations:
+While effort has been made into non-null reference checking in \CC and Java, the exercise seems moot for any non-managed languages (C/\CC), given that it only handles one of many different error situations:
 \begin{cquote}
 \usebox{\LstBox}
 …
 These explicit address-of operators can be thought of as ``cancelling out'' the implicit dereference operators, \eg @(&`*`)r1 = &x@ or @(&(&`*`)`*`)r3 = &(&`*`)r1@ or even @(&`*`)r2 = (&`*`)`*`r3@ for @&r2 = &r3@.
 More precisely:
 \begin{itemize}[topsep=3pt,itemsep=2pt,parsep=0pt]
+\begin{itemize}
 \item
 if @R@ is an rvalue of type {@T &@$_1 \cdots$@ &@$_r$} where $r \ge 1$ references (@&@ symbols) than @&R@ has type {@T `*`&@$_{\color{red}2} \cdots$@ &@$_{\color{red}r}$}, \\ \ie @T@ pointer with $r-1$ references (@&@ symbols).
 …
 \label{f:TypeNestingQualification}
 \end{figure}
 In the left example in C, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
 In the right example in \CFA, the types are not hoisted and accessed .
+In the C left example, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
+In the \CFA right example, the types are not hoisted and accessible.
 \subsection{Constructors and Destructors}
+\label{s:ConstructorsDestructors}
 One of the strengths (and weaknesses) of C is memory-management control, allowing resource release to be precisely specified versus unknown release with garbage-collected memory-management.
 …
 In \CFA, a constructor is named @?{}@ and a destructor is named @^?{}@.
 The name @{}@ comes from the syntax for the initializer: @struct S { int i, j; } s = `{` 2, 3 `}`@.
 The symbol \lstinline+^+ is used because it was the last remaining binary operator that could be used in a unary context.
+The name @{}@ comes from the syntax for the initializer: @struct S { int i, j; } s = `{` 2, 3 `}`@\footnote{%
+The symbol \lstinline+^+ is used for the destructor name because it was the last binary operator that could be used in a unary context.}.
 Like other \CFA operators, these names represent the syntax used to call the constructor or destructor, \eg @?{}(x, ...)@ or @^{}(x, ...)@.
 The constructor and destructor have return type @void@ and a first parameter of reference to the object type to be constructed or destructs.
+The constructor and destructor have return type @void@, and the first parameter is a reference to the object type to be constructed or destructed.
 While the first parameter is informally called the @this@ parameter, as in object-oriented languages, any variable name may be used.
 Both constructors and destructors allow additional parametes after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
 …
 };
 void ?{}( VLA & vla ) with ( vla ) {            $\C{// default constructor}$
         len = 10;  data = alloc( len );
+        len = 10;  data = alloc( len );                 $\C{// shallow copy}$
+}
 void ^?{}( VLA & vla ) with ( vla ) {           $\C{// destructor}$
 …
 }                                                                                       $\C{// implicit:  ?\^{}\{\}( x );}$
 \end{cfa}
+(Note, the example is purposely kept simple by using shallow-copy semantics.)
 @VLA@ is a \newterm{managed type}\footnote{
 A managed type affects the runtime environment versus a self-contained type.}: a type requiring a non-trivial constructor or destructor, or with a field of a managed type.
 A managed type is implicitly constructed upon allocation and destructed upon deallocation to ensure proper interaction with runtime resources, in this case the @data@ array in the heap.
 For details of the placement of implicit constructor and destructor calls among complex executable statements see~\cite[\S~2.2]{Schluntz17}.
+A managed type is implicitly constructed at allocation and destructed at deallocation to ensure proper interaction with runtime resources, in this case, the @data@ array in the heap.
+For details of the code-generation placement of implicit constructor and destructor calls among complex executable statements see~\cite[\S~2.2]{Schluntz17}.
 \CFA also provides syntax for \newterm{initialization} and \newterm{copy}:
 …
 In some circumstance programmers may not wish to have constructor and destructor calls.
 In these cases, \CFA provides the initialization syntax \lstinline|S x @= {}|, and the object becomes unmanaged, so constructors and destructors calls are not generated.
+In these cases, \CFA provides the initialization syntax \lstinline|S x @= {}|, and the object becomes unmanaged, so implicit constructor and destructor calls are not generated.
 Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics.
 The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert to implicit initialization.
 …
 C already includes limited polymorphism for literals -- @0@ can be either an integer or a pointer literal, depending on context, while the syntactic forms of literals of the various integer and float types are very similar, differing from each other only in suffix.
+In keeping with the general \CFA approach of adding features while respecting ``the C way'' of doing things, we have extended both C's polymorphic zero and typed literal syntax to interoperate with user-defined types, while maintaining a backwards-compatible semantics.
+In keeping with the general \CFA approach of adding features while respecting the ``C-style'' of doing things, C's polymorphic constants and typed literal syntax are extended to interoperate with user-defined types, while maintaining a backwards-compatible semantics.
+A trivial example is allowing the underscore to separate prefixes, digits, and suffixes in all \CFA constants, as in Ada, \eg @0x`_`1.ffff`_`ffff`_`p`_`128`_`l@.
 …
+\subsection{Integral Suffixes}
+Additional integral suffixes are added to cover all the integral types and lengths.
+\begin{cquote}
+\lstDeleteShortInline@%
+\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
+\begin{cfa}
+_hh     // signed char
+_hhu   // unsigned char
+_h      // signed short int
+_uh    // unsigned short int
+z        // size_t
+\end{cfa}
+&
+\begin{cfa}
+_L8     // int8_t
+_ul8    // uint8_t
+_l16    // int16_t
+_ul16  // uint16_t
+_l32    // int32_t
+\end{cfa}
+&
+\begin{cfa}
+_ul32      // uint32_t
+_l64        // int64_t
+_l64u      // uint64_t
+_L128     // int128
+_L128u  // unsigned int128
+\end{cfa}
+\end{tabular}
+\lstMakeShortInline@%
+\end{cquote}
 \subsection{Units}
 …
 \begin{cfa}
 struct Weight { double stones; };
 void ?{}( Weight & w ) { w.stones = 0; }        $\C{// operations}$
 void ?{}( Weight & w, double w ) { w.stones = w; }
 …
 int main() {
+        Weight w, hw = { 14 };                                  $\C{// 14 stone}$
+        w = 11|`st| + 1|`lb|;
+        w = 70.3|`kg|;
+        Weight w, heavy = { 20 };                               $\C{// 20 stone}$
         w = 155|`lb|;
         w = 0x_9b_u|`lb|;                                               $\C{// hexadecimal unsigned weight (155)}$
         w = 0_233|`lb|;                                                 $\C{// octal weight (155)}$
         w = 5|`st| + 8|`kg| + 25|`lb| + hw;
+        w = 5|`st| + 8|`kg| + 25|`lb| + heavy;
+}
 \end{cfa}
 …
 \end{cquote}
 While \Celeven has type-generic math~\cite[\S~7.25]{C11} in @tgmath.h@ to provide a similar mechanism, these macros are limited, matching a routine name with a single set of floating type(s).
 For example, it is not possible to overload @atan@ for both one and two arguments;
+For example, it is impossible to overload @atan@ for both one and two arguments;
 instead the names @atan@ and @atan2@ are required.
 The key observation is that only a restricted set of type-generic macros are provided for a limited set of routine names, which do not generalize across the type system, as in \CFA.
 …
 ip = alloc( ip, 2 * dim );
 ip = alloc( ip, 4 * dim, fill );
+ip = align_alloc( 16 );
+ip = align_alloc( 16, fill );
+ip = align_alloc( 16, dim );
+ip = align_alloc( 16, dim, fill );
 \end{cfa}
+&
 …
 ip = (int *)realloc( ip, 2 * dim * sizeof( int ) );
 ip = (int *)realloc( ip, 4 * dim * sizeof( int ) ); memset( ip, fill, 4 * dim * sizeof( int ) );
+\end{cfa}
+\end{tabular}
+\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
+\begin{cfa}
+ip = align_alloc( 16 );
+ip = align_alloc( 16, fill );
+ip = align_alloc( 16, dim );
+ip = align_alloc( 16, dim, fill );
+\end{cfa}
+&
+\begin{cfa}
 ip = memalign( 16, sizeof( int ) );
 ip = memalign( 16, sizeof( int ) ); memset( ip, fill, sizeof( int ) );
 …
 The implicit separator character (space/blank) is a separator not a terminator.
 The rules for implicitly adding the separator are:
 \begin{itemize}[topsep=3pt,itemsep=2pt,parsep=0pt]
+\begin{itemize}
 \item
 A separator does not appear at the start or end of a line.
 …
 A separator does not appear before or after a C string beginning/ending with the quote or whitespace characters: \lstinline[basicstyle=\tt,showspaces=true]@`'": \t\v\f\r\n@
 }%
 \item
+\end{itemize}
 There are routines to set and get the separator string, and manipulators to toggle separation on and off in the middle of output.
-\end{itemize}
 …
         sout | "Factorial Numbers" | endl;
         Int fact = 1;
         sout | 0 | fact | endl;
         for ( unsigned int i = 1; i <= 40; i += 1 ) {
 …
 int main( void ) {
         `gmp_printf`( "Factorial Numbers\n" );
+        `mpz_t` fact;
+        `mpz_init_set_ui`( fact, 1 );
+        `mpz_t` fact;  `mpz_init_set_ui`( fact, 1 );
         `gmp_printf`( "%d %Zd\n", 0, fact );
         for ( unsigned int i = 1; i <= 40; i += 1 ) {

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

Context Navigation

Changeset 4ada74e for doc/papers/general

Legend:

doc/papers/general/Paper.tex

Download in other formats: