Index: doc/papers/general/response =================================================================== --- doc/papers/general/response (revision cfc3e0facc59b4b72c5c4ade00f35a2478f94cf2) +++ doc/papers/general/response (revision cfc3e0facc59b4b72c5c4ade00f35a2478f94cf2) @@ -0,0 +1,373 @@ +Date: Thu, 19 Apr 2018 17:01:14 -0400 (EDT) +From: "Software: Practice and Experience" +Reply-To: judithbishop@outlook.com +To: a3moss@uwaterloo.ca, rschlunt@uwaterloo.ca, pabuhr@uwaterloo.ca +Subject: Software: Practice and Experience - Decision on Manuscript ID SPE-18-0065 + +19-Apr-2018 + +Dear Dr Buhr, + +Many thanks for submitting SPE-18-0065 entitled "Cforall : Adding Modern Programming +Language Features to C" to Software: Practice and Experience. The paper has now +been reviewed and the comments of the referee(s) are included at the bottom of +this letter. + +I am delighted to inform you that the referee(s) have recommended publication, +but also suggest some minor revisions to your manuscript. Therefore, I invite +you to respond to the referee(s)' comments and revise your manuscript. All of +the referees' comments are important, but I would like you to pay special +attention to the following general points: + +1. If there is any more evaluation that a stack, please add it. +2. How is the compiler implemented? +3. What features are actually implemented? +4. The article lacks some related work. such as Haskell, ML etc. +5. 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. +6. Many references are not properly formatted +7. A statement about any presence or absence of conflicts of interest with Huawei should be explicitly added. + +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. + +You have 42 days from the date of this email to submit your revision. If you +are unable to complete the revision within this time, please contact me to +request a short extension. + +You can upload your revised manuscript and submit it through your Author +Center. Log into https://mc.manuscriptcentral.com/spe and enter your Author +Center, where you will find your manuscript title listed under "Manuscripts +with Decisions". + +When submitting your revised manuscript, you will be able to respond to the +comments made by the referee(s) in the space provided. You can use this space +to document any changes you make to the original manuscript. + +If you feel that your paper could benefit from English language polishing, you +may wish to consider having your paper professionally edited for English +language by a service such as Wiley's at +http://wileyeditingservices.com. Please note that while this service will +greatly improve the readability of your paper, it does not guarantee acceptance +of your paper by the journal. + +Once again, thank you for submitting your manuscript to Software: Practice and Experience. I look forward to receiving your revision. + +Sincerely, + +Dr Judith Bishop +Editor, Software: Practice and Experience +judithbishop@outlook.com + +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. + +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. + + 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."), + +This sentence is replace with: + + 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. + + page 4 ("Under construction is a mechanism to distribute...") + +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. + +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. + +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. + +The Phil-Karlton quote is an urban legend without a specific academic citation: + + https://skeptics.stackexchange.com/questions/19836/has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science + +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.3 Typos: + - Page 3 "eager" should be "earlier" + +Fixed. + + - Page 4 "vals" should be "arr" + +Actually it is "vals", and the example is changed so it is clear why. + + - Page 21 "than" should be "then" + +Fixed. + + + 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. + + +Reviewing: 2 + +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. + +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. + +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. + + +From: Judith Bishop +To: "Peter A. Buhr" +Subject: RE: Software: Practice and Experience - Decision on Manuscript ID + SPE-18-0065 +Date: Tue, 24 Apr 2018 16:45:51 +0000 +Accept-Language: em-US + +Hi Peter + +Great to hear from you. I am also glad your paper got through, as it is in the +mainline of the SPE scope. + +It is important to mention that the software is open source. People really +value that. In the acknowledgements, you can refer to Huawei for funding. It is +quite normal to have industrial funding, and in fact it is a plus. + +I think that sorts out the comment from the referee. + +Looking forward to your revised submission. + +Kind regards + +Judith Bishop +Extraordinary Professor, Computer Science +Stellenbosch University, South Africa +082 301 5220 / 021 671 5133 +judithbishop@outlook.com LinkedIn + +-----Original Message----- +From: Peter A. Buhr +Sent: Tuesday, April 24, 2018 6:25 PM +To: judithbishop@outlook.com +Cc: a3moss@uwaterloo.ca; rschlunt@uwaterloo.ca +Subject: Re: Software: Practice and Experience - Decision on Manuscript ID SPE-18-0065 + +Hi Judy! Hope all is well. + +We are over-the-moon to get our paper accepted at SP&E, and we are actively +working on your and the referee's comments. + +One comment where we need assistance is: + + 7. A statement about any presence or absence of conflicts of interest with + Huawei should be explicitly added. + +We forgotten to mention in the paper that our project is open-source. So Huawei +was funding an open-source project. In fact, the Huawei funding ends soon, so +there will be no direct affiliation in a couple of months, although there are a +few people at Huawei who remain very interested in the project. + +So does stating that the Cforall project is an open-source project deal with +the issue of conflict of interest?