Changes in / [78af962:de94a60]


Ignore:
Files:
12 added
12 deleted
5 edited

Legend:

Unmodified
Added
Removed

  • doc/bibliography/pl.bib

    r78af962 rde94a60  
    4040% @string{mathann="Math. Ann."}
    4141
     42@misc{CFAStackEvaluation,
     43    author      = {Aaron Moss},
     44    title       = {\textsf{C}$\mathbf{\forall}$ Stack Evaluation Programs},
     45    year        = 2018,
     46    howpublished= {\href{https://plg.uwaterloo.ca/~cforall/evaluation.zip}{https://plg.uwaterloo.ca/\-\-$\sim$cforall/\-StackEvaluation.zip}},
     47    optnote     = {[Accessed May 2018]},
     48}
     49
    4250% A
    4351
    … …  
    900908    address     = {Waterloo, Ontario, Canada, N2L 3G1},
    901909    note        = {\href{http://plg.uwaterloo.ca/theses/EstevesThesis.pdf}{http://\-plg.uwaterloo.ca/\-theses/\-EstevesThesis.pdf}},
    902 }
    903 
    904 @misc{CFAStackEvaluation,
    905     author      = {Aaron Moss},
    906     title       = {\textsf{C}$\mathbf{\forall}$ Stack Evaluation Programs},
    907     year        = 2018,
    908     howpublished= {\href{https://plg.uwaterloo.ca/~cforall/evaluation.zip}{https://plg.uwaterloo.ca/\-\-$\sim$cforall/\-StackEvaluation.zip}},
    909     optnote     = {[Accessed May 2018]},
    910910}
    911911
    … …  
    29672967    month       = jul, year = 1987,
    29682968    volume      = 4, number = 4, pages = {9-16}
    2969 }
    2970 
    2971 @misc{Sutter05c,
    2972     contributer = {pabuhr@plg},
    2973     title       = {The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software},
    2974     author      = {Herb Sutter},
    2975     howpublished= {\url{http://www.gotw.ca/publications/concurrency-ddj.htm}},
    2976     year        = {2005},
    2977     note        = {originally Dr. Dobb's Journal 30(3)},
    29782969}
    29792970

  • doc/papers/general/Makefile

    r78af962 rde94a60  
    4444clean :
    4545        @rm -frv ${DOCUMENT} ${BASE}.ps WileyNJD-AMA.bst ${BASE}.out.ps ${Build}
    46 
    47 Paper.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
    4946
    5047evaluation.zip :

  • doc/papers/general/Paper.tex

    r78af962 rde94a60  
    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 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).
     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).
    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{-9pt}
     325\vspace{-10pt}
    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 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}).
     440To 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}).
    441441\begin{cfa}
    442442forall( otype `T` ) {                                                   $\C{// distribution block, add forall qualifier to declarations}$
    … …  
    480480\end{cquote}
    481481
    482 Note, the @sumable@ trait does not include a copy constructor needed for the right side of @?+=?@ and return;
    483 it is provided by @otype@, which is syntactic sugar for the following trait:
     482In 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:
    484483\begin{cfa}
    485484trait otype( dtype T | sized(T) ) {  // sized is a pseudo-trait for types with known size and alignment
    … …  
    499498Instead, 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.
    500499Hence, 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.
    501 % (Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.)
     500(Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.)
    502501
    503502% Nominal inheritance can be simulated with traits using marker variables or functions:
    … …  
    526525
    527526
     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;
    574 given 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.
     573Polymorphic 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.
    575574
    576575\CFA generic types also allow checked argument-constraints.
    … …  
    956955}
    957956\end{cfa}
    958 One more step permits the summation of any sumable type with all arguments of the same type:
    959 \begin{cfa}
    960 trait sumable( otype T ) {
     957One more step permits the summation of any summable type with all arguments of the same type:
     958\begin{cfa}
     959trait summable( otype T ) {
    961960        T ?+?( T, T );
    962961};
    963 forall( otype R | sumable( R ) ) R sum( R x, R y ) {
     962forall( otype R | summable( R ) ) R sum( R x, R y ) {
    964963        return x + y;
    965964}
    966 forall( otype R, ttype Params | sumable(R) | { R sum(R, Params); } ) R sum(R x, R y, Params rest) {
     965forall( otype R, ttype Params | summable(R) | { R sum(R, Params); } ) R sum(R x, R y, Params rest) {
    967966        return sum( x + y, rest );
    968967}
    … …  
    11091108\begin{cquote}
    11101109\lstDeleteShortInline@%
    1111 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1112 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     1110\begin{tabular}{@{}l|@{\hspace{2\parindentlnth}}l@{}}
     1111\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    11131112\begin{cfa}
    11141113case 2, 10, 34, 42:
    … …  
    11251124\lstDeleteShortInline@%
    11261125\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1127 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     1126\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    11281127\begin{cfa}
    11291128case 2~42:
    … …  
    11791178\lstDeleteShortInline@%
    11801179\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
    1181 \multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     1180\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    11821181\begin{cfa}
    11831182`choose` ( day ) {
    … …  
    12251224\lstDeleteShortInline@%
    12261225\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
    1227 \multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{non-terminator}}       & \multicolumn{1}{c@{}}{\textbf{target label}}  \\
     1226\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{non-terminator}}  & \multicolumn{1}{c}{\textbf{target label}}     \\
    12281227\begin{cfa}
    12291228choose ( ... ) {
    … …  
    12691268\lstDeleteShortInline@%
    12701269\begin{tabular}{@{\hspace{\parindentlnth}}l|@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
    1271 \multicolumn{1}{@{\hspace{\parindentlnth}}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{@{\hspace{\parindentlnth}}c@{}}{\textbf{C}}   \\
     1270\multicolumn{1}{@{\hspace{\parindentlnth}}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}}      \\
    12721271\begin{cfa}
    12731272`LC:` {
    … …  
    13651364\lstDeleteShortInline@%
    13661365\begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
    1367 \multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{Resumption}}   & \multicolumn{1}{c@{}}{\textbf{Termination}}   \\
     1366\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{Resumption}}      & \multicolumn{1}{c}{\textbf{Termination}}      \\
    13681367\begin{cfa}
    13691368`exception R { int fix; };`
    … …  
    16331632\lstDeleteShortInline@%
    16341633\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    1635 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     1634\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    16361635\begin{cfa}
    16371636`[5] *` int x1;
    … …  
    16611660\lstDeleteShortInline@%
    16621661\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1663 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     1662\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    16641663\begin{cfa}
    16651664`*` int x, y;
    … …  
    16821681\lstDeleteShortInline@%
    16831682\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    1684 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
     1683\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
    16851684\begin{cfa}
    16861685[ 5 ] int z;
    … …  
    17241723\lstDeleteShortInline@%
    17251724\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    1726 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
     1725\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
    17271726\begin{cfa}
    17281727extern const * const int x;
    … …  
    17491748\lstDeleteShortInline@%
    17501749\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1751 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     1750\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    17521751\begin{cfa}
    17531752y = (* int)x;
    … …  
    17771776\lstDeleteShortInline@%
    17781777\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    1779 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     1778\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    17801779\begin{cfa}
    17811780[double] foo(), foo( int ), foo( double ) {...}
    … …  
    17951794* [ * int ] ( int y ) gp;               $\C{// pointer to function returning pointer to int with int parameter}$
    17961795* [ ] ( int, char ) hp;                 $\C{// pointer to function returning no result with int and char parameters}$
    1797 * [ * int, int ] ( int ) jp;    $\C{// pointer to function returning pointer to int and int with int parameter}\CRT$
     1796* [ * int, int ] ( int ) jp;    $\C{// pointer to function returning pointer to int and int with int parameter}$
    17981797\end{cfa}
    17991798Note, the name of the function pointer is specified last, as for other variable declarations.
    … …  
    19941993The symbol \lstinline+^+ is used for the destructor name because it was the last binary operator that could be used in a unary context.}.
    19951994The name @{}@ comes from the syntax for the initializer: @struct S { int i, j; } s = `{` 2, 3 `}`@.
    1996 Like other \CFA operators, these names represent the syntax used to explicitly call the constructor or destructor, \eg @s{...}@ or @^s{...}@.
     1995Like other \CFA operators, these names represent the syntax used to call the constructor or destructor, \eg @?{}(x, ...)@ or @^{}(x, ...)@.
    19971996The constructor and destructor have return type @void@, and the first parameter is a reference to the object type to be constructed or destructed.
    19981997While the first parameter is informally called the @this@ parameter, as in object-oriented languages, any variable name may be used.
    1999 Both constructors and destructors allow additional parameters after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
     1998Both constructors and destructors allow additional parametes after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
    20001999Destruction parameters are useful for specifying storage-management actions, such as de-initialize but not deallocate.}.
    20012000\begin{cfa}
    … …  
    20042003void ^?{}( VLA & vla ) with ( vla ) { free( data ); } $\C{// destructor}$
    20052004{
    2006         VLA x;                                                                  $\C{// implicit:\ \ x\{\};}$
    2007 }                                                                                       $\C{// implicit:\ \textasciicircum{}x\{\};}$
     2005        VLA x;                                                                  $\C{// implicit:  ?\{\}( x );}$
     2006}                                                                                       $\C{// implicit:  ?\^{}\{\}( x );}$
    20082007\end{cfa}
    20092008@VLA@ is a \newterm{managed type}\footnote{
    … …  
    20302029appropriate care is taken to not recursively call the copy constructor when initializing the second parameter.
    20312030
    2032 \CFA constructors may be explicitly called, like Java, and destructors may be explicitly called, like \CC.
     2031\CFA constructors may be explicitly call, like Java, and destructors may be explicitly called, like \CC.
    20332032Explicit 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.
    2034 Like the other operators in \CFA, there is a concise syntax for constructor/destructor function calls:
     2033While existing call syntax works for explicit calls to constructors and destructors, \CFA also provides a more concise \newterm{operator syntax} for both:
    20352034\begin{cfa}
    20362035{
    20372036        VLA  x,            y = { 20, 0x01 },     z = y; $\C{// z points to y}$
    2038         //    x{};         y{ 20, 0x01 };          z{ z, y };
     2037        //      ?{}( x );   ?{}( y, 20, 0x01 );   ?{}( z, y );
    20392038        ^x{};                                                                   $\C{// deallocate x}$
    20402039        x{};                                                                    $\C{// reallocate x}$
    … …  
    20432042        y{ x };                                                                 $\C{// reallocate y, points to x}$
    20442043        x{};                                                                    $\C{// reallocate x, not pointing to y}$
    2045         //  ^z{};  ^y{};  ^x{};
     2044        // ^?{}(z);  ^?{}(y);  ^?{}(x);
    20462045}
    20472046\end{cfa}
    … …  
    20642063In these cases, \CFA provides the initialization syntax \lstinline|S x `@=` {}|, and the object becomes unmanaged, so implicit constructor and destructor calls are not generated.
    20652064Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics.
    2066 The same syntax can be used in a compound literal, \eg \lstinline|a = (VLA)`@`{ 0, 0x0 }|, to create a C-style literal.
     2065The same syntax can be used in a compound literal, \eg \lstinline|a = VLA`@`{ 0, 0x0 }|, to create a C-style literal.
    20672066The 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.
    20682067
    … …  
    21202119
    21212120In C, @0@ has the special property that it is the only ``false'' value;
    2122 by the standard, any value that compares equal to @0@ is false, while any value that compares unequal to @0@ is true.
     2121from the standard, any value that compares equal to @0@ is false, while any value that compares unequal to @0@ is true.
    21232122As 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.
    21242123Operator 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.
    … …  
    21552154\lstDeleteShortInline@%
    21562155\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
    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}}       \\
     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}}  \\
    21582157\begin{cfa}
    21592158int |?`h|( int s );
    … …  
    22002199\lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}}
    22012200\lstDeleteShortInline@%
    2202 \begin{tabular}{@{}l@{\hspace{1.25\parindentlnth}}l@{}}
    2203 \multicolumn{1}{@{}c@{\hspace{1.25\parindentlnth}}}{\textbf{\CFA}}      & \multicolumn{1}{c@{}}{\textbf{\CC}}   \\
     2201\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
     2202\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{\CC}}      \\
    22042203\begin{cfa}
    22052204struct W {
    … …  
    22752274\lstDeleteShortInline@%
    22762275\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2277 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}   & \multicolumn{1}{c@{}}{\textbf{Usage}} \\
     2276\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
    22782277\begin{cfa}
    22792278const short int `MIN` = -32768;
    … …  
    22942293\lstDeleteShortInline@%
    22952294\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
    2296 \multicolumn{1}{@{}c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     2295\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
    22972296\begin{cfa}
    22982297MIN
    … …  
    23202319\lstDeleteShortInline@%
    23212320\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2322 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}   & \multicolumn{1}{c@{}}{\textbf{Usage}} \\
     2321\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
    23232322\begin{cfa}
    23242323float `log`( float x );
    … …  
    23392338\lstDeleteShortInline@%
    23402339\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2341 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     2340\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    23422341\begin{cfa}
    23432342log
    … …  
    23672366\lstDeleteShortInline@%
    23682367\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2369 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}   & \multicolumn{1}{c@{}}{\textbf{Usage}} \\
     2368\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
    23702369\begin{cfa}
    23712370unsigned int `abs`( int );
    … …  
    23862385\lstDeleteShortInline@%
    23872386\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2388 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     2387\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
    23892388\begin{cfa}
    23902389abs
    … …  
    24092408an allocation with a specified character.
    24102409\item[resize]
    2411 an existing allocation to decrease or increase its size.
     2410an existing allocation to decreased or increased its size.
    24122411In 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.
    24132412For an increase in storage size, new storage after the copied data may be filled.
    … …  
    24482447\begin{figure}
    24492448\centering
    2450 \begin{cfa}[aboveskip=0pt,xleftmargin=0pt]
     2449\begin{cquote}
     2450\begin{cfa}[aboveskip=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{\parindentlnth}}l@{}}
    2457 \multicolumn{1}{@{}c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{c@{}}{\textbf{C}}     \\
    2458 \begin{cfa}[xleftmargin=-10pt]
     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}
    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) ); memset( ip, fill, 4 * dim * sizeof(int));
    2479 
    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@%
     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 ) );
     2479                        memset( ip, fill, 4 * dim * sizeof( int ) );
     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@%
     2487\end{cquote}
    24872488\caption{\CFA versus C Storage-Allocation}
    24882489\label{f:StorageAllocation}
    … …  
    24972498S * as = anew( dim, 2, 3 );                                     $\C{// each array element initialized to 2, 3}$
    24982499\end{cfa}
    2499 Note, \CC can only initialize array elements via the default constructor.
     2500Note, \CC can only initialization array elements via the default constructor.
    25002501
    25012502Finally, the \CFA memory-allocator has \newterm{sticky properties} for dynamic storage: fill and alignment are remembered with an object's storage in the heap.
    … …  
    25142515\lstDeleteShortInline@%
    25152516\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
    2516 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{\CC}}   \\
     2517\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{\CC}}      \\
    25172518\begin{cfa}
    25182519int x = 1, y = 2, z = 3;
    … …  
    26032604\centering
    26042605\lstDeleteShortInline@%
    2605 \begin{tabular}{@{}l@{\hspace{3\parindentlnth}}l@{}}
    2606 \multicolumn{1}{@{}c@{\hspace{3\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}}     \\
     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}}     \\
    26072608\begin{cfa}
    26082609#include <gmp>
    … …  
    26372638
    26382639
    2639 \section{Polymorphism Evaluation}
     2640\section{Polymorphic Evaluation}
    26402641\label{sec:eval}
    26412642
    … …  
    27262727Line-count is a fairly rough measure of code complexity;
    27272728another important factor is how much type information the programmer must specify manually, especially where that information is not compiler-checked.
    2728 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 un-type-checked downcasts, \eg @object@ to @integer@ when popping a stack.
     2729Such 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.
    27292730To 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.
    27302731The \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.
    27312732The \CFA benchmark is able to eliminate all redundant type annotations through use of the polymorphic @alloc@ function discussed in Section~\ref{sec:libraries}.
    27322733
    2733 We conjecture these results scale across most generic data-types as the underlying polymorphism implement is constant.
     2734We conjecture these results scale across most generic data-types as the underlying polymorphic implement is constant.
    27342735
    27352736

  • doc/papers/general/response

    r78af962 rde94a60  
    6161judithbishop@outlook.com
    6262
    63 
    64 We have attempted to response to all the issues raised by the Editor and referee's comments. For two
    65 of the issues, we have "pushed back", with an explanation. Specifically, moving the related work
    66 forward, and moving text from Section 9 into the captions of Table2 and Figure 10.  Our reasons for
    67 not making these changes are address below. Finally, as pointed out below, there are a couple of
    68 issues 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 
    74 The paper is 35 pages using the supplied Wiley LaTeX macros.
    75 
    76 
    7763Referee(s)' Comments to Author:
    7864
    7965Reviewing: 1
    8066
    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 
    86 Sometimes it is appropriate to put related work at the start of a paper and sometimes at the
    87 end. For this paper, it seems appropriate to put the related work at the end of the paper. The
    88 purpose of the related work in this paper is two fold: to introduce prior work and to contrast it
    89 with Cforall.  Only at the end of the paper does the reader have sufficient knowledge about Cforall
    90 to make detailed contrasts with other programming languages possible. If the related work is moved
    91 to the end of the introduction, the reader knows nothing about Cforall so talking about other
    92 programming languages in isolation makes little sense, especially non-C-related languages, like
    93 Java, Go, Rust, Haskell. We see no easy way to separate the related work into a general discussion
    94 at the start and a specific discussion at the end. We explicitly attempt to deal with the reader's
    95 anticipation 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 
    107 This suggestion is an alternative writing style. The experiment is complex enough that it is
    108 unlikely a reader could jump to the table/graph and understand the experiment without putting a
    109 substantive amount of the text from Section 9 into the table and figure, which the reader then has
    110 to read anyway.  In fact, we prefer a writing style where the reader does not have to look at the
    111 table/figure to understand the experiment and the results, i.e., the table/figure are only there to
    112 complement 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.
     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
     73Sometimes it is appropriate to put related work at the start of a paper and
     74sometimes at the end. For this paper, it seems appropriate to put the related
     75work at the end of the paper. The purpose of the related work in this paper is
     76two fold: to introduce prior work and to contrast it with Cforall.  Only at the
     77end of the paper does the reader have sufficient knowledge about Cforall to
     78make detailed contrasts with other programming languages possible. If the
     79related work is moved to the end of the introduction, the reader knows nothing
     80about Cforall so talking about other programming languages in isolation makes
     81little sense, especially non-C-related languages, like Java, Go, Rust,
     82Haskell. We see no easy way to separate the related work into a general
     83discussion at the start and a specific discussion at the end. We explicitly
     84attempt 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
     99This suggestion is an alternative writing style. The experiment is complex
     100enough that it is unlikely a reader could jump to the table/graph and
     101understand the experiment without putting a substantive amount of the text from
     102Section 9 into the table and figure, which the reader then has to read anyway.
     103In fact, we prefer a writing style where the reader does not have to look at
     104the table/figure to understand the experiment and the results, i.e., the
     105table/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.
    117110
    118111Done.
    119112
    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 
    125 Fixed. 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 
    133 Table 2 indicates the source-code size in lines of code. The third paragraph of Section 9 gives
    134 precise details of the software/hardware used in the experiments.
     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
     117Fixed. All errors in the paper are compilation errors because they are related
     118to 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
     125Table 2 indicates the source-code size in lines of code. The third paragraph of
     126Section 9 gives precise details of the software/hardware used in the
     127experiments.
    135128
    136129   3. Practical information about the work
    137130
    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."),
     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."),
    140134
    141135This sentence is replace with:
    142136
    143  All languages features discussed in this paper are working, except some advanced exception-handling
    144  features.
     137 All languages features discussed in this paper are working, except some
     138 advanced exception-handling features.
    145139
    146140and Section 5.4 Exception Handling states:
    147141
    148  The following framework for Cforall exception handling is in place, excluding some runtime
    149  type-information and virtual functions.
    150 
     142 The following framework for Cforall exception handling is in place, excluding
     143 some runtime type-information and virtual functions.
    151144
    152145   page 4 ("Under construction is a mechanism to distribute...")
    … …  
    154147The feature on page 4 is now complete.
    155148
    156 
    157149   and page 33 ("There is ongoing work on a wide range ... ")
    158150
    159151This sentence is replace to indicate the ongoing work is future work.
    160152
    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 
    169 There is nothing to move into an appendix, except 3 sentences. We do not intend to discuss these
    170 items 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.
     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
     162There is nothing to move into an appendix, except 3 sentences. We do not intend
     163to 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.
    175167
    176168See above.
    177169
    178 
    179    3.2 Instructions on how to access/use the working functionality of Cforall should be given.
    180 
    181 We will indicate release of Cforall in a public location, when we believe the code base is
    182 acceptable. In the interim, we have made public all the experimental code from section 9, and there
    183 is a reference in the paper to access this code. We can make a private beta-copy of Cforall
    184 available 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 
    188 Software development is not a rigorous engineering discipline. Given our small research
    189 development-team and the size of the project, we cannot give a specific time for completion of
    190 anything associated with the project. Having said that, we have reduced our expected time for
    191 Cforall 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.
     170   3.2 Instructions on how to access/use the working functionality of Cforall
     171   should be given.
     172
     173We will indicate release of Cforall in a public location, when we believe the
     174code base is acceptable. In the interim, we have made public all the
     175experimental code from section 9, and there is a reference in the paper to
     176access this code. We can make a private beta-copy of Cforall available to the
     177SP&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
     182Software development is not rigorous engineering discipline. Given our small
     183research development-team and the size of the project, we cannot give a
     184specific time for completion of anything associated with the project. Having
     185said that, we have reduced our expected time for Cforall release to 6-8 months
     186as 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.
    198195
    199196See point 1.
    200197
    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.
     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.
    204200
    205201The Phil-Karlton quote is an urban legend without a specific academic citation:
    … …  
    209205The term "const hell" is replaced with "const poisoning" with a citation.
    210206
    211 
    212    5.1 Footnotes and citations will need to have different schemes - number and perhaps letter.
    213 
    214 Switched 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 
    223 Agreed. The bibtex BST macros are at fault. I have fixed some issues but I cannot fix them all as my
    224 BST macro-knowledge is limited.
    225 
     207   5.1 Footnotes and citations will need to have different schemes - number and
     208   perhaps letter.
     209
     210The latex macros from Wiley generate those symbols. I assume during
     211copy-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
     217Agreed. The bibtex BST macros are at fault. I have fixed some issues but I
     218cannot fix them all as my BST macro-knowledge is limited.
    226219
    227220   5.3 Typos:
    … …  
    240233
    241234   6. Conflict of interest
    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 
    246 The paper now states the project is open-source, hence there is no conflict of interest with the
    247 funding received from Huawei.
     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
     239The paper now states the project is open-source, hence there is no conflict of
     240interest with the funding received from Huawei.
    248241
    249242
    … …  
    252245Comments to the Author
    253246
    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 
    257 There is no complexity with building Cforall/C programs, and there is an existence proof because C++
    258 has 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 
    264 We have clarified that the evaluation is not for the type system, but rather the underlying
    265 implementation 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 
    271 and 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 
    280 The 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.
     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
     251There is no complexity with building Cforall/C programs, and there is an
     252existence proof because C++ has name mangling for overloading and has no problem
     253interacting 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
     265The following paragraph has been added to the introduction to address this
     266comment:
     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.
    304294
    305295The following paragraph has been added at the start of Section 10.1:
    306296
    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.
     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.
    321314
    322315At the end of Section 10.2, we state:
    323316
    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.
     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.
    326320
    327321

  • src/Parser/parser.yy

    r78af962 rde94a60  
    1010// Created On       : Sat Sep  1 20:22:55 2001
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Wed May  9 17:17:35 2018
    13 // Update Count     : 3244
     12// Last Modified On : Thu May  3 08:20:09 2018
     13// Update Count     : 3225
    1414//
    1515
    … …  
    302302
    303303%type<decl> field_declaration field_declaration_list field_declarator field_declaring_list
    304 %type<en> field field_list field_name fraction_constants_opt
     304%type<en> field field_list field_name fraction_constants
    305305
    306306%type<decl> external_function_definition function_definition function_array function_declarator function_no_ptr function_ptr
    … …  
    499499        | type_name '.' no_attr_identifier                                      // CFA, nested type
    500500                { SemanticError( yylloc, "Qualified names are currently unimplemented." ); $$ = nullptr; }
    501 //              { $$ = nullptr; }
    502501        | type_name '.' '[' push field_list pop ']'                     // CFA, nested type / tuple field selector
    503502                { SemanticError( yylloc, "Qualified names are currently unimplemented." ); $$ = nullptr; }
    504 //              { $$ = nullptr; }
    505503        | GENERIC '(' assignment_expression ',' generic_assoc_list ')' // C11
    506504                { SemanticError( yylloc, "_Generic is currently unimplemented." ); $$ = nullptr; }
    … …  
    535533        | postfix_expression '.' no_attr_identifier
    536534                { $$ = new ExpressionNode( build_fieldSel( $1, build_varref( $3 ) ) ); }
    537         | postfix_expression '.' INTEGERconstant                        // CFA, tuple index
    538                 { $$ = new ExpressionNode( build_fieldSel( $1, build_constantInteger( *$3 ) ) ); }
     535        | postfix_expression '.' '[' push field_list pop ']' // CFA, tuple field selector
     536                { $$ = new ExpressionNode( build_fieldSel( $1, build_tuple( $5 ) ) ); }
    539537        | postfix_expression FLOATING_FRACTIONconstant          // CFA, tuple index
    540538                { $$ = new ExpressionNode( build_fieldSel( $1, build_field_name_FLOATING_FRACTIONconstant( *$2 ) ) ); }
    541         | postfix_expression '.' '[' push field_list pop ']' // CFA, tuple field selector
    542                 { $$ = new ExpressionNode( build_fieldSel( $1, build_tuple( $5 ) ) ); }
    543539        | postfix_expression ARROW no_attr_identifier
    544540                {
    545541                        $$ = new ExpressionNode( build_pfieldSel( $1, *$3 == "0" || *$3 == "1" ? build_constantInteger( *$3 ) : build_varref( $3 ) ) );
    546542                }
     543        | postfix_expression ARROW '[' push field_list pop ']' // CFA, tuple field selector
     544                        { $$ = new ExpressionNode( build_pfieldSel( $1, build_tuple( $5 ) ) ); }
    547545        | postfix_expression ARROW INTEGERconstant                      // CFA, tuple index
    548546                { $$ = new ExpressionNode( build_pfieldSel( $1, build_constantInteger( *$3 ) ) ); }
    549         | postfix_expression ARROW '[' push field_list pop ']' // CFA, tuple field selector
    550                 { $$ = new ExpressionNode( build_pfieldSel( $1, build_tuple( $5 ) ) ); }
    551547        | postfix_expression ICR
    552548                { $$ = new ExpressionNode( build_unary_ptr( OperKinds::IncrPost, $1 ) ); }
    … …  
    601597
    602598field_name:
    603         INTEGERconstant fraction_constants_opt
     599        INTEGERconstant fraction_constants
    604600                { $$ = new ExpressionNode( build_field_name_fraction_constants( build_constantInteger( *$1 ), $2 ) ); }
    605         | FLOATINGconstant fraction_constants_opt
     601        | FLOATINGconstant fraction_constants
    606602                { $$ = new ExpressionNode( build_field_name_fraction_constants( build_field_name_FLOATINGconstant( *$1 ), $2 ) ); }
    607         | no_attr_identifier fraction_constants_opt
     603        | no_attr_identifier fraction_constants
    608604                {
    609605                        $$ = new ExpressionNode( build_field_name_fraction_constants( build_varref( $1 ), $2 ) );
    … …  
    611607        ;
    612608
    613 fraction_constants_opt:
     609fraction_constants:
    614610        // empty
    615611                { $$ = nullptr; }
    616         | fraction_constants_opt FLOATING_FRACTIONconstant
     612        | fraction_constants FLOATING_FRACTIONconstant
    617613                {
    618614                        Expression * constant = build_field_name_FLOATING_FRACTIONconstant( *$2 );
    … …  
    23942390external_definition_list:
    23952391        external_definition
    2396         | external_definition_list
    2397                 { forall = xxx; }
    2398           push external_definition
     2392        | external_definition_list { forall = xxx; } push external_definition
    23992393                { $$ = $1 ? $1->appendList( $4 ) : $4; }
    24002394        ;
Note: See TracChangeset for help on using the changeset viewer.