Ignore:
Timestamp:
Jul 5, 2017, 4:59:17 PM (7 years ago)
Author:
Rob Schluntz <rschlunt@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
5805d15
Parents:
b1e63ac5 (diff), 1ce2189 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' of plg.uwaterloo.ca:/u/cforall/software/cfa/cfa-cc into references

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/generic_types/mail

    rb1e63ac5 r208e5be  
    7878
    7979- 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 TracChangeset for help on using the changeset viewer.