source: doc/papers/OOPSLA17/mail @ b12e4ad

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

restructure paper documents

  • Property mode set to 100644
File size: 18.7 KB
Line 
1From: "OOPSLA'17 HotCRP" <noreply@oopsla17.hotcrp.com>
2Subject: [OOPSLA'17] Registered #20 "Generic and Tuple Types with
3 Efficient..."
4To: Aaron Moss <a3moss@uwaterloo.ca>, Peter Buhr <pabuhr@uwaterloo.ca>
5Date: Wed,  5 Apr 2017 19:20:09 +0000 (UTC)
6
7Submission #20 has been registered at the 2017 ACM SIGPLAN International
8Conference on Object-Oriented Programming, Systems, Languages, and
9Applications (OOPSLA'17) site.
10
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: https://oopsla17.hotcrp.com/paper/20?cap=020aob3NvMVprLQ
16
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.
20
21Contact Jonathan Aldrich <jonathan.aldrich@cs.cmu.edu> with any questions
22or concerns.
23
24- OOPSLA'17 Submissions
25
26
27
28From: "OOPSLA'17 HotCRP" <noreply@oopsla17.hotcrp.com>
29Subject: [OOPSLA'17] Account information
30To: Peter Buhr <pabuhr@uwaterloo.ca>
31Date: Wed,  5 Apr 2017 19:20:09 +0000 (UTC)
32
33Greetings,
34
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.
38
39        Site: https://oopsla17.hotcrp.com/
40       Email: pabuhr@uwaterloo.ca
41    Password: htrkiy5slu8drk
42
43Use the link below to sign in.
44
45https://oopsla17.hotcrp.com/?email=pabuhr%40uwaterloo.ca&password=htrkiy5slu8drk
46
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".
50
51Contact Jonathan Aldrich <jonathan.aldrich@cs.cmu.edu> with any questions
52or concerns.
53
54- OOPSLA'17 Submissions
55
56
57
58From: "OOPSLA'17 HotCRP" <noreply@oopsla17.hotcrp.com>
59Subject: [OOPSLA'17] Updated #20 "Generic and Tuple Types with Efficient..."
60To: Aaron Moss <a3moss@uwaterloo.ca>, Peter Buhr <pabuhr@uwaterloo.ca>
61Date: Tue, 18 Apr 2017 03:05:16 +0000 (UTC)
62
63Submission #20 has been updated at the 2017 ACM SIGPLAN International
64Conference on Object-Oriented Programming, Systems, Languages, and
65Applications (OOPSLA'17) site.
66
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: https://oopsla17.hotcrp.com/paper/20?cap=020aob3NvMVprLQ
72
73You will receive email when reviews are available. Further updates are
74allowed until 18 Apr 2017 7:59:59am EDT.
75
76Contact Jonathan Aldrich <jonathan.aldrich@cs.cmu.edu> with any questions
77or concerns.
78
79- OOPSLA'17 Submissions
80
81
82
83From: "OOPSLA'17 HotCRP" <noreply@oopsla17.hotcrp.com>
84Subject: [OOPSLA'17] Paper #20 "Generic and Tuple Types with Efficient..."
85To: Peter Buhr <pabuhr@uwaterloo.ca>
86Cc: jonathan.aldrich@cs.cmu.edu
87Reply-To: jonathan.aldrich@cs.cmu.edu
88Date: Wed,  7 Jun 2017 13:33:40 +0000 (UTC)
89
90Dear Peter Buhr,
91
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).
96
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.
103
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.
109
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").
115
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
122identity)"
123
124Your paper's access information is below:
125
126       Title: Generic and Tuple Types with Efficient Dynamic Layout in C∀
127  Paper site: https://oopsla17.hotcrp.com/paper/20
128
129Use the link below to sign in to the site.
130
131https://oopsla17.hotcrp.com/?email=pabuhr%40uwaterloo.ca
132
133Please contact me <jonathan.aldrich@cs.cmu.edu> with any questions or
134concerns.
135
136Best Regards and wishes for a constructive response,
137
138Jonathan Aldrich
139
140
141
142From: "OOPSLA'17 HotCRP" <noreply@oopsla17.hotcrp.com>
143Subject: [OOPSLA'17] Paper #20 "Generic and Tuple Types with Efficient..."
144To: Peter Buhr <pabuhr@uwaterloo.ca>
145Cc: jonathan.aldrich@cs.cmu.edu
146Reply-To: jonathan.aldrich@cs.cmu.edu
147Date: Tue, 20 Jun 2017 00:33:10 +0000 (UTC)
148
149Dear Peter Buhr,
150
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.
157
158       Title: Generic and Tuple Types with Efficient Dynamic Layout in C∀
159  Paper site: https://oopsla17.hotcrp.com/paper/20
160  Login link: https://oopsla17.hotcrp.com/?email=pabuhr%40uwaterloo.ca
161
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
164useful.
165
166Best Regards,
167
168- Jonathan Aldrich <jonathan.aldrich@cs.cmu.edu>, for OOPSLA 2017
169Submissions
170
171
172
173===========================================================================
174                           OOPSLA'17 Review #20A
175---------------------------------------------------------------------------
176 Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
177---------------------------------------------------------------------------
178
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
182
183                         ===== Paper summary =====
184
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.
186
187                      ===== Comments for author =====
188
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.
190
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.
192
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 http://dl.acm.org/citation.cfm?doid=13310.13330.
194
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.
196
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.
198
199It is not obvious that type inference here always converges. An outline of the algorithm would be useful.
200
201Above all, this needs experience results from a more complete implementation.
202
203Details:
204
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.
206
207The print example seems a little simplistic, since it's not clear how it handles formatting.
208
209"does not using the return type"
210
211              ===== Questions for authors’ response =====
212
213How are atomics, volatile, and bit-fields in structs handled?
214
215===========================================================================
216                           OOPSLA'17 Review #20B
217---------------------------------------------------------------------------
218 Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
219---------------------------------------------------------------------------
220
221                      Overall merit: D. Reject
222                         Confidence: X. I am an expert in this area
223
224                         ===== Paper summary =====
225
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.
227
228                      ===== Comments for author =====
229
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.
231
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.
233
234## On the design of C-forall
235
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.
237
238## Evaluation
239
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.
241
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++.
243
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).
245
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.
247
248
249## Related work
250
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).
252
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.
254
255===========================================================================
256                           OOPSLA'17 Review #20C
257---------------------------------------------------------------------------
258 Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
259---------------------------------------------------------------------------
260
261                      Overall merit: D. Reject
262                         Confidence: Z. I am not an expert; my evaluation
263                                        is that of an informed outsider
264
265                         ===== Paper summary =====
266
267The paper presents two language features of "Cforall": generics and tuples.
268
269                      ===== Comments for author =====
270
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++?
272
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?
279
280About Tuples:
281The section about tuples is too long. I would have spent more time explaining generics.
282
283Feedback:
284"This installation base"
285Unclear what you mean by that.
286
287"Prior projects ... but failed ..."
288Hummm ... What about C++.
289
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.
293
294"In many cases, C++ is often ..."
295This sentence feels like it is coming out of nowhere.
296
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?
300
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.
305
306"... allows variable overloading ..."
307How are conflict resolved? In other words, what happens when two variables could be used?
308
309"... reuses the generated structure declarations where appropriate."
310This is too vague.
311
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".
315
316"The type-resolver ..."
317What's that? Type-checker? Type-inference?
318
319"... applies C conversions."
320Noooo! That's exactly what leads to very subtle bugs. Is there any way to stop those conversions from happening?
321
322"The minimal cost ..."
323In what regard? Runtime cost? How does the "resolver" know how expensive the conversions are?
324
325"z = 10 // mass assignments"
326That stuff is completely unreadable. Why not introduce a new operator?
327
328"... roughly equivalent time ..."
329Well, C++ looks faster to me.
330
331"... is restricted because the resolution does not using ..."
332Did you mean, does not use?
333
334"... D and go are garbage collected ..."
335Yes, but in D, the use of the GC is optional.
336
337"... while respecting the talent and skill of C programmers."
338Are you implying that other approaches are not?
339
340"On the surface, the project may appear as a rehash of similar mechanisms in C++."
341Absolutely.
342
343"... integration with C and its programmers ..."
344Bold claim. What makes you think you are integrated with programmers? Number of users?
345
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.