Context Navigation

-                      rf891424
+                      rb23d969
 \end{center}
 \lstMakeShortInline@%
 Love it or hate it, C is extremely popular, highly used, and one of the few system's languages.
+Love it or hate it, C is extremely popular, highly used, and one of the few systems languages.
 In many cases, \CC is often used solely as a better C.
 Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
 …
 (4) Extensions introduced by \CFA must be translated in the most efficient way possible.
 These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used.
 Unfortunately, \CC is actively diverging from C, so incremental additions require significant effort and training, coupled with multiple legacy design-choices that cannot be updated.
+\CC is often used similarly, but has the paired disadvantages of multiple legacy design-choices that cannot be updated and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
 \CFA is currently implemented as a source-to-source translator from \CFA to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3).
 …
 If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \emph{data type} (or @dtype@).
 In \CFA, the polymorphism runtime-cost is spread over each polymorphic call, due to passing more arguments to polymorphic functions; preliminary experiments show this overhead is similar to \CC virtual-function calls.
+In \CFA, the polymorphism runtime-cost is spread over each polymorphic call, due to passing more arguments to polymorphic functions; the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual-function calls.
 An advantage of this design is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat.
 Since bare polymorphic-types provide only a narrow set of available operations, \CFA provides a \emph{type assertion}~\cite{alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable.
+Since bare polymorphic-types provide a restricted set of available operations, \CFA provides a \emph{type assertion}~\cite{alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable.
 For example, the function @twice@ can be defined using the \CFA syntax for operator overloading:
 \begin{lstlisting}
 …
 One of the known shortcomings of standard C is that it does not provide reusable type-safe abstractions for generic data structures and algorithms.
 Broadly speaking, there are three approaches to create data structures in C.
+Broadly speaking, there are three approaches to implement abstract data structures in C.
 One approach is to write bespoke data structures for each context in which they are needed.
 While this approach is flexible and supports integration with the C type-checker and tooling, it is also tedious and error-prone, especially for more complex data structures.
 A second approach is to use @void *@--based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@, and does allow the use of common code for common functionality.
+A second approach is to use @void *@--based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@; an approach which does allow reuse of code for common functionality.
 However, basing all polymorphism on @void *@ eliminates the type-checker's ability to ensure that argument types are properly matched, often requiring a number of extra function parameters, pointer indirection, and dynamic allocation that would not otherwise be needed.
 A third approach to generic code is to use preprocessor macros, which does allow the generated code to be both generic and type-checked, but errors may be difficult to interpret.
 Furthermore, writing and using preprocessor macros can be unnatural and inflexible.
 Other languages use \emph{generic types}, \eg \CC and Java, to produce type-safe abstract data-types.
+\CC, Java, and other languages use \emph{generic types} to produce type-safe abstract data-types.
 \CFA also implements generic types that integrate efficiently and naturally with the existing polymorphic functions, while retaining backwards compatibility with C and providing separate compilation.
 However, for known concrete parameters, the generic type can be inlined, like \CC templates.
+However, for known concrete parameters, the generic type definition can be inlined, like \CC templates.
 A generic type can be declared by placing a @forall@ specifier on a @struct@ or @union@ declaration, and instantiated using a parenthesized list of types after the type name:
 …
 \CFA classifies generic types as either \emph{concrete} or \emph{dynamic}.
 Concrete have a fixed memory layout regardless of type parameters, while dynamic vary in memory layout depending on their type parameters.
+Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
 A type may have polymorphic parameters but still be concrete, called \emph{dtype-static}.
 Polymorphic pointers are an example of dtype-static types, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@  is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation.
 …
 Though \CFA implements concrete generic-types efficiently, it also has a fully general system for dynamic generic types.
 As mentioned in Section~\ref{sec:poly-fns}, @otype@ function parameters (in fact all @sized@ polymorphic parameters) come with implicit size and alignment parameters provided by the caller.
 Dynamic generic-types also have an \emph{offset array} containing structure member-offsets.
 A dynamic generic-union needs no such offset array, as all members are at offset 0 but size and alignment are still necessary.
+Dynamic generic-types also have an \emph{offset array} containing structure-member offsets.
+A dynamic generic-union needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.
 Access to members of a dynamic structure is provided at runtime via base-displacement addressing with the structure pointer and the member offset (similar to the @offsetof@ macro), moving a compile-time offset calculation to runtime.
 …
 \section{Evaluation}
+\label{sec:eval}
 Though \CFA provides significant added functionality over C, these added features have a low runtime penalty.
 …
 D restricts garbage collection to its own heap by default, while Rust is not garbage-collected, and thus has a lighter-weight runtime more interoperable with C.
 Rust also possesses much more powerful abstraction capabilities for writing generic code than Go.
 On the other hand, Rust's borrow-checker, provides strong safety guarantees but is complex and difficult to learn, and imposes a distinctly idiomatic programming style.
 \CFA, with its more modest safety features, ports directly to C code, while maintaining the idiomatic style of the original source.
+On the other hand, Rust's borrow-checker provides strong safety guarantees but is complex and difficult to learn and imposes a distinctly idiomatic programming style.
+\CFA, with its more modest safety features, allows direct ports of C code while maintaining the idiomatic style of the original source.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset b23d969 for doc/generic_types

Legend:

doc/generic_types/generic_types.tex

Download in other formats: