Index: doc/papers/general/response =================================================================== --- doc/papers/general/response (revision cfc3e0facc59b4b72c5c4ade00f35a2478f94cf2) +++ doc/papers/general/response (revision 3d60c08ac51fee59e5e460399d8f60bfa15e20c6) @@ -61,85 +61,92 @@ 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. 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. + 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. 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...") @@ -147,55 +154,52 @@ 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 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. + + 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. 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: @@ -205,16 +209,19 @@ 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. - -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.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.3 Typos: @@ -233,10 +240,10 @@ 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. @@ -245,77 +252,76 @@ 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. - - - - 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. + +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. 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.