Changes in doc/papers/general/response [3d60c08:cfc3e0f]

File:

• doc/papers/general/response (modified) (5 diffs)

doc/papers/general/response

@@ -61 +61 @@
 judithbishop@outlook.com
 
-
-We have attempted to response to all the issues raised by the Editor and referee's comments. For two
-of the issues, we have "pushed back", with an explanation. Specifically, moving the related work
-forward, and moving text from Section 9 into the captions of Table2 and Figure 10.  Our reasons for
-not making these changes are address below. Finally, as pointed out below, there are a couple of
-issues with the Wiley LaTeX macros that we worked around as best as possible.
-
-   The paper is long by SPE standards (33 pages). We have a maximum of 40 pages. Please do not
-   extend the paper beyond 35 pages. If necessary, find ways to cut the examples or text. If you
-   have an accompanying website for the system where some examples are stored, please mention it.
-
-The paper is 35 pages using the supplied Wiley LaTeX macros.
-
-
 Referee(s)' Comments to Author:
 
 Reviewing: 1
 
-   Most of the content in Section 10 RELATED WORK appears to belong to Section 1 INTRODUCTION as a
-   Subsection or as a new Section after Section 1. (Please also see #4.1 below.) Remaining
-   discussion that cannot be moved earlier can become a DISCUSSION Section or a Subsection within
-   the last Section of the paper.
-
-Sometimes it is appropriate to put related work at the start of a paper and sometimes at the
-end. For this paper, it seems appropriate to put the related work at the end of the paper. The
-purpose of the related work in this paper is two fold: to introduce prior work and to contrast it
-with Cforall.  Only at the end of the paper does the reader have sufficient knowledge about Cforall
-to make detailed contrasts with other programming languages possible. If the related work is moved
-to the end of the introduction, the reader knows nothing about Cforall so talking about other
-programming languages in isolation makes little sense, especially non-C-related languages, like
-Java, Go, Rust, Haskell. We see no easy way to separate the related work into a general discussion
-at the start and a specific discussion at the end. We explicitly attempt to deal with the reader's
-anticipation at the end of the introduction:
-
- Finally, it is impossible to describe a programming language without usages before definitions.
- Therefore, syntax and semantics appear before explanations; hence, patience is necessary until
- details are presented.
-
-
-   2.1 More information should be moved from the text and added to Figure 10 and Table 2 so that
-   readers can understand the comparison quickly. Imagine a reader read the summary and jump
-   directly to these two display elements. Questions would be raised about the binary size and pop
-   pair result of Cforall and it would take time to find answers in the text.
-
-This suggestion is an alternative writing style. The experiment is complex enough that it is
-unlikely a reader could jump to the table/graph and understand the experiment without putting a
-substantive amount of the text from Section 9 into the table and figure, which the reader then has
-to read anyway.  In fact, we prefer a writing style where the reader does not have to look at the
-table/figure to understand the experiment and the results, i.e., the table/figure are only there to
-complement the discussion.
-
-
-   2.2 The pronunciation of ("C-for-all") should be provided in the summary (page 1 line 22) so that
-   people not having an access to the full-text can see it.
+   Most of the content in Section 10 RELATED WORK appears to belong to Section
+   1 INTRODUCTION as a Subsection or as a new Section after Section 1. (Please
+   also see #4.1 below.) Remaining discussion that cannot be moved earlier can
+   become a DISCUSSION Section or a Subsection within the last Section of the
+   paper.
+
+Sometimes it is appropriate to put related work at the start of a paper and
+sometimes at the end. For this paper, it seems appropriate to put the related
+work at the end of the paper. The purpose of the related work in this paper is
+two fold: to introduce prior work and to contrast it with Cforall.  Only at the
+end of the paper does the reader have sufficient knowledge about Cforall to
+make detailed contrasts with other programming languages possible. If the
+related work is moved to the end of the introduction, the reader knows nothing
+about Cforall so talking about other programming languages in isolation makes
+little sense, especially non-C-related languages, like Java, Go, Rust,
+Haskell. We see no easy way to separate the related work into a general
+discussion at the start and a specific discussion at the end. We explicitly
+attempt to deal with the reader's anticipation at the end of the introduction:
+
+ Finally, it is impossible to describe a programming language without usages
+ before definitions.  Therefore, syntax and semantics appear before
+ explanations; hence, patience is necessary until details are presented.
+
+
+   2. Presentation
+
+   2.1 More information should be moved from the text and added to Figure 10 and
+   Table 2 so that readers can understand the comparison quickly. Imagine a reader
+   read the summary and jump directly to these two display elements. Questions
+   would be raised about the binary size and pop pair result of Cforall and it
+   would take time to find answers in the text.
+
+This suggestion is an alternative writing style. The experiment is complex
+enough that it is unlikely a reader could jump to the table/graph and
+understand the experiment without putting a substantive amount of the text from
+Section 9 into the table and figure, which the reader then has to read anyway.
+In fact, we prefer a writing style where the reader does not have to look at
+the table/figure to understand the experiment and the results, i.e., the
+table/figure are only there to complement the discussion.
+
+   2.2 The pronunciation of ("C-for-all") should be provided in the summary
+   (page 1 line 22) so that people not having an access to the full-text can
+   see it.
 
 Done.
 
-
-   2.3 Error comment in the code should be written with the same capitalization and it will be
-   helpful if you say specifically compilation error or runtime error. (Please see attached
-   annotated manuscript.)
-
-Fixed. All errors in the paper are compilation errors because they are related to the type system.
-
-
-   2.4 It is possible to provide a bit more information in Appendix A e.g. how many lines/bytes of
-   code and some details about software/hardware can be added/moved here. The aim is to provide
-   sufficient information for readers to reproduce the results and to appreciate the context of the
-   comparison.
-
-Table 2 indicates the source-code size in lines of code. The third paragraph of Section 9 gives
-precise details of the software/hardware used in the experiments.
+   2.3 Error comment in the code should be written with the same capitalization
+   and it will be helpful if you say specifically compilation error or runtime
+   error. (Please see attached annotated manuscript.)
+
+Fixed. All errors in the paper are compilation errors because they are related
+to the type system.
+
+   2.4 It is possible to provide a bit more information in Appendix A e.g. how
+   many lines/bytes of code and some details about software/hardware can be
+   added/moved here. The aim is to provide sufficient information for readers
+   to reproduce the results and to appreciate the context of the comparison.
+
+Table 2 indicates the source-code size in lines of code. The third paragraph of
+Section 9 gives precise details of the software/hardware used in the
+experiments.
 
    3. Practical information about the work
 
-   There are three separate pieces of information on pages 2 ("All features discussed in this paper
-   are working, unless otherwise stated as under construction."),
+   There are three separate pieces of information on pages 2 ("All features
+   discussed in this paper are working, unless otherwise stated as under
+   construction."),
 
 This sentence is replace with:
 
- All languages features discussed in this paper are working, except some advanced exception-handling
- features.
+ All languages features discussed in this paper are working, except some
+ advanced exception-handling features.
 
 and Section 5.4 Exception Handling states:
 
- The following framework for Cforall exception handling is in place, excluding some runtime
- type-information and virtual functions.
-
+ The following framework for Cforall exception handling is in place, excluding
+ some runtime type-information and virtual functions.
 
    page 4 ("Under construction is a mechanism to distribute...")
@@ -154 +147 @@
 The feature on page 4 is now complete.
 
-
    and page 33 ("There is ongoing work on a wide range ... ")
 
 This sentence is replace to indicate the ongoing work is future work.
 
- While all examples in the paper compile and run, a public beta-release of Cforall will take 6-8
- months to reduce compilation time, provide better debugging, and add a few more libraries.  There
- is also new work on a number of Cforall features, including arrays with size, runtime
- type-information, virtual functions, user-defined conversions, and modules.
-
-
-   My recommendation is to move them to an appendix so that the length is preserved.
-
-There is nothing to move into an appendix, except 3 sentences. We do not intend to discuss these
-items in this paper.
-
-
-   3.1 Any under construction work (only small part of page 4) should not be mingled into the main
-   part of the manuscript.
+ While all examples in the paper compile and run, a public beta-release of
+ Cforall will take 6-8 months to reduce compilation time, provide better
+ debugging, and add a few more libraries.  There is also new work on a number
+ of Cforall features, including arrays with size, runtime type-information,
+ virtual functions, user-defined conversions, and modules.
+
+   My recommendation is to move them to an appendix so that the length is
+   preserved.
+
+There is nothing to move into an appendix, except 3 sentences. We do not intend
+to discuss these items in this paper.
+
+   3.1 Any under construction work (only small part of page 4) should not be
+   mingled into the main part of the manuscript.
 
 See above.
 
-
-   3.2 Instructions on how to access/use the working functionality of Cforall should be given.
-
-We will indicate release of Cforall in a public location, when we believe the code base is
-acceptable. In the interim, we have made public all the experimental code from section 9, and there
-is a reference in the paper to access this code. We can make a private beta-copy of Cforall
-available to the SP&E editor for distribution to the referees so they can verify our claims.
-
-   3.3 Planned work should be given a specific time of completion/release not just "8-12 months".
-
-Software development is not a rigorous engineering discipline. Given our small research
-development-team and the size of the project, we cannot give a specific time for completion of
-anything associated with the project. Having said that, we have reduced our expected time for
-Cforall release to 6-8 months as work is progressing well.
-
-
-   4.1 The impression after reading Section 1 INTRODUCTION is that the referencing is poor. It is
-   not until Section 10 RELATED WORK where majority of the prior literature are discussed. Please
-   consider moving the content and improve citations - at least cite all main variations of C
-   languages.
+   3.2 Instructions on how to access/use the working functionality of Cforall
+   should be given.
+
+We will indicate release of Cforall in a public location, when we believe the
+code base is acceptable. In the interim, we have made public all the
+experimental code from section 9, and there is a reference in the paper to
+access this code. We can make a private beta-copy of Cforall available to the
+SP&E editor for distribution to the referees so they can verify our claims.
+
+   3.3 Planned work should be given a specific time of completion/release not
+   just "8-12 months".
+
+Software development is not rigorous engineering discipline. Given our small
+research development-team and the size of the project, we cannot give a
+specific time for completion of anything associated with the project. Having
+said that, we have reduced our expected time for Cforall release to 6-8 months
+as work is progressing well.
+
+
+   4. Citations
+
+   4.1 The impression after reading Section 1 INTRODUCTION is that the
+   referencing is poor. It is not until Section 10 RELATED WORK where majority
+   of the prior literature are discussed. Please consider moving the content
+   and improve citations - at least cite all main variations of C languages.
 
 See point 1.
 
-
-   4.2 I also would like to see citations at these specific places: Page 2 after Phil Karlton, page
-   22 after const hell problem.
+   4.2 I also would like to see citations at these specific places: Page 2
+   after Phil Karlton, page 22 after const hell problem.
 
 The Phil-Karlton quote is an urban legend without a specific academic citation:
@@ -209 +205 @@
 The term "const hell" is replaced with "const poisoning" with a citation.
 
-
-   5.1 Footnotes and citations will need to have different schemes - number and perhaps letter.
-
-Switched to letters. SP&E uses symbol footnotes but this macros fails with their macros:
-
- \renewcommand*{\thefootnote}{\fnsymbol{footnote}}
-
-
-   5.2 Many references are not properly formatted e.g. date is incomplete, extra/missing white
-   spaces, extra dots, use of page number or section number as part of superscript ref
-   number. Please refer to attached document.
-
-Agreed. The bibtex BST macros are at fault. I have fixed some issues but I cannot fix them all as my
-BST macro-knowledge is limited.
-
+   5.1 Footnotes and citations will need to have different schemes - number and
+   perhaps letter.
+
+The latex macros from Wiley generate those symbols. I assume during
+copy-editing the format is changed to suit the journal format.
+
+   5.2 Many references are not properly formatted e.g. date is incomplete,
+   extra/missing white spaces, extra dots, use of page number or section number
+   as part of superscript ref number. Please refer to attached document.
+
+Agreed. The bibtex BST macros are at fault. I have fixed some issues but I
+cannot fix them all as my BST macro-knowledge is limited.
 
    5.3 Typos:
@@ -240 +233 @@
 
    6. Conflict of interest
-   I see that the work is partially supported by Huawei. Perhaps statement about any presence or
-   absence of conflicts of interest should be explicitly added. Please get a clear direction on this
-   from the editor of the journal.
-
-The paper now states the project is open-source, hence there is no conflict of interest with the
-funding received from Huawei.
+   I see that the work is partially supported by Huawei. Perhaps statement
+   about any presence or absence of conflicts of interest should be explicitly
+   added. Please get a clear direction on this from the editor of the journal.
+
+The paper now states the project is open-source, hence there is no conflict of
+interest with the funding received from Huawei.
 
 
@@ -252 +245 @@
 Comments to the Author
 
-   Overloading requires the compiler to mangle a function's signature into its name in the object
-   file.  I'm pretty sure that this will complicate the build process of mixed Cforall/C projects.
-
-There is no complexity with building Cforall/C programs, and there is an existence proof because C++
-has name mangling for overloading and has no problem interacting with C.
-
-
-   I found the evaluation underwhelming.  There were only ~200 LoC ported from C to Cforall.  This
-   is too less to encounter potential caveats Cforall's type system might impose.
-
-We have clarified that the evaluation is not for the type system, but rather the underlying
-implementation approach for the parametric polymorphism. Section 9 now starts:
-
- Cforall adds parametric polymorphism to C.  A runtime evaluation is performed to compare the cost
- of alternative styles of polymorphism.  The goal is to compare just the underlying mechanism for
- implementing different kinds of polymorphism.
-
-and ends with:
-
- We conjecture these results scale across most generic data-types as the underlying polymorphic
- implement is constant.
- 
-
-   Also, how is the compiler implemented?  I guess, Cforall is a source-to-source compiler (from
-   Cforall to C).  But this is left in the dark.  What features are actually implemented?
-
-The following paragraph has been added to the introduction to address this comment:
-
- All languages features discussed in this paper are working, except some advanced exception-handling
- features.  Not discussed in this paper are the integrated concurrency-constructs and user-level
- threading-library~\cite{Delisle18}.  Cforall is an open-source project implemented as an
- source-to-source translator from Cforall to the gcc-dialect of C~\cite{GCCExtensions}, allowing it
- to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
- Ultimately, a compiler is necessary for advanced features and optimal performance.  The Cforall
- translator is 200+ files and 46,000+ lines of code written in C/C++.  Starting with a translator
- versus a compiler makes it easier and faster to generate and debug C object-code rather than
- intermediate, assembler or machine code.  The translator design is based on the visitor pattern,
- allowing multiple passes over the abstract code-tree, which works well for incrementally adding new
- feature through additional visitor passes.  At the heart of the translator is the type resolver,
- which handles the polymorphic routine/type overload-resolution.  The Cforall runtime system is 100+
- files and 11,000+ lines of code, written in Cforall.  Currently, the Cforall runtime is the largest
- user of Cforall providing a vehicle to test the language features and implementation.  The Cforall
- tests are 290+ files and 27,000+ lines of code.  The tests illustrate syntactic and semantic
- features in Cforall, plus a growing number of runtime benchmarks.  The tests check for correctness
- and are used for daily regression testing of commits (3800+).
-
-
-   Furthermore, the article lacks some related work.  Many proposed features are present in
-   functional languages such as Haskell, ML etc.  In particular, the dealing of parametric
-   polymorphism reminds me of Haskell.
+   Overloading requires the compiler to mangle a function's signature into its
+   name in the object file.  I'm pretty sure that this will complicate the
+   build process of mixed Cforall/C projects.
+
+There is no complexity with building Cforall/C programs, and there is an
+existence proof because C++ has name mangling for overloading and has no problem
+interacting with C.
+
+   I found the evaluation underwhelming.  There were only ~200 LoC ported from
+   C to Cforall.  This is too less to encounter potential caveats Cforall's
+   type system might impose.
+
+
+
+   Also, how is the compiler implemented?  I guess, Cforall is a
+   source-to-source compiler (from Cforall to C).  But this is left in the
+   dark.  What features are actually implemented?
+
+The following paragraph has been added to the introduction to address this
+comment:
+
+ All languages features discussed in this paper are working, except some
+ advanced exception-handling features.  Not discussed in this paper are the
+ integrated concurrency-constructs and user-level
+ threading-library~\cite{Delisle18}.  Cforall is an open-source project
+ implemented as an source-to-source translator from Cforall to the gcc-dialect
+ of C~\cite{GCCExtensions}, allowing it to leverage the portability and code
+ optimizations provided by gcc, meeting goals (1)--(3).  Ultimately, a compiler
+ is necessary for advanced features and optimal performance.  The Cforall
+ translator is 200+ files and 46,000+ lines of code written in C/C++.  Starting
+ with a translator versus a compiler makes it easier and faster to generate and
+ debug C object-code rather than intermediate, assembler or machine code.  The
+ translator design is based on the visitor pattern, allowing multiple passes
+ over the abstract code-tree, which works well for incrementally adding new
+ feature through additional visitor passes.  At the heart of the translator is
+ the type resolver, which handles the polymorphic routine/type
+ overload-resolution.  The Cforall runtime system is 100+ files and 11,000+
+ lines of code, written in Cforall.  Currently, the Cforall runtime is the
+ largest user of Cforall providing a vehicle to test the language features and
+ implementation.  The Cforall tests are 290+ files and 27,000+ lines of code.
+ The tests illustrate syntactic and semantic features in Cforall, plus a
+ growing number of runtime benchmarks.  The tests check for correctness and are
+ used for daily regression testing of commits (3800+).
+
+   Furthermore, the article lacks some related work.  Many proposed features
+   are present in functional languages such as Haskell, ML etc.  In particular,
+   the dealing of parametric polymorphism reminds me of Haskell.
 
 The following paragraph has been added at the start of Section 10.1:
 
- ML~\cite{ML} was the first language to support parametric polymorphism.  Like Cforall, it supports
- universal type parameters, but not the use of assertions and traits to constrain type arguments.
- Haskell~\cite{Haskell10} combines ML-style polymorphism, polymorphic data types, and type inference
- with the notion of type classes, collections of overloadable methods that correspond in intent to
- traits in Cforall.  Unlike Cforall, Haskell requires an explicit association between types and
- their classes that specifies the implementation of operations.  These associations determine the
- functions that are assertion arguments for particular combinations of class and type, in contrast
- to Cforall where the assertion arguments are selected at function call sites based upon the set of
- operations in scope at that point.  Haskell also severely restricts the use of overloading: an
- overloaded name can only be associated with a single class, and methods with overloaded names can
- only be defined as part of instance declarations.
-
-
-   Cforall's approach to tuples is also quite similar to many functional languages.
+ ML~\cite{ML} was the first language to support parametric polymorphism.  Like
+ Cforall, it supports universal type parameters, but not the use of assertions
+ and traits to constrain type arguments.  Haskell~\cite{Haskell10} combines
+ ML-style polymorphism, polymorphic data types, and type inference with the
+ notion of type classes, collections of overloadable methods that correspond in
+ intent to traits in Cforall.  Unlike Cforall, Haskell requires an explicit
+ association between types and their classes that specifies the implementation
+ of operations.  These associations determine the functions that are assertion
+ arguments for particular combinations of class and type, in contrast to
+ Cforall where the assertion arguments are selected at function call sites
+ based upon the set of operations in scope at that point.  Haskell also
+ severely restricts the use of overloading: an overloaded name can only be
+ associated with a single class, and methods with overloaded names can only be
+ defined as part of instance declarations.
+
+   Cforall's approach to tuples is also quite similar to many functional
+   languages.
 
 At the end of Section 10.2, we state:
 
- Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML,
- Haskell}, and Scala, which decompose tuples using pattern matching.
+ Tuples are a fundamental abstraction in most functional programming languages,
+ such as Standard ML, Haskell}, and Scala, which decompose tuples using pattern
+ matching.