Changeset a95310e3

Timestamp:

Apr 5, 2017, 10:38:55 AM (8 years ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

7a026ff

Parents:

8f5bf6d

Message:

more squeezing on pages 1-4

File:

• doc/generic_types/generic_types.tex (modified) (4 diffs)

doc/generic_types/generic_types.tex

@@ -149 +149 @@
 Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
 
-\CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. Four key design goals were set out in the original design of \CFA~\citep{Bilson03}:
+\CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. The four key design goals for \CFA~\citep{Bilson03} are:
 (1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;
 (2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler;
 (3) \CFA code must be at least as portable as standard C code;
 (4) Extensions introduced by \CFA must be translated in the most efficient way possible.
-These goals ensure existing C code-bases can be converted to \CFA incrementally and with minimal effort, and C programmers can productively generate \CFA code without training beyond the features they wish to employ. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance.
-
-\CFA has been previously extended with polymorphic functions and name overloading (including operator overloading) by \citet{Bilson03}, and deterministically-executed constructors and destructors by \citet{Schluntz17}. This paper builds on those contributions, identifying shortcomings in existing approaches to generic and variadic data types in C-like languages and presenting a design for generic and variadic types avoiding those shortcomings. Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions. The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance.
+These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance.
+
+This paper identifies shortcomings in existing approaches to generic and variadic data types in C-like languages and presents a design for generic and variadic types avoiding those shortcomings. Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions. The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance.
 
 
@@ -224 +224 @@
 Call-site inferencing and nested functions provide a localized form of inheritance. For example, @qsort@ only sorts in ascending order using @<@. However, it is trivial to locally change this behaviour:
 \begin{lstlisting}
-{   int ?<?( double x, double y ) { return x `>` y; }   $\C{// override behaviour}$
+{
+        int ?<?( double x, double y ) { return x `>` y; }       $\C{// override behaviour}$
         qsort( vals, size );                                    $\C{// descending sort}$
 }
@@ -257 +258 @@
 \begin{lstlisting}
 trait summable( otype T ) {
-        void ?{}(T*, zero_t);                                   $\C{// constructor from 0 literal}$
+        void ?{}( T *, zero_t );                                $\C{// constructor from 0 literal}$
         T ?+?( T, T );                                                  $\C{// assortment of additions}$
         T ?+=?( T *, T );
@@ -263 +264 @@
         T ?++( T * );
 };
-forall( otype T | summable( T ) )
-  T sum( T a[$\,$], size_t size ) {
-        `T` total = { `0` };                                    $\C{// instantiate T from 0 but calling its constructor}$
+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}$
         for ( unsigned int i = 0; i < size; i += 1 )
                 total `+=` a[i];                                        $\C{// select appropriate +}$