Changeset ad4d035

Apr 13, 2017, 1:20:08 PM (7 years ago)
Peter A. Buhr <pabuhr@…>
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

first dfrat of tuple/variadic related work

2 edited


  • doc/bibliography/cfa.bib

    r5103d7a rad4d035  
    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

    r5103d7a rad4d035  
    934934\section{Related Work}
    936939\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.
    942945D \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.
     950Many programming languages have some form of tuple construct and/or variadic functions, \eg SETL, C, KW-C, \CC, D, Go, Java, ML, and Scala.
     951SETL~\cite{SETL} is a high-level mathematical programming language, with tuples being one of the primary data types.
     952Tuples in SETL allow subscripting, dynamic expansion, and multiple assignment.
     953KW-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.
     954The main contributions of that work were adding MRVF, tuple mass and multiple assignment, and record-field access.
     955\CCeleven introduced @std::tuple@ as a library variadic template structure.
     956Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values.
     957Operations include @std::get<N>@ to extract vales, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons.
     958\CCseventeen proposes \emph{structured bindings}~\cite{Sutter15} to eliminate pre-declaring variables and use of @std::tie@ for binding the results.
     959This 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.
     960Furthermore, structured bindings are not a full replacement for @std::tie@, as it always declares new variables.
     961Like \CC, D provides tuples through a library variadic-template structure.
     962Go does not have tuple but supports MRVF.
     963Java's variadic functions appears similar to C's but type-safe using arrays.
     964Tuples 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.
    944967\section{Conclusion \& Future Work}
Note: See TracChangeset for help on using the changeset viewer.