Ignore:
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:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/generic_types/generic_types.tex

    r8f5bf6d ra95310e3  
    149149Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
    150150
    151 \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}:
     151\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:
    152152(1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;
    153153(2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler;
    154154(3) \CFA code must be at least as portable as standard C code;
    155155(4) Extensions introduced by \CFA must be translated in the most efficient way possible.
    156 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.
    157 
    158 \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.
     156These 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.
     157
     158This 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.
    159159
    160160
     
    224224Call-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:
    225225\begin{lstlisting}
    226 {   int ?<?( double x, double y ) { return x `>` y; }   $\C{// override behaviour}$
     226{
     227        int ?<?( double x, double y ) { return x `>` y; }       $\C{// override behaviour}$
    227228        qsort( vals, size );                                    $\C{// descending sort}$
    228229}
     
    257258\begin{lstlisting}
    258259trait summable( otype T ) {
    259         void ?{}(T*, zero_t);                                   $\C{// constructor from 0 literal}$
     260        void ?{}( T *, zero_t );                                $\C{// constructor from 0 literal}$
    260261        T ?+?( T, T );                                                  $\C{// assortment of additions}$
    261262        T ?+=?( T *, T );
     
    263264        T ?++( T * );
    264265};
    265 forall( otype T | summable( T ) )
    266   T sum( T a[$\,$], size_t size ) {
    267         `T` total = { `0` };                                    $\C{// instantiate T from 0 but calling its constructor}$
     266forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) {  // use trait
     267        `T` total = { `0` };                                    $\C{// instantiate T from 0 by calling its constructor}$
    268268        for ( unsigned int i = 0; i < size; i += 1 )
    269269                total `+=` a[i];                                        $\C{// select appropriate +}$
Note: See TracChangeset for help on using the changeset viewer.