Changeset c87eb50

Apr 13, 2017, 4:54:42 PM (4 years ago)
Aaron Moss <a3moss@…>
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-env, no_list, persistent-indexer, resolv-new, with_gc
cceab8a (diff), ad4d035 (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.

Merge branch 'master' of

2 edited


  • doc/bibliography/cfa.bib

    rcceab8a rc87eb50  
    58925892    keywords    = {Scala programming language},
    58935893    contributer = {pabuhr@plg},
     5894    author      = {{Scala}},
    58945895    title       = {{Scala} Language Specification, Version 2.11},
    58955896    organization= {\'{E}cole Polytechnique F\'{e}d\'{e}rale de Lausanne},
    63096310    number      = 5,
    63106311    pages       = {341-346}
     6315    contributer = {pabuhr@plg},
     6316    author      = {Herb Sutter and Bjarne Stroustrup and Gabriel Dos Reis},
     6317    title       = {Structured bindings},
     6318    issue_date  = {2015-10-14},
     6319    month       = oct,
     6320    year        = 2015,
     6321    pages       = {1--6},
     6322    numpages    = {6},
     6323    note        = {\href{}{http://\\-jtc1/\-sc22/\-wg21/\-docs/\-papers/\-2015/\-p0144r0.pdf}},
  • doc/generic_types/generic_types.tex

    rcceab8a rc87eb50  
    958958\section{Related Work}
    960963\CC is the existing language it is most natural to compare \CFA to, as they are both more modern extensions to C with backwards source compatibility. The most fundamental difference in approach between \CC and \CFA is their approach to this C compatibility. \CC does provide fairly strong source backwards compatibility with C, but is a dramatically more complex language than C, and imposes a steep learning curve to use many of its extension features. For instance, in a break from general C practice, template code is typically written in header files, with a variety of subtle restrictions implied on its use by this choice, while the other polymorphism mechanism made available by \CC, class inheritance, requires programmers to learn an entirely new object-oriented programming paradigm; the interaction between templates and inheritance is also quite complex. \CFA, by contrast, has a single facility for polymorphic code, one which supports separate compilation and the existing procedural paradigm of C code. A major difference between the approaches of \CC and \CFA to polymorphism is that the set of assumed properties for a type is \emph{explicit} in \CFA. One of the major limiting factors of \CC's approach is that templates cannot be separately compiled, and, until concepts~\citep{C++Concepts} are standardized (currently anticipated for \CCtwenty), \CC provides no way to specify the requirements of a generic function in code beyond compilation errors for template expansion failures. By contrast, the explicit nature of assertions in \CFA allows polymorphic functions to be separately compiled, and for their requirements to be checked by the compiler; similarly, \CFA generic types may be opaque, unlike \CC template classes.
    966969D \citep{D}, Go \citep{Go}, and Rust \citep{Rust} are modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in D and Go and \emph{traits} in Rust. However, each language represents dramatic departures from C in terms of language model, and none has the same level of compatibility with C as \CFA. D and Go are garbage-collected languages, imposing the associated runtime overhead. The necessity of accounting for data transfer between the managed Go runtime and the unmanaged C runtime complicates foreign-function interface between Go and C. 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. D restricts garbage collection to its own heap by default, while Rust is not garbage-collected, and thus has a lighter-weight runtime that is more easily 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, 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.
     974Many programming languages have some form of tuple construct and/or variadic functions, \eg SETL, C, KW-C, \CC, D, Go, Java, ML, and Scala.
     975SETL~\cite{SETL} is a high-level mathematical programming language, with tuples being one of the primary data types.
     976Tuples in SETL allow subscripting, dynamic expansion, and multiple assignment.
     977KW-C~\cite{Buhr94a}, a predecessor of \CFA, introduced tuples to C as an extension of the C syntax, taking much of its inspiration from SETL.
     978The main contributions of that work were adding MRVF, tuple mass and multiple assignment, and record-field access.
     979\CCeleven introduced @std::tuple@ as a library variadic template structure.
     980Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values.
     981Operations include @std::get<N>@ to extract vales, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons.
     982\CCseventeen proposes \emph{structured bindings}~\cite{Sutter15} to eliminate pre-declaring variables and use of @std::tie@ for binding the results.
     983This extension requires the use of @auto@ to infer the types of the new variables, so complicated expressions with a non-obvious type must be documented with some other mechanism.
     984Furthermore, structured bindings are not a full replacement for @std::tie@, as it always declares new variables.
     985Like \CC, D provides tuples through a library variadic-template structure.
     986Go does not have tuple but supports MRVF.
     987Java's variadic functions appears similar to C's but type-safe using arrays.
     988Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML~\cite{sml} and Scala~\cite{Scala}, which decompose tuples using pattern matching.
    968991\section{Conclusion \& Future Work}
Note: See TracChangeset for help on using the changeset viewer.