- Timestamp:
- Apr 13, 2017, 4:54:42 PM (7 years ago)
- 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:
- 0111dc7
- Parents:
- 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. - Location:
- doc
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/bibliography/cfa.bib
rcceab8a rc87eb50 5892 5892 keywords = {Scala programming language}, 5893 5893 contributer = {pabuhr@plg}, 5894 author = {{Scala}}, 5894 5895 title = {{Scala} Language Specification, Version 2.11}, 5895 5896 organization= {\'{E}cole Polytechnique F\'{e}d\'{e}rale de Lausanne}, … … 6309 6310 number = 5, 6310 6311 pages = {341-346} 6312 } 6313 6314 @article{Sutter15, 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://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf}{http://\-www.open-std.org/\-jtc1/\-sc22/\-wg21/\-docs/\-papers/\-2015/\-p0144r0.pdf}}, 6311 6324 } 6312 6325 -
doc/generic_types/generic_types.tex
rcceab8a rc87eb50 958 958 \section{Related Work} 959 959 960 961 \subsection{Generics} 962 960 963 \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. 961 964 … … 965 968 966 969 D \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. 970 971 972 \subsection{Tuples/Variadics} 973 974 Many programming languages have some form of tuple construct and/or variadic functions, \eg SETL, C, KW-C, \CC, D, Go, Java, ML, and Scala. 975 SETL~\cite{SETL} is a high-level mathematical programming language, with tuples being one of the primary data types. 976 Tuples in SETL allow subscripting, dynamic expansion, and multiple assignment. 977 KW-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. 978 The 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. 980 Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values. 981 Operations 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. 983 This 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. 984 Furthermore, structured bindings are not a full replacement for @std::tie@, as it always declares new variables. 985 Like \CC, D provides tuples through a library variadic-template structure. 986 Go does not have tuple but supports MRVF. 987 Java's variadic functions appears similar to C's but type-safe using arrays. 988 Tuples 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. 989 967 990 968 991 \section{Conclusion \& Future Work}
Note: See TracChangeset
for help on using the changeset viewer.