Changeset 3d60c08 for doc/papers


Ignore:
Timestamp:
May 8, 2018, 9:20:23 PM (6 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, with_gc
Children:
b4a835d
Parents:
83034ec
Message:

complete referee changes

Location:
doc/papers/general
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • doc/papers/general/Makefile

    r83034ec r3d60c08  
    4444clean :
    4545        @rm -frv ${DOCUMENT} ${BASE}.ps WileyNJD-AMA.bst ${BASE}.out.ps ${Build}
     46
     47Paper.zip :
     48        zip -x general/.gitignore -x general/"*AMA*" -x general/Paper.out.ps -x general/Paper.tex.plain -x general/evaluation.zip -x general/mail -x general/response -x general/test.c -x general/evaluation.zip -x general/Paper.tex.plain -x general/Paper.ps -x general/Paper.pdf -x general/"*build*" -x general/evaluation/.gitignore -x general/evaluation/timing.xlsx -r Paper.zip general
    4649
    4750evaluation.zip :

  • doc/papers/general/Paper.tex

    r83034ec r3d60c08  
    6060\renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
    6161
    62 \renewcommand*{\thefootnote}{\alph{footnote}} % hack because fnsymbol does not work
     62\renewcommand*{\thefootnote}{\Alph{footnote}} % hack because fnsymbol does not work
    6363%\renewcommand*{\thefootnote}{\fnsymbol{footnote}}
    6464
    … …  
    249249All languages features discussed in this paper are working, except some advanced exception-handling features.
    250250Not discussed in this paper are the integrated concurrency-constructs and user-level threading-library~\cite{Delisle18}.
    251 \CFA is an \emph{open-source} project implemented as an source-to-source translator from \CFA to the gcc-dialect of C~\cite{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
     251\CFA is an \emph{open-source} project implemented as a source-to-source translator from \CFA to the gcc-dialect of C~\cite{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
    252252Ultimately, a compiler is necessary for advanced features and optimal performance.
    253253% @plg2[9]% cd cfa-cc/src; cloc ArgTweak CodeGen CodeTools Common Concurrency ControlStruct Designators GenPoly InitTweak MakeLibCfa.cc MakeLibCfa.h Parser ResolvExpr SymTab SynTree Tuples driver prelude main.cc
    … …  
    323323There are only two hard things in Computer Science: cache invalidation and \emph{naming things} -- Phil Karlton
    324324\end{quote}
    325 \vspace{-10pt}
     325\vspace{-9pt}
    326326C 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.
    327327\CFA extends the built-in operator overloading by allowing users to define overloads for any function, not just operators, and even any variable;
    … …  
    438438Hence, programmers can easily form local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
    439439
    440 To reducing duplication, it is possible to distribute a group of @forall@ (and storage-class qualifiers) over functions/types, so each block declaration is prefixed by the group (see example in Appendix~\ref{s:CforallStack}).
     440To reduce duplication, it is possible to distribute a group of @forall@ (and storage-class qualifiers) over functions/types, so each block declaration is prefixed by the group (see example in Appendix~\ref{s:CforallStack}).
    441441\begin{cfa}
    442442forall( otype `T` ) {                                                   $\C{// distribution block, add forall qualifier to declarations}$
    … …  
    480480\end{cquote}
    481481
    482 In fact, the set of @summable@ trait operators is incomplete, as it is missing assignment for type @T@, but @otype@ is syntactic sugar for the following implicit trait:
     482Note, the @sumable@ trait does not include a copy constructor needed for the right side of @?+=?@ and return;
     483it is provided by @otype@, which is syntactic sugar for the following trait:
    483484\begin{cfa}
    484485trait otype( dtype T | sized(T) ) {  // sized is a pseudo-trait for types with known size and alignment
    … …  
    498499Instead, each polymorphic function (or generic type) defines the structural type needed for its execution (polymorphic type-key), and this key is fulfilled at each call site from the lexical environment, which is similar to Go~\cite{Go} interfaces.
    499500Hence, new lexical scopes and nested functions are used extensively to create local subtypes, as in the @qsort@ example, without having to manage a nominal-inheritance hierarchy.
    500 (Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.)
     501% (Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.)
    501502
    502503% Nominal inheritance can be simulated with traits using marker variables or functions:
    … …  
    525526
    526527
    527 \vspace*{-2pt}
    528528\section{Generic Types}
    529529
    … …  
    571571Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
    572572A \newterm{dtype-static} type has polymorphic parameters but is still concrete.
    573 Polymorphic pointers are an example of dtype-static types, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@  is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation.
     573Polymorphic pointers are an example of dtype-static types;
     574given some type variable @T@, @T@ is a polymorphic type, as is @T *@, but @T *@ has a fixed size and can therefore be represented by @void *@ in code generation.
    574575
    575576\CFA generic types also allow checked argument-constraints.
    … …  
    955956}
    956957\end{cfa}
    957 One more step permits the summation of any summable type with all arguments of the same type:
    958 \begin{cfa}
    959 trait summable( otype T ) {
     958One more step permits the summation of any sumable type with all arguments of the same type:
     959\begin{cfa}
     960trait sumable( otype T ) {
    960961        T ?+?( T, T );
    961962};
    962 forall( otype R | summable( R ) ) R sum( R x, R y ) {
     963forall( otype R | sumable( R ) ) R sum( R x, R y ) {
    963964        return x + y;
    964965}
    965 forall( otype R, ttype Params | summable(R) | { R sum(R, Params); } ) R sum(R x, R y, Params rest) {
     966forall( otype R, ttype Params | sumable(R) | { R sum(R, Params); } ) R sum(R x, R y, Params rest) {
    966967        return sum( x + y, rest );
    967968}
    … …  
    11081109\begin{cquote}
    11091110\lstDeleteShortInline@%
    1110 \begin{tabular}{@{}l|@{\hspace{2\parindentlnth}}l@{}}
    1111 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     1111\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
     1112\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    11121113\begin{cfa}
    11131114case 2, 10, 34, 42:
    … …  
    11241125\lstDeleteShortInline@%
    11251126\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1126 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     1127\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    11271128\begin{cfa}
    11281129case 2~42:
    … …  
    11781179\lstDeleteShortInline@%
    11791180\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
    1180 \multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     1181\multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    11811182\begin{cfa}
    11821183`choose` ( day ) {
    … …  
    12241225\lstDeleteShortInline@%
    12251226\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
    1226 \multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{non-terminator}}  & \multicolumn{1}{c}{\textbf{target label}}     \\
     1227\multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{non-terminator}}       & \multicolumn{1}{c@{}}{\textbf{target label}}  \\
    12271228\begin{cfa}
    12281229choose ( ... ) {
    … …  
    12681269\lstDeleteShortInline@%
    12691270\begin{tabular}{@{\hspace{\parindentlnth}}l|@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
    1270 \multicolumn{1}{@{\hspace{\parindentlnth}}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}}      \\
     1271\multicolumn{1}{@{\hspace{\parindentlnth}}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{@{\hspace{\parindentlnth}}c@{}}{\textbf{C}}   \\
    12711272\begin{cfa}
    12721273`LC:` {
    … …  
    13641365\lstDeleteShortInline@%
    13651366\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
    1366 \multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{Resumption}}      & \multicolumn{1}{c}{\textbf{Termination}}      \\
     1367\multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{Resumption}}   & \multicolumn{1}{c@{}}{\textbf{Termination}}   \\
    13671368\begin{cfa}
    13681369`exception R { int fix; };`
    … …  
    16321633\lstDeleteShortInline@%
    16331634\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    1634 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     1635\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    16351636\begin{cfa}
    16361637`[5] *` int x1;
    … …  
    16601661\lstDeleteShortInline@%
    16611662\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1662 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     1663\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    16631664\begin{cfa}
    16641665`*` int x, y;
    … …  
    16811682\lstDeleteShortInline@%
    16821683\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    1683 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
     1684\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
    16841685\begin{cfa}
    16851686[ 5 ] int z;
    … …  
    17231724\lstDeleteShortInline@%
    17241725\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    1725 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
     1726\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
    17261727\begin{cfa}
    17271728extern const * const int x;
    … …  
    17481749\lstDeleteShortInline@%
    17491750\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1750 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     1751\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    17511752\begin{cfa}
    17521753y = (* int)x;
    … …  
    17761777\lstDeleteShortInline@%
    17771778\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1778 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     1779\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    17791780\begin{cfa}
    17801781[double] foo(), foo( int ), foo( double ) {...}
    … …  
    17941795* [ * int ] ( int y ) gp;               $\C{// pointer to function returning pointer to int with int parameter}$
    17951796* [ ] ( int, char ) hp;                 $\C{// pointer to function returning no result with int and char parameters}$
    1796 * [ * int, int ] ( int ) jp;    $\C{// pointer to function returning pointer to int and int with int parameter}$
     1797* [ * int, int ] ( int ) jp;    $\C{// pointer to function returning pointer to int and int with int parameter}\CRT$
    17971798\end{cfa}
    17981799Note, the name of the function pointer is specified last, as for other variable declarations.
    … …  
    19931994The symbol \lstinline+^+ is used for the destructor name because it was the last binary operator that could be used in a unary context.}.
    19941995The name @{}@ comes from the syntax for the initializer: @struct S { int i, j; } s = `{` 2, 3 `}`@.
    1995 Like other \CFA operators, these names represent the syntax used to call the constructor or destructor, \eg @?{}(x, ...)@ or @^{}(x, ...)@.
     1996Like other \CFA operators, these names represent the syntax used to explicitly call the constructor or destructor, \eg @s{...}@ or @^s{...}@.
    19961997The constructor and destructor have return type @void@, and the first parameter is a reference to the object type to be constructed or destructed.
    19971998While the first parameter is informally called the @this@ parameter, as in object-oriented languages, any variable name may be used.
    1998 Both constructors and destructors allow additional parametes after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
     1999Both constructors and destructors allow additional parameters after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
    19992000Destruction parameters are useful for specifying storage-management actions, such as de-initialize but not deallocate.}.
    20002001\begin{cfa}
    … …  
    20032004void ^?{}( VLA & vla ) with ( vla ) { free( data ); } $\C{// destructor}$
    20042005{
    2005         VLA x;                                                                  $\C{// implicit:  ?\{\}( x );}$
    2006 }                                                                                       $\C{// implicit:  ?\^{}\{\}( x );}$
     2006        VLA x;                                                                  $\C{// implicit:\ \ x\{\};}$
     2007}                                                                                       $\C{// implicit:\ \textasciicircum{}x\{\};}$
    20072008\end{cfa}
    20082009@VLA@ is a \newterm{managed type}\footnote{
    … …  
    20292030appropriate care is taken to not recursively call the copy constructor when initializing the second parameter.
    20302031
    2031 \CFA constructors may be explicitly call, like Java, and destructors may be explicitly called, like \CC.
     2032\CFA constructors may be explicitly called, like Java, and destructors may be explicitly called, like \CC.
    20322033Explicit calls to constructors double as a \CC-style \emph{placement syntax}, useful for construction of member fields in user-defined constructors and reuse of existing storage allocations.
    2033 While existing call syntax works for explicit calls to constructors and destructors, \CFA also provides a more concise \newterm{operator syntax} for both:
     2034Like the other operators in \CFA, there is a concise syntax for constructor/destructor function calls:
    20342035\begin{cfa}
    20352036{
    20362037        VLA  x,            y = { 20, 0x01 },     z = y; $\C{// z points to y}$
    2037         //      ?{}( x );   ?{}( y, 20, 0x01 );   ?{}( z, y );
     2038        //    x{};         y{ 20, 0x01 };          z{ z, y };
    20382039        ^x{};                                                                   $\C{// deallocate x}$
    20392040        x{};                                                                    $\C{// reallocate x}$
    … …  
    20422043        y{ x };                                                                 $\C{// reallocate y, points to x}$
    20432044        x{};                                                                    $\C{// reallocate x, not pointing to y}$
    2044         // ^?{}(z);  ^?{}(y);  ^?{}(x);
     2045        //  ^z{};  ^y{};  ^x{};
    20452046}
    20462047\end{cfa}
    … …  
    20632064In these cases, \CFA provides the initialization syntax \lstinline|S x `@=` {}|, and the object becomes unmanaged, so implicit constructor and destructor calls are not generated.
    20642065Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics.
    2065 The same syntax can be used in a compound literal, \eg \lstinline|a = VLA`@`{ 0, 0x0 }|, to create a C-style literal.
     2066The same syntax can be used in a compound literal, \eg \lstinline|a = (VLA)`@`{ 0, 0x0 }|, to create a C-style literal.
    20662067The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert to implicit initialization.
    20672068
    … …  
    21192120
    21202121In C, @0@ has the special property that it is the only ``false'' value;
    2121 from the standard, any value that compares equal to @0@ is false, while any value that compares unequal to @0@ is true.
     2122by the standard, any value that compares equal to @0@ is false, while any value that compares unequal to @0@ is true.
    21222123As such, an expression @x@ in any boolean context (such as the condition of an @if@ or @while@ statement, or the arguments to @&&@, @||@, or @?:@\,) can be rewritten as @x != 0@ without changing its semantics.
    21232124Operator overloading in \CFA provides a natural means to implement this truth-value comparison for arbitrary types, but the C type system is not precise enough to distinguish an equality comparison with @0@ from an equality comparison with an arbitrary integer or pointer.
    … …  
    21542155\lstDeleteShortInline@%
    21552156\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    2156 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{postfix function}}        & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{constant}}      & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{variable/expression}}   & \multicolumn{1}{c}{\textbf{postfix pointer}}  \\
     2157\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{postfix function}}     & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{constant}}      & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{variable/expression}}   & \multicolumn{1}{c@{}}{\textbf{postfix pointer}}       \\
    21572158\begin{cfa}
    21582159int |?`h|( int s );
    … …  
    21992200\lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}}
    22002201\lstDeleteShortInline@%
    2201 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2202 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{\CC}}      \\
     2202\begin{tabular}{@{}l@{\hspace{1.25\parindentlnth}}l@{}}
     2203\multicolumn{1}{@{}c@{\hspace{1.25\parindentlnth}}}{\textbf{\CFA}}      & \multicolumn{1}{c@{}}{\textbf{\CC}}   \\
    22032204\begin{cfa}
    22042205struct W {
    … …  
    22742275\lstDeleteShortInline@%
    22752276\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2276 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
     2277\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}   & \multicolumn{1}{c@{}}{\textbf{Usage}} \\
    22772278\begin{cfa}
    22782279const short int `MIN` = -32768;
    … …  
    22932294\lstDeleteShortInline@%
    22942295\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
    2295 \multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
     2296\multicolumn{1}{@{}c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    22962297\begin{cfa}
    22972298MIN
    … …  
    23192320\lstDeleteShortInline@%
    23202321\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2321 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
     2322\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}   & \multicolumn{1}{c@{}}{\textbf{Usage}} \\
    23222323\begin{cfa}
    23232324float `log`( float x );
    … …  
    23382339\lstDeleteShortInline@%
    23392340\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2340 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     2341\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    23412342\begin{cfa}
    23422343log
    … …  
    23662367\lstDeleteShortInline@%
    23672368\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2368 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
     2369\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}   & \multicolumn{1}{c@{}}{\textbf{Usage}} \\
    23692370\begin{cfa}
    23702371unsigned int `abs`( int );
    … …  
    23852386\lstDeleteShortInline@%
    23862387\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2387 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
     2388\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    23882389\begin{cfa}
    23892390abs
    … …  
    24082409an allocation with a specified character.
    24092410\item[resize]
    2410 an existing allocation to decreased or increased its size.
     2411an existing allocation to decrease or increase its size.
    24112412In either case, new storage may or may not be allocated and, if there is a new allocation, as much data from the existing allocation is copied.
    24122413For an increase in storage size, new storage after the copied data may be filled.
    … …  
    24472448\begin{figure}
    24482449\centering
    2449 \begin{cquote}
    2450 \begin{cfa}[aboveskip=0pt]
     2450\begin{cfa}[aboveskip=0pt,xleftmargin=0pt]
    24512451size_t  dim = 10;                                                       $\C{// array dimension}$
    24522452char fill = '\xff';                                                     $\C{// initialization fill value}$
    … …  
    24542454\end{cfa}
    24552455\lstDeleteShortInline@%
    2456 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2457 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    2458 \begin{cfa}
     2456\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
     2457\multicolumn{1}{@{}c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     2458\begin{cfa}[xleftmargin=-10pt]
    24592459ip = alloc();
    24602460ip = alloc( fill );
    … …  
    24712471&
    24722472\begin{cfa}
    2473 ip = (int *)malloc( sizeof( int ) );
    2474 ip = (int *)malloc( sizeof( int ) ); memset( ip, fill, sizeof( int ) );
    2475 ip = (int *)malloc( dim * sizeof( int ) );
    2476 ip = (int *)malloc( sizeof( int ) ); memset( ip, fill, dim * sizeof( int ) );
    2477 ip = (int *)realloc( ip, 2 * dim * sizeof( int ) );
    2478 ip = (int *)realloc( ip, 4 * dim * sizeof( int ) );
    2479                         memset( ip, fill, 4 * dim * sizeof( int ) );
    2480 ip = memalign( 16, sizeof( int ) );
    2481 ip = memalign( 16, sizeof( int ) ); memset( ip, fill, sizeof( int ) );
    2482 ip = memalign( 16, dim * sizeof( int ) );
    2483 ip = memalign( 16, dim * sizeof( int ) ); memset( ip, fill, dim * sizeof( int ) );
    2484 \end{cfa}
    2485 \end{tabular}
    2486 \lstMakeShortInline@%
    2487 \end{cquote}
     2473ip = (int *)malloc( sizeof(int) );
     2474ip = (int *)malloc( sizeof(int) ); memset( ip, fill, sizeof(int) );
     2475ip = (int *)malloc( dim * sizeof(int) );
     2476ip = (int *)malloc( sizeof(int) ); memset( ip, fill, dim * sizeof(int) );
     2477ip = (int *)realloc( ip, 2 * dim * sizeof(int) );
     2478ip = (int *)realloc( ip, 4 * dim * sizeof(int) ); memset( ip, fill, 4 * dim * sizeof(int));
     2479
     2480ip = memalign( 16, sizeof(int) );
     2481ip = memalign( 16, sizeof(int) ); memset( ip, fill, sizeof(int) );
     2482ip = memalign( 16, dim * sizeof(int) );
     2483ip = memalign( 16, dim * sizeof(int) ); memset( ip, fill, dim * sizeof(int) );
     2484\end{cfa}
     2485\end{tabular}
     2486\lstMakeShortInline@%
    24882487\caption{\CFA versus C Storage-Allocation}
    24892488\label{f:StorageAllocation}
    … …  
    24982497S * as = anew( dim, 2, 3 );                                     $\C{// each array element initialized to 2, 3}$
    24992498\end{cfa}
    2500 Note, \CC can only initialization array elements via the default constructor.
     2499Note, \CC can only initialize array elements via the default constructor.
    25012500
    25022501Finally, the \CFA memory-allocator has \newterm{sticky properties} for dynamic storage: fill and alignment are remembered with an object's storage in the heap.
    … …  
    25152514\lstDeleteShortInline@%
    25162515\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2517 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{\CC}}      \\
     2516\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{\CC}}   \\
    25182517\begin{cfa}
    25192518int x = 1, y = 2, z = 3;
    … …  
    26042603\centering
    26052604\lstDeleteShortInline@%
    2606 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}@{\hspace{2\parindentlnth}}l@{}}
    2607 \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{@{\hspace{2\parindentlnth}}c}{\textbf{C}}     \\
     2605\begin{tabular}{@{}l@{\hspace{3\parindentlnth}}l@{}}
     2606\multicolumn{1}{@{}c@{\hspace{3\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    26082607\begin{cfa}
    26092608#include <gmp>
    … …  
    26382637
    26392638
    2640 \section{Polymorphic Evaluation}
     2639\section{Polymorphism Evaluation}
    26412640\label{sec:eval}
    26422641
    … …  
    27272726Line-count is a fairly rough measure of code complexity;
    27282727another important factor is how much type information the programmer must specify manually, especially where that information is not compiler-checked.
    2729 Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of untype-checked downcasts, \eg @object@ to @integer@ when popping a stack.
     2728Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts, \eg @object@ to @integer@ when popping a stack.
    27302729To quantify this manual typing, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is respecified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression.
    27312730The \CC benchmark uses two redundant type annotations to create a new stack nodes, while the C and \CCV benchmarks have several such annotations spread throughout their code.
    27322731The \CFA benchmark is able to eliminate all redundant type annotations through use of the polymorphic @alloc@ function discussed in Section~\ref{sec:libraries}.
    27332732
    2734 We conjecture these results scale across most generic data-types as the underlying polymorphic implement is constant.
     2733We conjecture these results scale across most generic data-types as the underlying polymorphism implement is constant.
    27352734
    27362735

  • doc/papers/general/response

    r83034ec r3d60c08  
    6161judithbishop@outlook.com
    6262
     63
     64We have attempted to response to all the issues raised by the Editor and referee's comments. For two
     65of the issues, we have "pushed back", with an explanation. Specifically, moving the related work
     66forward, and moving text from Section 9 into the captions of Table2 and Figure 10.  Our reasons for
     67not making these changes are address below. Finally, as pointed out below, there are a couple of
     68issues with the Wiley LaTeX macros that we worked around as best as possible.
     69
     70   The paper is long by SPE standards (33 pages). We have a maximum of 40 pages. Please do not
     71   extend the paper beyond 35 pages. If necessary, find ways to cut the examples or text. If you
     72   have an accompanying website for the system where some examples are stored, please mention it.
     73
     74The paper is 35 pages using the supplied Wiley LaTeX macros.
     75
     76
    6377Referee(s)' Comments to Author:
    6478
    6579Reviewing: 1
    6680
    67    Most of the content in Section 10 RELATED WORK appears to belong to Section
    68    1 INTRODUCTION as a Subsection or as a new Section after Section 1. (Please
    69    also see #4.1 below.) Remaining discussion that cannot be moved earlier can
    70    become a DISCUSSION Section or a Subsection within the last Section of the
    71    paper.
    72 
    73 Sometimes it is appropriate to put related work at the start of a paper and
    74 sometimes at the end. For this paper, it seems appropriate to put the related
    75 work at the end of the paper. The purpose of the related work in this paper is
    76 two fold: to introduce prior work and to contrast it with Cforall.  Only at the
    77 end of the paper does the reader have sufficient knowledge about Cforall to
    78 make detailed contrasts with other programming languages possible. If the
    79 related work is moved to the end of the introduction, the reader knows nothing
    80 about Cforall so talking about other programming languages in isolation makes
    81 little sense, especially non-C-related languages, like Java, Go, Rust,
    82 Haskell. We see no easy way to separate the related work into a general
    83 discussion at the start and a specific discussion at the end. We explicitly
    84 attempt to deal with the reader's anticipation at the end of the introduction:
    85 
    86  Finally, it is impossible to describe a programming language without usages
    87  before definitions.  Therefore, syntax and semantics appear before
    88  explanations; hence, patience is necessary until details are presented.
    89 
    90 
    91    2. Presentation
    92 
    93    2.1 More information should be moved from the text and added to Figure 10 and
    94    Table 2 so that readers can understand the comparison quickly. Imagine a reader
    95    read the summary and jump directly to these two display elements. Questions
    96    would be raised about the binary size and pop pair result of Cforall and it
    97    would take time to find answers in the text.
    98 
    99 This suggestion is an alternative writing style. The experiment is complex
    100 enough that it is unlikely a reader could jump to the table/graph and
    101 understand the experiment without putting a substantive amount of the text from
    102 Section 9 into the table and figure, which the reader then has to read anyway.
    103 In fact, we prefer a writing style where the reader does not have to look at
    104 the table/figure to understand the experiment and the results, i.e., the
    105 table/figure are only there to complement the discussion.
    106 
    107    2.2 The pronunciation of ("C-for-all") should be provided in the summary
    108    (page 1 line 22) so that people not having an access to the full-text can
    109    see it.
     81   Most of the content in Section 10 RELATED WORK appears to belong to Section 1 INTRODUCTION as a
     82   Subsection or as a new Section after Section 1. (Please also see #4.1 below.) Remaining
     83   discussion that cannot be moved earlier can become a DISCUSSION Section or a Subsection within
     84   the last Section of the paper.
     85
     86Sometimes it is appropriate to put related work at the start of a paper and sometimes at the
     87end. For this paper, it seems appropriate to put the related work at the end of the paper. The
     88purpose of the related work in this paper is two fold: to introduce prior work and to contrast it
     89with Cforall.  Only at the end of the paper does the reader have sufficient knowledge about Cforall
     90to make detailed contrasts with other programming languages possible. If the related work is moved
     91to the end of the introduction, the reader knows nothing about Cforall so talking about other
     92programming languages in isolation makes little sense, especially non-C-related languages, like
     93Java, Go, Rust, Haskell. We see no easy way to separate the related work into a general discussion
     94at the start and a specific discussion at the end. We explicitly attempt to deal with the reader's
     95anticipation at the end of the introduction:
     96
     97 Finally, it is impossible to describe a programming language without usages before definitions.
     98 Therefore, syntax and semantics appear before explanations; hence, patience is necessary until
     99 details are presented.
     100
     101
     102   2.1 More information should be moved from the text and added to Figure 10 and Table 2 so that
     103   readers can understand the comparison quickly. Imagine a reader read the summary and jump
     104   directly to these two display elements. Questions would be raised about the binary size and pop
     105   pair result of Cforall and it would take time to find answers in the text.
     106
     107This suggestion is an alternative writing style. The experiment is complex enough that it is
     108unlikely a reader could jump to the table/graph and understand the experiment without putting a
     109substantive amount of the text from Section 9 into the table and figure, which the reader then has
     110to read anyway.  In fact, we prefer a writing style where the reader does not have to look at the
     111table/figure to understand the experiment and the results, i.e., the table/figure are only there to
     112complement the discussion.
     113
     114
     115   2.2 The pronunciation of ("C-for-all") should be provided in the summary (page 1 line 22) so that
     116   people not having an access to the full-text can see it.
    110117
    111118Done.
    112119
    113    2.3 Error comment in the code should be written with the same capitalization
    114    and it will be helpful if you say specifically compilation error or runtime
    115    error. (Please see attached annotated manuscript.)
    116 
    117 Fixed. All errors in the paper are compilation errors because they are related
    118 to the type system.
    119 
    120    2.4 It is possible to provide a bit more information in Appendix A e.g. how
    121    many lines/bytes of code and some details about software/hardware can be
    122    added/moved here. The aim is to provide sufficient information for readers
    123    to reproduce the results and to appreciate the context of the comparison.
    124 
    125 Table 2 indicates the source-code size in lines of code. The third paragraph of
    126 Section 9 gives precise details of the software/hardware used in the
    127 experiments.
     120
     121   2.3 Error comment in the code should be written with the same capitalization and it will be
     122   helpful if you say specifically compilation error or runtime error. (Please see attached
     123   annotated manuscript.)
     124
     125Fixed. All errors in the paper are compilation errors because they are related to the type system.
     126
     127
     128   2.4 It is possible to provide a bit more information in Appendix A e.g. how many lines/bytes of
     129   code and some details about software/hardware can be added/moved here. The aim is to provide
     130   sufficient information for readers to reproduce the results and to appreciate the context of the
     131   comparison.
     132
     133Table 2 indicates the source-code size in lines of code. The third paragraph of Section 9 gives
     134precise details of the software/hardware used in the experiments.
    128135
    129136   3. Practical information about the work
    130137
    131    There are three separate pieces of information on pages 2 ("All features
    132    discussed in this paper are working, unless otherwise stated as under
    133    construction."),
     138   There are three separate pieces of information on pages 2 ("All features discussed in this paper
     139   are working, unless otherwise stated as under construction."),
    134140
    135141This sentence is replace with:
    136142
    137  All languages features discussed in this paper are working, except some
    138  advanced exception-handling features.
     143 All languages features discussed in this paper are working, except some advanced exception-handling
     144 features.
    139145
    140146and Section 5.4 Exception Handling states:
    141147
    142  The following framework for Cforall exception handling is in place, excluding
    143  some runtime type-information and virtual functions.
     148 The following framework for Cforall exception handling is in place, excluding some runtime
     149 type-information and virtual functions.
     150
    144151
    145152   page 4 ("Under construction is a mechanism to distribute...")
    … …  
    147154The feature on page 4 is now complete.
    148155
     156
    149157   and page 33 ("There is ongoing work on a wide range ... ")
    150158
    151159This sentence is replace to indicate the ongoing work is future work.
    152160
    153  While all examples in the paper compile and run, a public beta-release of
    154  Cforall will take 6-8 months to reduce compilation time, provide better
    155  debugging, and add a few more libraries.  There is also new work on a number
    156  of Cforall features, including arrays with size, runtime type-information,
    157  virtual functions, user-defined conversions, and modules.
    158 
    159    My recommendation is to move them to an appendix so that the length is
    160    preserved.
    161 
    162 There is nothing to move into an appendix, except 3 sentences. We do not intend
    163 to discuss these items in this paper.
    164 
    165    3.1 Any under construction work (only small part of page 4) should not be
    166    mingled into the main part of the manuscript.
     161 While all examples in the paper compile and run, a public beta-release of Cforall will take 6-8
     162 months to reduce compilation time, provide better debugging, and add a few more libraries.  There
     163 is also new work on a number of Cforall features, including arrays with size, runtime
     164 type-information, virtual functions, user-defined conversions, and modules.
     165
     166
     167   My recommendation is to move them to an appendix so that the length is preserved.
     168
     169There is nothing to move into an appendix, except 3 sentences. We do not intend to discuss these
     170items in this paper.
     171
     172
     173   3.1 Any under construction work (only small part of page 4) should not be mingled into the main
     174   part of the manuscript.
    167175
    168176See above.
    169177
    170    3.2 Instructions on how to access/use the working functionality of Cforall
    171    should be given.
    172 
    173 We will indicate release of Cforall in a public location, when we believe the
    174 code base is acceptable. In the interim, we have made public all the
    175 experimental code from section 9, and there is a reference in the paper to
    176 access this code. We can make a private beta-copy of Cforall available to the
    177 SP&E editor for distribution to the referees so they can verify our claims.
    178 
    179    3.3 Planned work should be given a specific time of completion/release not
    180    just "8-12 months".
    181 
    182 Software development is not rigorous engineering discipline. Given our small
    183 research development-team and the size of the project, we cannot give a
    184 specific time for completion of anything associated with the project. Having
    185 said that, we have reduced our expected time for Cforall release to 6-8 months
    186 as work is progressing well.
    187 
    188 
    189    4. Citations
    190 
    191    4.1 The impression after reading Section 1 INTRODUCTION is that the
    192    referencing is poor. It is not until Section 10 RELATED WORK where majority
    193    of the prior literature are discussed. Please consider moving the content
    194    and improve citations - at least cite all main variations of C languages.
     178
     179   3.2 Instructions on how to access/use the working functionality of Cforall should be given.
     180
     181We will indicate release of Cforall in a public location, when we believe the code base is
     182acceptable. In the interim, we have made public all the experimental code from section 9, and there
     183is a reference in the paper to access this code. We can make a private beta-copy of Cforall
     184available to the SP&E editor for distribution to the referees so they can verify our claims.
     185
     186   3.3 Planned work should be given a specific time of completion/release not just "8-12 months".
     187
     188Software development is not a rigorous engineering discipline. Given our small research
     189development-team and the size of the project, we cannot give a specific time for completion of
     190anything associated with the project. Having said that, we have reduced our expected time for
     191Cforall release to 6-8 months as work is progressing well.
     192
     193
     194   4.1 The impression after reading Section 1 INTRODUCTION is that the referencing is poor. It is
     195   not until Section 10 RELATED WORK where majority of the prior literature are discussed. Please
     196   consider moving the content and improve citations - at least cite all main variations of C
     197   languages.
    195198
    196199See point 1.
    197200
    198    4.2 I also would like to see citations at these specific places: Page 2
    199    after Phil Karlton, page 22 after const hell problem.
     201
     202   4.2 I also would like to see citations at these specific places: Page 2 after Phil Karlton, page
     203   22 after const hell problem.
    200204
    201205The Phil-Karlton quote is an urban legend without a specific academic citation:
    … …  
    205209The term "const hell" is replaced with "const poisoning" with a citation.
    206210
    207    5.1 Footnotes and citations will need to have different schemes - number and
    208    perhaps letter.
    209 
    210 The latex macros from Wiley generate those symbols. I assume during
    211 copy-editing the format is changed to suit the journal format.
    212 
    213    5.2 Many references are not properly formatted e.g. date is incomplete,
    214    extra/missing white spaces, extra dots, use of page number or section number
    215    as part of superscript ref number. Please refer to attached document.
    216 
    217 Agreed. The bibtex BST macros are at fault. I have fixed some issues but I
    218 cannot fix them all as my BST macro-knowledge is limited.
     211
     212   5.1 Footnotes and citations will need to have different schemes - number and perhaps letter.
     213
     214Switched to letters. SP&E uses symbol footnotes but this macros fails with their macros:
     215
     216 \renewcommand*{\thefootnote}{\fnsymbol{footnote}}
     217
     218
     219   5.2 Many references are not properly formatted e.g. date is incomplete, extra/missing white
     220   spaces, extra dots, use of page number or section number as part of superscript ref
     221   number. Please refer to attached document.
     222
     223Agreed. The bibtex BST macros are at fault. I have fixed some issues but I cannot fix them all as my
     224BST macro-knowledge is limited.
     225
    219226
    220227   5.3 Typos:
    … …  
    233240
    234241   6. Conflict of interest
    235    I see that the work is partially supported by Huawei. Perhaps statement
    236    about any presence or absence of conflicts of interest should be explicitly
    237    added. Please get a clear direction on this from the editor of the journal.
    238 
    239 The paper now states the project is open-source, hence there is no conflict of
    240 interest with the funding received from Huawei.
     242   I see that the work is partially supported by Huawei. Perhaps statement about any presence or
     243   absence of conflicts of interest should be explicitly added. Please get a clear direction on this
     244   from the editor of the journal.
     245
     246The paper now states the project is open-source, hence there is no conflict of interest with the
     247funding received from Huawei.
    241248
    242249
    … …  
    245252Comments to the Author
    246253
    247    Overloading requires the compiler to mangle a function's signature into its
    248    name in the object file.  I'm pretty sure that this will complicate the
    249    build process of mixed Cforall/C projects.
    250 
    251 There is no complexity with building Cforall/C programs, and there is an
    252 existence proof because C++ has name mangling for overloading and has no problem
    253 interacting with C.
    254 
    255    I found the evaluation underwhelming.  There were only ~200 LoC ported from
    256    C to Cforall.  This is too less to encounter potential caveats Cforall's
    257    type system might impose.
    258 
    259 
    260 
    261    Also, how is the compiler implemented?  I guess, Cforall is a
    262    source-to-source compiler (from Cforall to C).  But this is left in the
    263    dark.  What features are actually implemented?
    264 
    265 The following paragraph has been added to the introduction to address this
    266 comment:
    267 
    268  All languages features discussed in this paper are working, except some
    269  advanced exception-handling features.  Not discussed in this paper are the
    270  integrated concurrency-constructs and user-level
    271  threading-library~\cite{Delisle18}.  Cforall is an open-source project
    272  implemented as an source-to-source translator from Cforall to the gcc-dialect
    273  of C~\cite{GCCExtensions}, allowing it to leverage the portability and code
    274  optimizations provided by gcc, meeting goals (1)--(3).  Ultimately, a compiler
    275  is necessary for advanced features and optimal performance.  The Cforall
    276  translator is 200+ files and 46,000+ lines of code written in C/C++.  Starting
    277  with a translator versus a compiler makes it easier and faster to generate and
    278  debug C object-code rather than intermediate, assembler or machine code.  The
    279  translator design is based on the visitor pattern, allowing multiple passes
    280  over the abstract code-tree, which works well for incrementally adding new
    281  feature through additional visitor passes.  At the heart of the translator is
    282  the type resolver, which handles the polymorphic routine/type
    283  overload-resolution.  The Cforall runtime system is 100+ files and 11,000+
    284  lines of code, written in Cforall.  Currently, the Cforall runtime is the
    285  largest user of Cforall providing a vehicle to test the language features and
    286  implementation.  The Cforall tests are 290+ files and 27,000+ lines of code.
    287  The tests illustrate syntactic and semantic features in Cforall, plus a
    288  growing number of runtime benchmarks.  The tests check for correctness and are
    289  used for daily regression testing of commits (3800+).
    290 
    291    Furthermore, the article lacks some related work.  Many proposed features
    292    are present in functional languages such as Haskell, ML etc.  In particular,
    293    the dealing of parametric polymorphism reminds me of Haskell.
     254   Overloading requires the compiler to mangle a function's signature into its name in the object
     255   file.  I'm pretty sure that this will complicate the build process of mixed Cforall/C projects.
     256
     257There is no complexity with building Cforall/C programs, and there is an existence proof because C++
     258has name mangling for overloading and has no problem interacting with C.
     259
     260
     261   I found the evaluation underwhelming.  There were only ~200 LoC ported from C to Cforall.  This
     262   is too less to encounter potential caveats Cforall's type system might impose.
     263
     264We have clarified that the evaluation is not for the type system, but rather the underlying
     265implementation approach for the parametric polymorphism. Section 9 now starts:
     266
     267 Cforall adds parametric polymorphism to C.  A runtime evaluation is performed to compare the cost
     268 of alternative styles of polymorphism.  The goal is to compare just the underlying mechanism for
     269 implementing different kinds of polymorphism.
     270
     271and ends with:
     272
     273 We conjecture these results scale across most generic data-types as the underlying polymorphic
     274 implement is constant.
     275 
     276
     277   Also, how is the compiler implemented?  I guess, Cforall is a source-to-source compiler (from
     278   Cforall to C).  But this is left in the dark.  What features are actually implemented?
     279
     280The following paragraph has been added to the introduction to address this comment:
     281
     282 All languages features discussed in this paper are working, except some advanced exception-handling
     283 features.  Not discussed in this paper are the integrated concurrency-constructs and user-level
     284 threading-library~\cite{Delisle18}.  Cforall is an open-source project implemented as an
     285 source-to-source translator from Cforall to the gcc-dialect of C~\cite{GCCExtensions}, allowing it
     286 to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
     287 Ultimately, a compiler is necessary for advanced features and optimal performance.  The Cforall
     288 translator is 200+ files and 46,000+ lines of code written in C/C++.  Starting with a translator
     289 versus a compiler makes it easier and faster to generate and debug C object-code rather than
     290 intermediate, assembler or machine code.  The translator design is based on the visitor pattern,
     291 allowing multiple passes over the abstract code-tree, which works well for incrementally adding new
     292 feature through additional visitor passes.  At the heart of the translator is the type resolver,
     293 which handles the polymorphic routine/type overload-resolution.  The Cforall runtime system is 100+
     294 files and 11,000+ lines of code, written in Cforall.  Currently, the Cforall runtime is the largest
     295 user of Cforall providing a vehicle to test the language features and implementation.  The Cforall
     296 tests are 290+ files and 27,000+ lines of code.  The tests illustrate syntactic and semantic
     297 features in Cforall, plus a growing number of runtime benchmarks.  The tests check for correctness
     298 and are used for daily regression testing of commits (3800+).
     299
     300
     301   Furthermore, the article lacks some related work.  Many proposed features are present in
     302   functional languages such as Haskell, ML etc.  In particular, the dealing of parametric
     303   polymorphism reminds me of Haskell.
    294304
    295305The following paragraph has been added at the start of Section 10.1:
    296306
    297  ML~\cite{ML} was the first language to support parametric polymorphism.  Like
    298  Cforall, it supports universal type parameters, but not the use of assertions
    299  and traits to constrain type arguments.  Haskell~\cite{Haskell10} combines
    300  ML-style polymorphism, polymorphic data types, and type inference with the
    301  notion of type classes, collections of overloadable methods that correspond in
    302  intent to traits in Cforall.  Unlike Cforall, Haskell requires an explicit
    303  association between types and their classes that specifies the implementation
    304  of operations.  These associations determine the functions that are assertion
    305  arguments for particular combinations of class and type, in contrast to
    306  Cforall where the assertion arguments are selected at function call sites
    307  based upon the set of operations in scope at that point.  Haskell also
    308  severely restricts the use of overloading: an overloaded name can only be
    309  associated with a single class, and methods with overloaded names can only be
    310  defined as part of instance declarations.
    311 
    312    Cforall's approach to tuples is also quite similar to many functional
    313    languages.
     307 ML~\cite{ML} was the first language to support parametric polymorphism.  Like Cforall, it supports
     308 universal type parameters, but not the use of assertions and traits to constrain type arguments.
     309 Haskell~\cite{Haskell10} combines ML-style polymorphism, polymorphic data types, and type inference
     310 with the notion of type classes, collections of overloadable methods that correspond in intent to
     311 traits in Cforall.  Unlike Cforall, Haskell requires an explicit association between types and
     312 their classes that specifies the implementation of operations.  These associations determine the
     313 functions that are assertion arguments for particular combinations of class and type, in contrast
     314 to Cforall where the assertion arguments are selected at function call sites based upon the set of
     315 operations in scope at that point.  Haskell also severely restricts the use of overloading: an
     316 overloaded name can only be associated with a single class, and methods with overloaded names can
     317 only be defined as part of instance declarations.
     318
     319
     320   Cforall's approach to tuples is also quite similar to many functional languages.
    314321
    315322At the end of Section 10.2, we state:
    316323
    317  Tuples are a fundamental abstraction in most functional programming languages,
    318  such as Standard ML, Haskell}, and Scala, which decompose tuples using pattern
    319  matching.
     324 Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML,
     325 Haskell}, and Scala, which decompose tuples using pattern matching.
    320326
    321327
Note: See TracChangeset for help on using the changeset viewer.