source: doc/papers/general/response @ 387c9a1

Date: Thu, 19 Apr 2018 17:01:14 -0400 (EDT)
From: "Software: Practice and Experience" <onbehalfof@manuscriptcentral.com>
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 <judithbishop@outlook.com>
To: "Peter A. Buhr" <pabuhr@uwaterloo.ca>
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 <pabuhr@uwaterloo.ca> 
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?