Changeset 59c034c


Ignore:
Timestamp:
May 23, 2018, 8:59:45 AM (3 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, with_gc
Children:
6f9bc09, b9da9585
Parents:
2c88368
Message:

small updates

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/papers/general/Paper.tex

    r2c88368 r59c034c  
    243243Nevertheless, C, first standardized almost forty years ago~\cite{ANSI89:C}, lacks many features that make programming in more modern languages safer and more productive.
    244244
    245 \CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that adds modern language-features to C, while maintaining both source and runtime compatibility with C and a familiar programming model for programmers.
     245\CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that adds modern language-features to C, while maintaining source and runtime compatibility in the familiar C programming model.
    246246The four key design goals for \CFA~\cite{Bilson03} are:
    247247(1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;
     
    273273Starting with a translator versus a compiler makes it easier and faster to generate and debug C object-code rather than intermediate, assembler or machine code.
    274274The translator design is based on the \emph{visitor pattern}, allowing multiple passes over the abstract code-tree, which works well for incrementally adding new feature through additional visitor passes.
    275 At the heart of the translator is the type resolver, which handles the polymorphic routine/type overload-resolution.
     275At the heart of the translator is the type resolver, which handles the polymorphic function/type overload-resolution.
    276276% @plg2[8]% cd cfa-cc/src; cloc libcfa
    277277% -------------------------------------------------------------------------------
     
    310310
    311311Finally, it is impossible to describe a programming language without usages before definitions.
    312 Therefore, syntax and semantics appear before explanations;
    313 hence, patience is necessary until details are presented.
     312Therefore, syntax and semantics appear before explanations, and related work (Section~\ref{s:RelatedWork}) is deferred until \CFA is presented;
     313hence, patience is necessary until details are discussed.
    314314
    315315
     
    329329\end{quote}
    330330\vspace{-9pt}
    331 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.
     331C already has a limited form of ad-hoc polymorphism in its basic arithmetic operators, which apply to a variety of different types using identical syntax.
    332332\CFA extends the built-in operator overloading by allowing users to define overloads for any function, not just operators, and even any variable;
    333333Section~\ref{sec:libraries} includes a number of examples of how this overloading simplifies \CFA programming relative to C.
     
    15351535The difference between parallel and nesting occurs for fields with the same name and type:
    15361536\begin{cfa}
    1537 struct S { int `i`; int j; double m; } s, w;
     1537struct S { int `i`; int j; double m; } s, w;    $\C{// field i has same type in structure types S and T}$
    15381538struct T { int `i`; int k; int m; } t, w;
    1539 with ( s, t ) {
     1539with ( s, t ) {                                                         $\C{// open structure variables s and t in parallel}$
    15401540        j + k;                                                                  $\C{// unambiguous, s.j + t.k}$
    15411541        m = 5.0;                                                                $\C{// unambiguous, s.m = 5.0}$
     
    20052005Destruction parameters are useful for specifying storage-management actions, such as de-initialize but not deallocate.}.
    20062006\begin{cfa}
    2007 struct VLA { int len, * data; };                        $\C{// variable length array of integers}$
    2008 void ?{}( VLA & vla ) with ( vla ) { len = 10;  data = alloc( len ); }  $\C{// default constructor}$
     2007struct VLA { int size, * data; };                       $\C{// variable length array of integers}$
     2008void ?{}( VLA & vla ) with ( vla ) { size = 10;  data = alloc( size ); }  $\C{// default constructor}$
    20092009void ^?{}( VLA & vla ) with ( vla ) { free( data ); } $\C{// destructor}$
    20102010{
     
    20192019\CFA also provides syntax for \newterm{initialization} and \newterm{copy}:
    20202020\begin{cfa}
    2021 void ?{}( VLA & vla, int size, char fill ) with ( vla ) {  $\C{// initialization}$
    2022         len = size;  data = alloc( len, fill );
     2021void ?{}( VLA & vla, int size, char fill = '\0' ) {  $\C{// initialization}$
     2022        vla.[ size, data ] = [ size, alloc( size, fill ) ];
    20232023}
    20242024void ?{}( VLA & vla, VLA other ) {                      $\C{// copy, shallow}$
    2025         vla.len = other.len;  vla.data = other.data;
     2025        vla = other;
    20262026}
    20272027\end{cfa}
     
    20482048        y{ x };                                                                 $\C{// reallocate y, points to x}$
    20492049        x{};                                                                    $\C{// reallocate x, not pointing to y}$
    2050         //  ^z{};  ^y{};  ^x{};
    2051 }
     2050}       //  ^z{};  ^y{};  ^x{};
    20522051\end{cfa}
    20532052
     
    27402739
    27412740\section{Related Work}
     2741\label{s:RelatedWork}
    27422742
    27432743
Note: See TracChangeset for help on using the changeset viewer.