Context Navigation

-                      r93401f8
+                      r14cbfad
 C already has a limited form of ad-hoc polymorphism in the form of its basic arithmetic operators, which apply to a variety of different types using identical syntax.
+\CFA extends the built-in operator overloading by allowing users to define overloads for any function, not just operators, and even any variable; Section~\ref{sec:libraries} includes a number of examples of how this overloading simplifies \CFA programming relative to C.
+\CFA extends the built-in operator overloading by allowing users to define overloads for any function, not just operators, and even any variable;
+Section~\ref{sec:libraries} includes a number of examples of how this overloading simplifies \CFA programming relative to C.
 Code generation for these overloaded functions and variables is implemented by the usual approach of mangling the identifier names to include a representation of their type, while \CFA decides which overload to apply based on the same ``usual arithmetic conversions'' used in C to disambiguate operator overloads.
 As an example:
 …
 The macro wrapping the generic expression imposes some limitations; as an example, it could not implement the example above, because the variables @max@ would collide with the functions @max@.
 Ergonomic limitations of @_Generic@ include the necessity to put a fixed list of supported types in a single place and manually dispatch to appropriate overloads, as well as possible namespace pollution from the functions dispatched to, which must all have distinct names.
+% http://fanf.livejournal.com/144696.html
+% http://www.robertgamble.net/2012/01/c11-generic-selections.html
+% https://abissell.com/2014/01/16/c11s-_generic-keyword-macro-applications-and-performance-impacts/
 \subsection{\texorpdfstring{\LstKeywordStyle{forall} Functions}{forall Functions}}
 …
 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 float values */ };
 double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
 …
         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 );
 …
 \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.
+\CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations (see Section~\ref{sec:libraries}).
 For example, it is possible to write a type-safe \CFA wrapper @malloc@ based on the C @malloc@:
 \begin{lstlisting}
 …
 \CFA provides \newterm{traits} to name a group of type assertions, where the trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration:
 \begin{lstlisting}
 trait summable( otype T ) {
+trait `summable`( otype T ) {
         void ?{}( T *, zero_t );                                $\C{// constructor from 0 literal}$
         T ?+?( T, T );                                                  $\C{// assortment of additions}$
 …
         T ++?( T * );
         T ?++( T * ); };
 forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) {  // use trait
         `T` total = { `0` };                                    $\C{// instantiate T from 0 by calling its constructor}$
 …
 forall( otype T ) T value( pair( const char *, T ) p ) { return p.second; }
 forall( dtype F, otype T ) T value_p( pair( F *, T * ) p ) { return * p.second; }
 pair( const char *, int ) p = { "magic", 42 };
 int magic = value( p );
 …
 @case@ clauses are made disjoint by the @break@ statement.
 While the ability to fall through \emph{is} a useful form of control flow, it does not match well with programmer intuition, resulting in many errors from missing @break@ statements.
 \CFA provides a new control structure, @choose@, which mimics @switch@, but reverses the meaning of fall through:
+For backwards compatibility, \CFA provides a \emph{new} control structure, @choose@, which mimics @switch@, but reverses the meaning of fall through:
 \begin{cquote}
 \lstDeleteShortInline@%
 …
 \begin{cfa}
 `choose` ( day ) {
+  case Mon~Thu:
+        // program
+  case Fri:
+        // program
+  case Mon~Thu:  // program
+  case Fri:  // program
         wallet += pay;
         `fallthrough;`
+  case Sat:
+        // party
+  case Sat:  // party
         wallet -= party;
+  case Sun:
+        // rest
+  default:
+        // error
+  case Sun:  // rest
+  default:  // error
+}
 \end{cfa}
 …
 \begin{cfa}
 switch ( day ) {
+  case Mon: case Tue: case Wed: case Thu:
+        // program
+  case Mon: case Tue: case Wed: case Thu:  // program
         `break;`
+  case Fri:
+        // program
+  case Fri:  // program
         wallet += pay;
+  case Sat:
+        // party
+  case Sat:  // party
         wallet -= party;
         `break;`
+  case Sun:
+        // rest
+  case Sun:  // rest
         `break;`
+  default:
+        // error
+  default:  // error
+}
 \end{cfa}
 …
 \label{s:WithClauseStatement}
 Grouping heterogenous data into \newterm{aggregate}s (structure/union) is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers:
+Grouping heterogeneous data into \newterm{aggregate}s (structure/union) is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers:
 \begin{cfa}
 struct S {                                                                      $\C{// aggregate}$
 …
+}
 \end{cfa}
+which extends to multiple levels of qualification for nested aggregates.
 A similar situation occurs in object-oriented programming, \eg \CC:
 \begin{C++}
 …
         int i;
         double d;
         int mem() {                                                             $\C{// implicit "this" parameter}$
+        int f() {                                                               $\C{// implicit "this" parameter}$
                 `this->`c; `this->`i; `this->`d;        $\C{// access containing fields}$
+        }
+}
 \end{C++}
 Nesting of member routines in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
+Object-oriented nesting of member routines in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
 However, for other aggregate parameters, qualification is necessary:
 \begin{cfa}
 struct T { double m, n; };
 int C::mem( T & t ) {                                           $\C{// multiple aggregate parameters}$
+int C::f( T & t ) {                                                     $\C{// multiple aggregate parameters}$
         c; i; d;                                                                $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$
         `t.`m; `t.`n;                                                   $\C{// must qualify}$
 …
 \end{cfa}
+% In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided.
+% In any programming language, some functions have a naturally close relationship with a particular data type.
+% Object-oriented programming allows this close relationship to be codified in the language by making such functions \newterm{class methods} of their related data type.
+% Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type.
+% When writing C functions in an object-oriented style, this un-prefixed access is swiftly missed, as access to fields of a @Foo* f@ requires an extra three characters @f->@ every time, which disrupts coding flow and clutters the produced code.
+%
+% \TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.}
+To simplify the programmer experience, \CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
+To simplify the programmer experience, \CFA provides a @with@ statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
 Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block.
 \begin{cfa}
+void f( S s ) `with( s )` {                                     $\C{// with clause}$
+        c; i; d;                                                                $\C{\color{red}// s.c, s.i, s.d}$
+}
+\end{cfa}
+and the equivalence for object-style programming is:
+\begin{cfa}
+int mem( S & this ) `with( this )` {            $\C{// with clause}$
+void f( S & this ) `with ( this )` {            $\C{// with statement}$
         c; i; d;                                                                $\C{\color{red}// this.c, this.i, this.d}$
+}
 …
 with the generality of opening multiple aggregate-parameters:
 \begin{cfa}
 int mem( S & s, T & t ) `with( s, t )` {        $\C{// multiple aggregate parameters}$
+int f( S & s, T & t ) `with ( s, t )` {         $\C{// multiple aggregate parameters}$
         c; i; d;                                                                $\C{\color{red}// s.c, s.i, s.d}$
         m; n;                                                                   $\C{\color{red}// t.m, t.n}$
 …
 \end{cfa}
 In detail, the @with@ clause/statement has the form:
+In detail, the @with@ statement has the form:
 \begin{cfa}
 $\emph{with-statement}$:
 …
 All expressions in the expression list are open in ``parallel'' within the compound statement.
 This semantic is different from Pascal, which nests the openings.
 The difference between parallel and nesting occurs for fields with the same name but different type:
 \begin{cfa}
 struct S { int i; int j; double m; } s, w;
 struct T { int i; int k; int m } t, w;
 with( s, t ) {
         j + k;                                                                  $\C{// unambiguous, s.j + t.m}$
+This semantic is different from Pascal, which nests the openings from left to right.
+The difference between parallel and nesting occurs for fields with the same name and type:
+\begin{cfa}
+struct S { int `i`; int j; double m; } s, w;
+struct T { int `i`; int k; int m; } t, w;
+with ( s, t ) {
+        j + k;                                                                  $\C{// unambiguous, s.j + t.k}$
         m = 5.0;                                                                $\C{// unambiguous, t.m = 5.0}$
         m = 1;                                                                  $\C{// unambiguous, s.m = 1}$
+        int a = s.i + m;                                                $\C{// unambiguous, a = s.i + t.i}$
+        int b = s.i + t.i;                                              $\C{// unambiguous, qualification}$
+        sout | (double)m | endl;                                $\C{// unambiguous, cast}$
+        i;                                                                              $\C{// ambiguous}$
+}
+\end{cfa}
+\CFA's ability to overload variables means usages of field with the same names can be automatically disambiguated, eliminating most qualification.
+        int a = m;                                                              $\C{// unambiguous, a = s.i }$
+        double b = m;                                                   $\C{// unambiguous, b = t.m}$
+        int c = s.i + t.i;                                              $\C{// unambiguous, qualification}$
+        (double)m;                                                              $\C{// unambiguous, cast}$
+}
+\end{cfa}
+For parallel semantics, both @s.i@ and @t.i@ are visible, so @i@ is ambiguous without qualification;
+for nested semantics, @t.i@ hides @s.i@, so @i@ implies @t.i@.
+\CFA's ability to overload variables means fields with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates.
 Qualification or a cast is used to disambiguate.
+A cast may be necessary to disambiguate between the overload variables in a @with@ expression:
+\begin{cfa}
+with( w ) { ... }                                                       $\C{// ambiguous, same name and no context}$
+with( (S)w ) { ... }                                            $\C{// unambiguous}$
+\end{cfa}
+There is an interesting problem between parameters and the routine @with@, \eg:
+\begin{cfa}
+void ?{}( S & s, int i ) with ( s ) {           $\C{// constructor}$
+        `s.i = i;` j = 3; m = 5.5;
+}
+\end{cfa}
+Here, the assignment @s.i = i@ means @s.i = s.i@, which is meaningless, and there is no mechanism to qualify the parameter @i@, making the assignment impossible using the routine @with@.
+To solve this problem, parameters are treated like an initialized aggregate:
+\begin{cfa}
+struct Params {
+        S & s;
+        int i;
+} params;
+\end{cfa}
+and implicitly opened \emph{after} a routine open, to give them higher priority:
+\begin{cfa}
+void ?{}( S & s, int i ) with ( s ) `with( $\emph{\color{red}params}$ )` {
+        s.i = i; j = 3; m = 5.5;
+}
+\end{cfa}
+Finally, a cast may be used to disambiguate among overload variables in a @with@ expression:
+\begin{cfa}
+with ( w ) { ... }                                                      $\C{// ambiguous, same name and no context}$
+with ( (S)w ) { ... }                                           $\C{// unambiguous, cast}$
+\end{cfa}
+and @with@ expressions may be pointers and references (see Section~\ref{s:References}) to aggregates:
 \begin{cfa}
 struct S { int i, j; } sv;
 with( sv ) {
+with ( sv ) {                                                           $\C{variable}$
         S & sr = sv;
         with( sr ) {
+        with ( sr ) {                                                   $\C{reference}$
                 S * sp = &sv;
                 with( *sp ) {
+                with ( *sp ) {                                          $\C{pointer}$
                         i = 3; j = 4;                                   $\C{\color{red}// sp-{\textgreater}i, sp-{\textgreater}j}$
+                }
 …
 \end{cfa}
-The statement form is used within a block:
-\begin{cfa}
-int foo() {
-        struct S1 { ... } s1;
-        struct S2 { ... } s2;
-        `with( s1 )` {                                                  $\C{// with statement}$
-                // access fields of s1 without qualification
-                `with( s2 )` {                                          $\C{// nesting}$
-                        // access fields of s1 and s2 without qualification
+                }
+        }
-        `with( s1, s2 )` {
-                // access unambiguous fields of s1 and s2 without qualification
+        }
+}
-\end{cfa}
 % \subsection{Exception Handling ???}
 \section{Declarations}
 …
 \subsection{References}
+\label{s:References}
 All variables in C have an \newterm{address}, a \newterm{value}, and a \newterm{type};

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

Context Navigation

Changeset 14cbfad for doc/papers

Legend:

doc/papers/general/Paper.tex

Download in other formats: