source: doc/papers/general/response @ cfc3e0f

aaron-thesisarm-ehcleanup-dtorsdeferred_resndemanglerjacob/cs343-translationjenkins-sandboxnew-astnew-ast-unique-exprnew-envno_listpersistent-indexerwith_gc
Last change on this file since cfc3e0f was cfc3e0f, checked in by Peter A. Buhr <pabuhr@…>, 4 years ago

referee responses

  • Property mode set to 100644
File size: 16.3 KB
Line 
1Date: Thu, 19 Apr 2018 17:01:14 -0400 (EDT)
2From: "Software: Practice and Experience" <onbehalfof@manuscriptcentral.com>
3Reply-To: judithbishop@outlook.com
4To: a3moss@uwaterloo.ca, rschlunt@uwaterloo.ca, pabuhr@uwaterloo.ca
5Subject: Software: Practice and Experience - Decision on Manuscript ID SPE-18-0065
6
719-Apr-2018
8
9Dear Dr Buhr,
10
11Many thanks for submitting SPE-18-0065 entitled "Cforall : Adding Modern Programming
12Language Features to C" to Software: Practice and Experience. The paper has now
13been reviewed and the comments of the referee(s) are included at the bottom of
14this letter.
15
16I am delighted to inform you that the referee(s) have recommended publication,
17but also suggest some minor revisions to your manuscript.  Therefore, I invite
18you to respond to the referee(s)' comments and revise your manuscript. All of
19the referees' comments are important, but I would like you to pay special
20attention to the following general points:
21
221. If there is any more evaluation that a stack, please add it.
232. How is the compiler implemented?
243. What features are actually implemented?
254. The article lacks some related work. such as Haskell, ML etc.
265. 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.
276. Many references are not properly formatted
287. A statement about any presence or absence of conflicts of interest with Huawei should be explicitly added.
29
30The paper is long by SPE standards (33 pages). We have a maximum of 40
31pages. Please do not extend the paper beyond 35 pages. If necessary, find ways
32to cut the examples or text. If you have an accompanying website for the system
33where some examples are stored, please mention it.
34
35You have 42 days from the date of this email to submit your revision. If you
36are unable to complete the revision within this time, please contact me to
37request a short extension.
38
39You can upload your revised manuscript and submit it through your Author
40Center. Log into https://mc.manuscriptcentral.com/spe and enter your Author
41Center, where you will find your manuscript title listed under "Manuscripts
42with Decisions".
43
44When submitting your revised manuscript, you will be able to respond to the
45comments made by the referee(s) in the space provided.  You can use this space
46to document any changes you make to the original manuscript.
47
48If you feel that your paper could benefit from English language polishing, you
49may wish to consider having your paper professionally edited for English
50language by a service such as Wiley's at
51http://wileyeditingservices.com. Please note that while this service will
52greatly improve the readability of your paper, it does not guarantee acceptance
53of your paper by the journal.
54
55Once again, thank you for submitting your manuscript to Software: Practice and Experience. I look forward to receiving your revision.
56
57Sincerely,
58
59Dr Judith Bishop
60Editor, Software: Practice and Experience
61judithbishop@outlook.com
62
63Referee(s)' Comments to Author:
64
65Reviewing: 1
66
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.
110
111Done.
112
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.
128
129   3. Practical information about the work
130
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."),
134
135This sentence is replace with:
136
137 All languages features discussed in this paper are working, except some
138 advanced exception-handling features.
139
140and Section 5.4 Exception Handling states:
141
142 The following framework for Cforall exception handling is in place, excluding
143 some runtime type-information and virtual functions.
144
145   page 4 ("Under construction is a mechanism to distribute...")
146
147The feature on page 4 is now complete.
148
149   and page 33 ("There is ongoing work on a wide range ... ")
150
151This sentence is replace to indicate the ongoing work is future work.
152
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.
167
168See above.
169
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.
195
196See point 1.
197
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.
200
201The Phil-Karlton quote is an urban legend without a specific academic citation:
202
203  https://skeptics.stackexchange.com/questions/19836/has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science
204
205The term "const hell" is replaced with "const poisoning" with a citation.
206
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.
219
220   5.3 Typos:
221   - Page 3 "eager" should be "earlier"
222
223Fixed.
224
225   - Page 4 "vals" should be "arr"
226
227Actually it is "vals", and the example is changed so it is clear why.
228
229   - Page 21 "than" should be "then"
230
231Fixed.
232
233
234   6. Conflict of interest
235   I see that the work is partially supported by Huawei. Perhaps statement
236   about any presence or absence of conflicts of interest should be explicitly
237   added. Please get a clear direction on this from the editor of the journal.
238
239The paper now states the project is open-source, hence there is no conflict of
240interest with the funding received from Huawei.
241
242
243Reviewing: 2
244
245Comments to the Author
246
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.
294
295The following paragraph has been added at the start of Section 10.1:
296
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.
314
315At the end of Section 10.2, we state:
316
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.
320
321
322From: Judith Bishop <judithbishop@outlook.com>
323To: "Peter A. Buhr" <pabuhr@uwaterloo.ca>
324Subject: RE: Software: Practice and Experience - Decision on Manuscript ID
325 SPE-18-0065
326Date: Tue, 24 Apr 2018 16:45:51 +0000
327Accept-Language: em-US
328
329Hi Peter
330
331Great to hear from you. I am also glad your paper got through, as it is in the
332mainline of the SPE scope.
333
334It is important to mention that the software is open source. People really
335value that. In the acknowledgements, you can refer to Huawei for funding. It is
336quite normal to have industrial funding, and in fact it is a plus.
337
338I think that sorts out the comment from the referee.
339
340Looking forward to your revised submission.
341
342Kind regards
343
344Judith Bishop
345Extraordinary Professor, Computer Science
346Stellenbosch University, South Africa
347082 301 5220 / 021 671 5133
348judithbishop@outlook.com     LinkedIn
349
350-----Original Message-----
351From: Peter A. Buhr <pabuhr@uwaterloo.ca>
352Sent: Tuesday, April 24, 2018 6:25 PM
353To: judithbishop@outlook.com
354Cc: a3moss@uwaterloo.ca; rschlunt@uwaterloo.ca
355Subject: Re: Software: Practice and Experience - Decision on Manuscript ID SPE-18-0065
356
357Hi Judy! Hope all is well.
358
359We are over-the-moon to get our paper accepted at SP&E, and we are actively
360working on your and the referee's comments.
361
362One comment where we need assistance is:
363
364  7. A statement about any presence or absence of conflicts of interest with
365     Huawei should be explicitly added.
366
367We forgotten to mention in the paper that our project is open-source. So Huawei
368was funding an open-source project. In fact, the Huawei funding ends soon, so
369there will be no direct affiliation in a couple of months, although there are a
370few people at Huawei who remain very interested in the project.
371
372So does stating that the Cforall project is an open-source project deal with
373the issue of conflict of interest?
Note: See TracBrowser for help on using the repository browser.