Changeset a5de33e for doc/generic_types/mail

Timestamp:

Jul 5, 2017, 5:00:46 PM (8 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:

55a68c3, 5805d15

Parents:

f7cb0bc (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

File:

• doc/generic_types/mail (modified) (1 diff)

doc/generic_types/mail

@@ -78 +78 @@
 
 - OOPSLA'17 Submissions
+
+
+
+From: "OOPSLA'17 HotCRP" <noreply@oopsla17.hotcrp.com>
+Subject: [OOPSLA'17] Paper #20 "Generic and Tuple Types with Efficient..."
+To: Peter Buhr <pabuhr@uwaterloo.ca>
+Cc: jonathan.aldrich@cs.cmu.edu
+Reply-To: jonathan.aldrich@cs.cmu.edu
+Date: Wed,  7 Jun 2017 13:33:40 +0000 (UTC)
+
+Dear Peter Buhr,
+
+The author response period for OOPSLA has started, and will continue until
+the end of June 10th (Anywhere on Earth).  No email with a snapshot of your
+reviews will be sent: you can see the live version of reviews (including
+current updates) on the HotCRP system (links at the bottom).
+
+An author response should aim to:
+ -correct reviewers' mistakes or misunderstandings
+ -offer new information only when this addresses reviewers' concerns (e.g.,
+"I wonder if A might work better...";  "we tried that, but...")
+ -answer explicit questions by the reviewers. The key questions will be in a
+designated "Questions for Author Response" entry of a review.
+
+Please keep in mind that an author response is *not* a "rebuttal". You are
+not rebutting an opponent's arguments with your own, in front of an
+audience that weighs both sets of arguments. Instead, your audience is the
+same reviewers who offered the comments in the first place, and their
+subjective weighing of different factors is very unlikely to change.
+
+During author response, please keep in mind that the reviewers are still
+unaware of author identity. If you need to refer to author-identifying
+information during your response, the ideal course of action is to place it
+at an external location and include a URL, with an explicit warning (e.g.,
+"WARNING: following this link will reveal author identity").
+
+As with all external resources, your response should be self-contained,
+without consulting them. That is, the author-visible external URL is just
+evidence, but the claim that this evidence supports should be clear in the
+response text. For instance:
+"we have received public feedback from the developers of X that confirm the
+issue [supporting URL] (WARNING: following this link will reveal author
+identity)"
+
+Your paper's access information is below:
+
+       Title: Generic and Tuple Types with Efficient Dynamic Layout in C∀
+  Paper site: https://oopsla17.hotcrp.com/paper/20
+
+Use the link below to sign in to the site.
+
+https://oopsla17.hotcrp.com/?email=pabuhr%40uwaterloo.ca
+
+Please contact me <jonathan.aldrich@cs.cmu.edu> with any questions or
+concerns.
+
+Best Regards and wishes for a constructive response,
+
+Jonathan Aldrich
+
+
+
+From: "OOPSLA'17 HotCRP" <noreply@oopsla17.hotcrp.com>
+Subject: [OOPSLA'17] Paper #20 "Generic and Tuple Types with Efficient..."
+To: Peter Buhr <pabuhr@uwaterloo.ca>
+Cc: jonathan.aldrich@cs.cmu.edu
+Reply-To: jonathan.aldrich@cs.cmu.edu
+Date: Tue, 20 Jun 2017 00:33:10 +0000 (UTC)
+
+Dear Peter Buhr,
+
+I regret to inform you that your submission to OOPSLA'17 listed below has not
+been selected for the second phase of the review process. I understand this is
+not welcome news but selection was very competitive: 157 of the 223 papers
+submitted did not advance to the second phase. For several of these, there was
+a clear impression that in the future they can evolve into some of the
+strongest results of our community.
+
+       Title: Generic and Tuple Types with Efficient Dynamic Layout in C∀
+  Paper site: https://oopsla17.hotcrp.com/paper/20
+  Login link: https://oopsla17.hotcrp.com/?email=pabuhr%40uwaterloo.ca
+
+Below you will find reviews, as well as author-visible comments--the latter may
+include further communication. I hope you will find the reviewers' feedback
+useful.
+
+Best Regards,
+
+- Jonathan Aldrich <jonathan.aldrich@cs.cmu.edu>, for OOPSLA 2017
+Submissions
+
+
+
+===========================================================================
+                           OOPSLA'17 Review #20A
+---------------------------------------------------------------------------
+ Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
+---------------------------------------------------------------------------
+
+                      Overall merit: C. Weak paper, though I will not fight
+                                        strongly against it
+                         Confidence: X. I am an expert in this area
+
+                         ===== Paper summary =====
+
+This 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.
+
+                      ===== Comments for author =====
+
+This 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.
+
+Unfortunately, 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.
+
+The 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.
+
+There 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.
+
+I 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. 
+
+It is not obvious that type inference here always converges. An outline of the algorithm would be useful.
+
+Above all, this needs experience results from a more complete implementation.
+
+Details:
+
+Relying 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.
+
+The print example seems a little simplistic, since it's not clear how it handles formatting.
+
+"does not using the return type"
+
+              ===== Questions for authors’ response =====
+
+How are atomics, volatile, and bit-fields in structs handled?
+
+===========================================================================
+                           OOPSLA'17 Review #20B
+---------------------------------------------------------------------------
+ Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
+---------------------------------------------------------------------------
+
+                      Overall merit: D. Reject
+                         Confidence: X. I am an expert in this area
+
+                         ===== Paper summary =====
+
+The 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.
+
+                      ===== Comments for author =====
+
+The 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.
+
+While 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.
+
+## On the design of C-forall
+
+There 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.
+
+## Evaluation
+
+The 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.
+
+A 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++.
+
+However, 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).
+
+Finally, 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.
+
+
+## Related work
+
+The 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).
+
+The 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.
+
+===========================================================================
+                           OOPSLA'17 Review #20C
+---------------------------------------------------------------------------
+ Paper #20: Generic and Tuple Types with Efficient Dynamic Layout in C∀
+---------------------------------------------------------------------------
+
+                      Overall merit: D. Reject
+                         Confidence: Z. I am not an expert; my evaluation
+                                        is that of an informed outsider
+
+                         ===== Paper summary =====
+
+The paper presents two language features of "Cforall": generics and tuples.
+
+                      ===== Comments for author =====
+
+The 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++?
+
+Comparison with C++:
+The 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 ...).
+Now, when doing system programming, one needs very fine grain control over the resources: memory layout, etc ...
+It 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.
+The authors need to better justify the runtime overhead, or give escape hatches for those who don't want to pay that cost at runtime.
+They 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?
+
+About Tuples:
+The section about tuples is too long. I would have spent more time explaining generics.
+
+Feedback:
+"This installation base"
+Unclear what you mean by that.
+
+"Prior projects ... but failed ..."
+Hummm ... What about C++.
+
+"... object-oriented or functional programming with garbage collection ..."
+You are really mixing apples and oranges here. Many C programmers have nothing agains object-oriented features, not even functional programming (C++ 11 adds
+a bunch of features proving my point), but it's clear that most of them feel very strongly against automated garbage collection.
+
+"In many cases, C++ is often ..."
+This sentence feels like it is coming out of nowhere.
+
+"... the polymorphic runtime-cost ..."
+Is 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
+the overhead at runtime. Is there a way to force the compiler to specialize the code?
+
+"... to write a type-safe Cforall wrapper malloc based ..."
+That cannot be true in general. Malloc produces a pointer (of any type), given an integer (the size).
+It looks like Cforall is assuming that the integer is the result of a call to sizeof (a good practice in C).
+However, if that's the case, it should be explained.
+
+"... allows variable overloading ..."
+How are conflict resolved? In other words, what happens when two variables could be used?
+
+"... reuses the generated structure declarations where appropriate."
+This is too vague.
+
+"... have multiple outcomes, some exceptional."
+Humm, 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
+return one or multiple values or throw an exception. Not that some of the values returned are "exceptional".
+
+"The type-resolver ..."
+What's that? Type-checker? Type-inference?
+
+"... applies C conversions."
+Noooo! That's exactly what leads to very subtle bugs. Is there any way to stop those conversions from happening?
+
+"The minimal cost ..."
+In what regard? Runtime cost? How does the "resolver" know how expensive the conversions are?
+
+"z = 10 // mass assignments"
+That stuff is completely unreadable. Why not introduce a new operator?
+
+"... roughly equivalent time ..."
+Well, C++ looks faster to me.
+
+"... is restricted because the resolution does not using ..."
+Did you mean, does not use?
+
+"... D and go are garbage collected ..."
+Yes, but in D, the use of the GC is optional.
+
+"... while respecting the talent and skill of C programmers."
+Are you implying that other approaches are not?
+
+"On the surface, the project may appear as a rehash of similar mechanisms in C++."
+Absolutely.
+
+"... integration with C and its programmers ..."
+Bold claim. What makes you think you are integrated with programmers? Number of users?
+
+"... inline annotation at polymorphic function call sites to create a template-specialization ..."
+This should have been mentioned sooner. Plus conflating inlining and specialization is unfortunate.
+Does "inline" also inline the function? Or does it only specialize the code?
+If it also inline, that's a very unfortunate design. I might want to specialize the code, but without inlining ...
+How do I specialize a recursive function?