source: doc/papers/OOPSLA17/mail

Last change on this file was f4e3419d, checked in by Peter A. Buhr <pabuhr@…>, 6 years ago

restructure paper documents

  • Property mode set to 100644
File size: 18.7 KB
1From: "OOPSLA'17 HotCRP" <>
2Subject: [OOPSLA'17] Registered #20 "Generic and Tuple Types with
3 Efficient..."
4To: Aaron Moss <>, Peter Buhr <>
5Date: Wed,  5 Apr 2017 19:20:09 +0000 (UTC)
7Submission #20 has been registered at the 2017 ACM SIGPLAN International
8Conference on Object-Oriented Programming, Systems, Languages, and
9Applications (OOPSLA'17) site.
11       Title: Generic and Tuple Types with Efficient Dynamic Layout in C∀
12     Authors: Aaron Moss (University of Waterloo)
13              Robert Schluntz (University of Waterloo)
14              Peter Buhr (University of Waterloo)
15  Paper site:
17The submission has not yet been uploaded. Further updates are allowed until
1818 Apr 2017 7:59:59am EDT. If the submission is not ready for review by 18
19Apr 2017 7:59:59am EDT, it will not be considered.
21Contact Jonathan Aldrich <> with any questions
22or concerns.
24- OOPSLA'17 Submissions
28From: "OOPSLA'17 HotCRP" <>
29Subject: [OOPSLA'17] Account information
30To: Peter Buhr <>
31Date: Wed,  5 Apr 2017 19:20:09 +0000 (UTC)
35An account has been created for you at the 2017 ACM SIGPLAN International
36Conference on Object-Oriented Programming, Systems, Languages, and
37Applications (OOPSLA'17) submissions site.
39        Site:
40       Email:
41    Password: htrkiy5slu8drk
43Use the link below to sign in.
47If you already have an account under a different email address, you may
48merge this new account into that one. Go to your profile page and select
49"Merge with another account".
51Contact Jonathan Aldrich <> with any questions
52or concerns.
54- OOPSLA'17 Submissions
58From: "OOPSLA'17 HotCRP" <>
59Subject: [OOPSLA'17] Updated #20 "Generic and Tuple Types with Efficient..."
60To: Aaron Moss <>, Peter Buhr <>
61Date: Tue, 18 Apr 2017 03:05:16 +0000 (UTC)
63Submission #20 has been updated at the 2017 ACM SIGPLAN International
64Conference on Object-Oriented Programming, Systems, Languages, and
65Applications (OOPSLA'17) site.
67       Title: Generic and Tuple Types with Efficient Dynamic Layout in C∀
68     Authors: Aaron Moss (University of Waterloo)
69              Robert Schluntz (University of Waterloo)
70              Peter Buhr (University of Waterloo)
71  Paper site:
73You will receive email when reviews are available. Further updates are
74allowed until 18 Apr 2017 7:59:59am EDT.
76Contact Jonathan Aldrich <> with any questions
77or concerns.
79- OOPSLA'17 Submissions
83From: "OOPSLA'17 HotCRP" <>
84Subject: [OOPSLA'17] Paper #20 "Generic and Tuple Types with Efficient..."
85To: Peter Buhr <>
88Date: Wed,  7 Jun 2017 13:33:40 +0000 (UTC)
90Dear Peter Buhr,
92The author response period for OOPSLA has started, and will continue until
93the end of June 10th (Anywhere on Earth).  No email with a snapshot of your
94reviews will be sent: you can see the live version of reviews (including
95current updates) on the HotCRP system (links at the bottom).
97An author response should aim to:
98 -correct reviewers' mistakes or misunderstandings
99 -offer new information only when this addresses reviewers' concerns (e.g.,
100"I wonder if A might work better...";  "we tried that, but...")
101 -answer explicit questions by the reviewers. The key questions will be in a
102designated "Questions for Author Response" entry of a review.
104Please keep in mind that an author response is *not* a "rebuttal". You are
105not rebutting an opponent's arguments with your own, in front of an
106audience that weighs both sets of arguments. Instead, your audience is the
107same reviewers who offered the comments in the first place, and their
108subjective weighing of different factors is very unlikely to change.
110During author response, please keep in mind that the reviewers are still
111unaware of author identity. If you need to refer to author-identifying
112information during your response, the ideal course of action is to place it
113at an external location and include a URL, with an explicit warning (e.g.,
114"WARNING: following this link will reveal author identity").
116As with all external resources, your response should be self-contained,
117without consulting them. That is, the author-visible external URL is just
118evidence, but the claim that this evidence supports should be clear in the
119response text. For instance:
120"we have received public feedback from the developers of X that confirm the
121issue [supporting URL] (WARNING: following this link will reveal author
124Your paper's access information is below:
126       Title: Generic and Tuple Types with Efficient Dynamic Layout in C∀
127  Paper site:
129Use the link below to sign in to the site.
133Please contact me <> with any questions or
136Best Regards and wishes for a constructive response,
138Jonathan Aldrich
142From: "OOPSLA'17 HotCRP" <>
143Subject: [OOPSLA'17] Paper #20 "Generic and Tuple Types with Efficient..."
144To: Peter Buhr <>
147Date: Tue, 20 Jun 2017 00:33:10 +0000 (UTC)
149Dear Peter Buhr,
151I regret to inform you that your submission to OOPSLA'17 listed below has not
152been selected for the second phase of the review process. I understand this is
153not welcome news but selection was very competitive: 157 of the 223 papers
154submitted did not advance to the second phase. For several of these, there was
155a clear impression that in the future they can evolve into some of the
156strongest results of our community.
158       Title: Generic and Tuple Types with Efficient Dynamic Layout in C∀
159  Paper site:
160  Login link:
162Below you will find reviews, as well as author-visible comments--the latter may
163include further communication. I hope you will find the reviewers' feedback
166Best Regards,
168- Jonathan Aldrich <>, for OOPSLA 2017
174                           OOPSLA'17 Review #20A
176 Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
179                      Overall merit: C. Weak paper, though I will not fight
180                                        strongly against it
181                         Confidence: X. I am an expert in this area
183                         ===== Paper summary =====
185This presents an extension of the C programming language that tries to preserve the character of the existing language, while adding tuples and generics. Unlike C++ templates, generics preserve separate compilation. Types are represented at runtime, if needed, by size and alignment values, along with pointers to the code for any needed operators. A microbenchmark performance comparison is provided.
187                      ===== Comments for author =====
189This is an interesting extension to C, that may be of interest to some C programmers. It generally seems to be fairly well engineered, and mostly respects C's design goals.
191Unfortunately, there have been enough proposals for extended C dialects that this sort of design is tough to sell. And I don't think the evaluation really went far enough to make that case.
193The ideas in the paper don't appear to be fundamentally new. The idea of passing types as runtime objects has certainly been explored before. An additional ancient reference is
195There seems to be a new idea of minimally describing types using alignment and size attributes instead of (?) pointers to assignment operators and the like. But this scheme is not very well described. Notably, it is not clear how, say, a struct with atomic field or bit-fields would be described.
197I wasn't quite clear on the extent to which operator overloading is supported. The MAX example appears to me like it would be quite controversial among C programmers.
199It is not obvious that type inference here always converges. An outline of the algorithm would be useful.
201Above all, this needs experience results from a more complete implementation.
205Relying on TIOBE here seems a bit dubious. Since it counts web pages, and C isn't exactly new and hot, it may actually understate your case.
207The print example seems a little simplistic, since it's not clear how it handles formatting.
209"does not using the return type"
211              ===== Questions for authors’ response =====
213How are atomics, volatile, and bit-fields in structs handled?
216                           OOPSLA'17 Review #20B
218 Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
221                      Overall merit: D. Reject
222                         Confidence: X. I am an expert in this area
224                         ===== Paper summary =====
226The authors present an extension to C, adding universal polymorphism and tuples. These features are described in prose. There is an implementation, though this is not described in depth in the paper. There is a benchmark evaluation.
228                      ===== Comments for author =====
230The paper is well-written and the concepts explained well. It is nice to see work in the low-level/C space - I believe that it is an area that has not been well-served by the OOPSLA community. My concerns with the paper are that the contribution is rather small and the concepts are not well-evaluated; specifically this is a language design paper and there is no attempt to evaluate the actual language design.
232While it is reasonable to describe only a couple of features in a paper, I would then expect a detailed description of the implementation and/or a formalism with proven safety properties and a thorough evaluation of the design. For a paper which only describes the design of a language the bar is higher than two features - for example, a description of a 'large' language such as D or Rust, even then I would expect a stronger evaluation.
234## On the design of C-forall
236There are some interesting points in the design of generics, notably the otype/dtype distinction. The design seems reasonable and follows what I would expect from other languages. The design for tuples is more unusual - the usual design of simple anonymous records with anonymous fields is extended with a mix of 'spread'ing, variadics, and implicit conversions. Importantly, the authors neither justify nor evaluate this departure - that is a severe omission for this paper. Furthermore, the only in-depth description of the implementation in the paper concerns tuples, and it seems to me that this is only interesting because of the unusual design - further reason for justifying it.
238## Evaluation
240The paper evaluates the implementation of C-forall with (effectively) a single micro-benchmark. That benchmark seems to show that C-forall performs worse than C++ on every measure, but this is not really discussed.
242A better performance evaluation would consist of multiple tests, both micro-benchmarks and realistic code and would test C-forall compared to alternatives (D, Rust, Go, etc.) not just C/C++.
244However, performance is not the really interesting thing to test here. The authors propose a new language and while performance is an important consideration for systems languages, it is far from the most important. I would like to see the usability of the language tested with user studies of different kinds (various levels of skill-level and coding scenarios). The authors could also use case studies or programming idioms to compare programming in C-forall vs the alternatives (again, comparing with D, Rust, etc. is more interesting to me than C).
246Finally, in designing C-forall, the authors make several assumptions about why C programmers use C. These should be backed up either with evaluation or citation. Statements in the paper certainly do not reflect my experience discussing language design with C programmers, and I would like to see them verified.
249## Related work
251The related work section is broad and gives good descriptions of other languages. However, the comparisons between languages focus more on the high-level goals of the language. It would be more interesting to focus on the details of the languages - the comparisons between Cyclone, C++, Java, and C-forall generics are good, I would like to see more of this with D and Rust, which are the more modern alternatives to C-forall (for example, Rust's notion of Sized and ?Sized types seems similar to otypes/dtypes).
253The related work is really missing any discussion of why the C-forall design choices are better than other languages. To clarify, I mean the specific design of generics and tuples, c.f., the suitability of the language in general because of garbage collection or learning difficulties.
256                           OOPSLA'17 Review #20C
258 Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
261                      Overall merit: D. Reject
262                         Confidence: Z. I am not an expert; my evaluation
263                                        is that of an informed outsider
265                         ===== Paper summary =====
267The paper presents two language features of "Cforall": generics and tuples.
269                      ===== Comments for author =====
271The authors really need to talk about C++ as early as possible IMHO. That's the first thing that came to mind when reading the abstract: how is this different from C++?
273Comparison with C++:
274The main difference with C++ seems to be that Cforall favors separate compilation at the expense of runtime overhead while C++ systematically avoids any runtime overhead (at the expense of slow compilation times). C++ approach makes more sense IMHO. While it's true that people where using C for almost everything 30 years ago, that is just not true anymore. Most people writing C today are doing system programming, otherwise there would be using a higher level programming language (C#, Java etc ...).
275Now, when doing system programming, one needs very fine grain control over the resources: memory layout, etc ...
276It is pretty clear to me that the people writing that kind of code will favor generics that do not cost any overhead at runtime, otherwise they would be writing Java in the first place.
277The authors need to better justify the runtime overhead, or give escape hatches for those who don't want to pay that cost at runtime.
278They very often go back to the benefit of separate compilation, but that's not enough IMHO. Here is a proposal: why not have 2 modes, one called debug mode, used while developing the code, that would compile generics with a runtime overhead. Another, called production, that would unfold the world like C++ does?
280About Tuples:
281The section about tuples is too long. I would have spent more time explaining generics.
284"This installation base"
285Unclear what you mean by that.
287"Prior projects ... but failed ..."
288Hummm ... What about C++.
290"... object-oriented or functional programming with garbage collection ..."
291You are really mixing apples and oranges here. Many C programmers have nothing agains object-oriented features, not even functional programming (C++ 11 adds
292a bunch of features proving my point), but it's clear that most of them feel very strongly against automated garbage collection.
294"In many cases, C++ is often ..."
295This sentence feels like it is coming out of nowhere.
297"... the polymorphic runtime-cost ..."
298Is there any way to avoid that overhead? It's true it will make the compiler faster, but there are cases where the user might not want to pay for
299the overhead at runtime. Is there a way to force the compiler to specialize the code?
301"... to write a type-safe Cforall wrapper malloc based ..."
302That cannot be true in general. Malloc produces a pointer (of any type), given an integer (the size).
303It looks like Cforall is assuming that the integer is the result of a call to sizeof (a good practice in C).
304However, if that's the case, it should be explained.
306"... allows variable overloading ..."
307How are conflict resolved? In other words, what happens when two variables could be used?
309"... reuses the generated structure declarations where appropriate."
310This is too vague.
312"... have multiple outcomes, some exceptional."
313Humm, I would say these two things are distinct. Let's just way that this way of presenting things is strange, I woulds ay that a function can either
314return one or multiple values or throw an exception. Not that some of the values returned are "exceptional".
316"The type-resolver ..."
317What's that? Type-checker? Type-inference?
319"... applies C conversions."
320Noooo! That's exactly what leads to very subtle bugs. Is there any way to stop those conversions from happening?
322"The minimal cost ..."
323In what regard? Runtime cost? How does the "resolver" know how expensive the conversions are?
325"z = 10 // mass assignments"
326That stuff is completely unreadable. Why not introduce a new operator?
328"... roughly equivalent time ..."
329Well, C++ looks faster to me.
331"... is restricted because the resolution does not using ..."
332Did you mean, does not use?
334"... D and go are garbage collected ..."
335Yes, but in D, the use of the GC is optional.
337"... while respecting the talent and skill of C programmers."
338Are you implying that other approaches are not?
340"On the surface, the project may appear as a rehash of similar mechanisms in C++."
343"... integration with C and its programmers ..."
344Bold claim. What makes you think you are integrated with programmers? Number of users?
346"... inline annotation at polymorphic function call sites to create a template-specialization ..."
347This should have been mentioned sooner. Plus conflating inlining and specialization is unfortunate.
348Does "inline" also inline the function? Or does it only specialize the code?
349If it also inline, that's a very unfortunate design. I might want to specialize the code, but without inlining ...
350How do I specialize a recursive function?
Note: See TracBrowser for help on using the repository browser.