Changeset 387c9a1


Ignore:
Timestamp:
May 7, 2018, 6:23:40 PM (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:
5fec3f6, 83034ec
Parents:
c5e5109
Message:

corrections for referee responses

File:
1 edited

Legend:

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

    rc5e5109 r387c9a1  
    5959%\DeclareTextCommandDefault{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}
    6060\renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
     61
     62\renewcommand*{\thefootnote}{\alph{footnote}} % hack because fnsymbol does not work
     63%\renewcommand*{\thefootnote}{\fnsymbol{footnote}}
    6164
    6265\makeatletter
     
    197200The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects.
    198201This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
    199 Nevertheless, C, first standardized almost fourty years ago, lacks many features that make programming in more modern languages safer and more productive.
     202Nevertheless, C, first standardized almost forty years ago, lacks many features that make programming in more modern languages safer and more productive.
    200203
    201204The goal of the \CFA project (pronounced ``C-for-all'') is to create an extension of C that provides modern safety and productivity features while still ensuring strong backwards compatibility with C and its programmers.
     
    233236Love it or hate it, C is extremely popular, highly used, and one of the few systems languages.
    234237In many cases, \CC is often used solely as a better C.
    235 Nevertheless, C, first standardized almost fourty years ago~\cite{ANSI89:C}, lacks many features that make programming in more modern languages safer and more productive.
     238Nevertheless, C, first standardized almost forty years ago~\cite{ANSI89:C}, lacks many features that make programming in more modern languages safer and more productive.
    236239
    237240\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.
     
    299302The \CFA tests are 290+ files and 27,000+ lines of code.
    300303The tests illustrate syntactic and semantic features in \CFA, plus a growing number of runtime benchmarks.
    301 The tests check for correctness and are used for daily regression testing of commits (3800+).
     304The tests check for correctness and are used for daily regression testing of 3800+ commits.
    302305
    303306Finally, it is impossible to describe a programming language without usages before definitions.
     
    348351\eg, it cannot implement the example above, because the variables @max@ are ambiguous with the functions @max@.
    349352Ergonomic 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 dispatch functions, which must all have distinct names.
    350 For backwards compatibility, \CFA supports @_Generic@ expressions, but it is an unnecessary mechanism. \TODO{actually implement that}
     353\CFA supports @_Generic@ expressions for backwards compatibility, but it is an unnecessary mechanism. \TODO{actually implement that}
    351354
    352355% http://fanf.livejournal.com/144696.html
     
    543546\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
    544547\begin{cfa}
    545 forall( otype R, otype S ) struct pair {
     548`forall( otype R, otype S )` struct pair {
    546549        R first;        S second;
    547550};
     
    11801183  case Mon~Thu:  // program
    11811184
    1182   case Fri:  // program
     1185  case Fri:    // program
    11831186        wallet += pay;
    11841187        `fallthrough;`
    1185   case Sat:  // party
     1188  case Sat:   // party
    11861189        wallet -= party;
    11871190
    11881191  case Sun:  // rest
    11891192
    1190   default:  // error
     1193  default:    // print error
    11911194}
    11921195\end{cfa}
     
    11961199  case Mon: case Tue: case Wed: case Thu:  // program
    11971200        `break;`
    1198   case Fri:  // program
     1201  case Fri:    // program
    11991202        wallet += pay;
    12001203
    1201   case Sat:  // party
     1204  case Sat:   // party
    12021205        wallet -= party;
    12031206        `break;`
    12041207  case Sun:  // rest
    12051208        `break;`
    1206   default:  // error
     1209  default:    // print error
    12071210}
    12081211\end{cfa}
     
    14771480If an exception is raised and caught, the handler is run before the finally clause.
    14781481Like a destructor (see Section~\ref{s:ConstructorsDestructors}), a finally clause can raise an exception but not if there is an exception being propagated.
    1479 Mimicking the @finally@ clause with mechanisms like RAII is non-trivially when there are multiple types and local accesses.
     1482Mimicking the @finally@ clause with mechanisms like RAII is non-trivial when there are multiple types and local accesses.
    14801483
    14811484
     
    15301533with ( s, t ) {
    15311534        j + k;                                                                  $\C{// unambiguous, s.j + t.k}$
    1532         m = 5.0;                                                                $\C{// unambiguous, t.m = 5.0}$
    1533         m = 1;                                                                  $\C{// unambiguous, s.m = 1}$
    1534         int a = m;                                                              $\C{// unambiguous, a = s.i }$
    1535         double b = m;                                                   $\C{// unambiguous, b = t.m}$
     1535        m = 5.0;                                                                $\C{// unambiguous, s.m = 5.0}$
     1536        m = 1;                                                                  $\C{// unambiguous, t.m = 1}$
     1537        int a = m;                                                              $\C{// unambiguous, a = t.m }$
     1538        double b = m;                                                   $\C{// unambiguous, b = s.m}$
    15361539        int c = s.i + t.i;                                              $\C{// unambiguous, qualification}$
    1537         (double)m;                                                              $\C{// unambiguous, cast}$
     1540        (double)m;                                                              $\C{// unambiguous, cast s.m}$
    15381541}
    15391542\end{cfa}
     
    15591562and implicitly opened \emph{after} a function-body open, to give them higher priority:
    15601563\begin{cfa}
    1561 void ?{}( S & s, int `i` ) with ( s ) `with( $\emph{\color{red}params}$ )` {
     1564void ?{}( S & s, int `i` ) with ( s ) `{` `with( $\emph{\color{red}params}$ )` {
    15621565        s.i = `i`; j = 3; m = 5.5;
    1563 }
     1566} `}`
    15641567\end{cfa}
    15651568Finally, a cast may be used to disambiguate among overload variables in a @with@ expression:
     
    16601663\begin{cfa}
    16611664`*` int x, y;
    1662 int y;
    1663 \end{cfa}
    1664 &
    1665 \begin{cfa}
    1666 int `*`x, `*`y;
     1665int z;
     1666\end{cfa}
     1667&
     1668\begin{cfa}
     1669int `*`x, `*`y, z;
    16671670
    16681671\end{cfa}
     
    16701673\lstMakeShortInline@%
    16711674\end{cquote}
    1672 The downside of the \CFA semantics is the need to separate regular and pointer declarations.
     1675% The downside of the \CFA semantics is the need to separate regular and pointer declarations.
     1676The separation of regular and pointer declarations by \CFA declarations enforces greater clarity with only slightly more syntax.
    16731677
    16741678\begin{comment}
     
    17921796* [ * int, int ] ( int ) jp;    $\C{// pointer to function returning pointer to int and int with int parameter}$
    17931797\end{cfa}
    1794 Note, a function name cannot be specified:
    1795 \begin{cfa}
    1796 * [ int x ] f () fp;                    $\C{// function name "f" is disallowed}\CRT$
    1797 \end{cfa}
     1798Note, the name of the function pointer is specified last, as for other variable declarations.
    17981799
    17991800Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
     
    26372638
    26382639
    2639 \section{Polymorphism Evaluation}
     2640\section{Polymorphic Evaluation}
    26402641\label{sec:eval}
    26412642
Note: See TracChangeset for help on using the changeset viewer.