Changeset 5995116

Timestamp:

Apr 3, 2017, 12:00:58 PM (8 years ago)

Author:

Aaron Moss <a3moss@…>

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:

7444113

Parents:

1d29d46

Message:

Update TODOs, language references

Location:

doc

Files:

• bibliography/cfa.bib (modified) (1 diff)
• generic_types/.gitignore (modified) (1 diff)
• generic_types/generic_types.tex (modified) (7 diffs)

doc/bibliography/cfa.bib

@@ -860 +860 @@
 }
 
-@manual{C11,
+@techreport{C11,
+    type = {International Standard},
     keywords    = {ISO/IEC C 11},
     contributer = {pabuhr@plg},
-    key         = {C11},
+    key         = {{ISO/IEC} 9889-2011},
     title       = {American National Standard Information technology -- Programming Languages -- {C}},
-    organization= {International Standard ISO/IEC 9899-2011[2012]},
-    publisher   = {International Standard Organization},
+    institution = {International Standard Organization},
     address     = {http://www.iso.org},
     year        = 2012,
 }
 
-@manual{C++Concepts,
+@techreport{C++Concepts,
+    type = {International Standard},
     keywords    = {ISO/IEC TS 19217:2015},
     contributer = {a3moss@uwaterloo.ca},
-    key         = {C++ Concepts},
+    key         = {{ISO/IEC} {TS} 19217},
     title       = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts},
-    organization= {International Standard ISO/IEC TS 19217:2015},
-    publisher   = {International Standard Organization},
+    institution = {International Standard Organization},
     address     = {http://www.iso.org},
     year        = 2015

doc/generic_types/.gitignore

@@ -16 +16 @@
 *.lot
 *.synctex.gz
+comment.cut

doc/generic_types/generic_types.tex

@@ -29 +29 @@
 \newcommand{\CCtwenty}{\rm C\kern-.1em\hbox{+\kern-.25em+}20\xspace} % C++20 symbolic name
 
-\newcommand{\TODO}{\textbf{TODO}}
+\newcommand{\TODO}[1]{\textbf{TODO}: #1} % TODO included
+%\newcommand{\TODO}[1]{} % TODO elided
 \newcommand{\eg}{\textit{e}.\textit{g}.,\xspace}
 \newcommand{\ie}{\textit{i}.\textit{e}.,\xspace}
@@ -280 +281 @@
 };
 \end{lstlisting}
-Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete struct type -- they can be stack-allocated using the @alloca@ compiler builtin, default or copy-initialized, assigned, and deleted. As an example, the @sum@ function produces generated code something like the following (simplified for clarity and brevity) \TODO{} fix example, maybe elide, it's likely too long with the more complicated function:
+Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete struct type -- they can be stack-allocated using the @alloca@ compiler builtin, default or copy-initialized, assigned, and deleted. As an example, the @sum@ function produces generated code something like the following (simplified for clarity and brevity)\TODO{fix example, maybe elide, it's likely too long with the more complicated function}:
 \begin{lstlisting}
 void abs( size_t _sizeof_M, size_t _alignof_M,
@@ -629 +630 @@
   [int, [int, int], int] g();
 
-  ([int, double])f();           // (1)
-  ([int, int, int])g();         // (2)
-  ([void, [int, int]])g();      // (3)
-  ([int, int, int, int])g();    // (4)
-  ([int, [int, int, int]])g();  // (5)
+  ([int, double])f();           $\C{// (1)}$
+  ([int, int, int])g();         $\C{// (2)}$
+  ([void, [int, int]])g();      $\C{// (3)}$
+  ([int, int, int, int])g();    $\C{// (4)}$
+  ([int, [int, int, int]])g();  $\C{// (5)}$
 \end{lstlisting}
 
@@ -766 +767 @@
 In the call to @new@, @Pair(double, char)@ is selected to match @T@, and @Params@ is expanded to match @[double, char]@. The constructor (1) may be specialized to  satisfy the assertion for a constructor with an interface compatible with @void ?{}(Pair(int, char) *, int, char)@.
 
-\TODO{} Check if we actually can use ttype parameters on generic types (if they set the complete flag, it should work, or nearly so).
+\TODO{Check if we actually can use ttype parameters on generic types (if they set the complete flag, it should work, or nearly so).}
 
 \subsection{Implementation}
@@ -849 +850 @@
 The various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions. A variable is generated to store the value produced by a statement expression, since its fields may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg in a unique expression. The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language. However, there are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this restriction is not new.
 
+\section{Evaluation}
+
+\TODO{Magnus suggests we need some graphs, it's kind of a done thing that the reviewers will be looking for. Also, we've made some unsubstantiated claims about the runtime performance of \CFA, which some micro-benchmarks could help with. I'm thinking a simple stack push and pop, with an idiomatic \lstinline@void*@, \CFA, \CC template and \CC virtual inheritance versions (the void* and virtual inheritance versions likely need to be linked lists, or clumsy in their API -- possibly both versions) to test generics, and variadic print to test tuples. We measure SLOC, runtime performance, executable size (making sure to include benchmarks for multiple types in the executable), and possibly manually count the number of places where the programmer must provide un-type-checked type information. Appendices don't count against our page limit, so we might want to include the source code for the benchmarks (or at least the relevant implementation details) in one.}
+
 \section{Related Work}
 
@@ -855 +860 @@
 Cyclone also provides capabilities for polymorphic functions and existential types~\citep{Grossman06}, similar in concept to \CFA's @forall@ functions and generic types. Cyclone existential types can include function pointers in a construct similar to a virtual function table, but these pointers must be explicitly initialized at some point in the code, a tedious and potentially error-prone process. Furthermore, Cyclone's polymorphic functions and types are restricted in that they may only abstract over types with the same layout and calling convention as @void*@, in practice only pointer types and @int@ - in \CFA terms, all Cyclone polymorphism must be dtype-static. This design provides the efficiency benefits discussed in Section~\ref{sec:generic-apps} for dtype-static polymorphism, but is more restrictive than \CFA's more general model.
 
-Go and Rust are both modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in Go and \emph{traits} in Rust. However, both languages represent dramatic departures from C in terms of language model, and neither has the same level of compatibility with C as \CFA. Go is a garbage-collected language, imposing the associated runtime overhead, and complicating foreign-function calls with the necessity of accounting for data transfer between the managed Go runtime and the unmanaged C runtime. Furthermore, while generic types and functions are available in Go, they are limited to a small fixed set provided by the compiler, with no language facility to define more. Rust is not garbage-collected, and thus has a lighter-weight runtime that is more easily interoperable with C. It also possesses much more powerful abstraction capabilities for writing generic code than Go. On the other hand, Rust's borrow-checker, while it does provide strong safety guarantees, is complex and difficult to learn, and imposes a distinctly idiomatic programming style on Rust. \CFA, with its more modest safety features, is significantly easier to port C code to, while maintaining the idiomatic style of the original source.
+Go \citep{Go} and Rust \citep{Rust} are both modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in Go and \emph{traits} in Rust. However, both languages represent dramatic departures from C in terms of language model, and neither has the same level of compatibility with C as \CFA. Go is a garbage-collected language, imposing the associated runtime overhead, and complicating foreign-function calls with the necessity of accounting for data transfer between the managed Go runtime and the unmanaged C runtime. Furthermore, while generic types and functions are available in Go, they are limited to a small fixed set provided by the compiler, with no language facility to define more. Rust is not garbage-collected, and thus has a lighter-weight runtime that is more easily interoperable with C. It also possesses much more powerful abstraction capabilities for writing generic code than Go. On the other hand, Rust's borrow-checker, while it does provide strong safety guarantees, is complex and difficult to learn, and imposes a distinctly idiomatic programming style on Rust. \CFA, with its more modest safety features, is significantly easier to port C code to, while maintaining the idiomatic style of the original source.
 
 \section{Conclusion \& Future Work}
@@ -862 +867 @@
 
 \begin{acks}
+The authors would like to thank Magnus Madsen for valuable editorial feedback.
+
 This work is supported in part by a corporate partnership with \grantsponsor{Huawei}{Huawei Ltd.}{http://www.huawei.com}\ and the first author's \grantsponsor{NSERC-PGS}{NSERC PGS D}{http://www.nserc-crsng.gc.ca/Students-Etudiants/PG-CS/BellandPostgrad-BelletSuperieures_eng.asp} scholarship.
 \end{acks}