Changeset 2ca35b1


Ignore:
Timestamp:
Apr 17, 2017, 10:12:34 PM (4 years ago)
Author:
Aaron Moss <a3moss@…>
Branches:
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
Children:
036895e, d87ade9
Parents:
c13b2b8
Message:

Add Polymorphic C reference, fix some typos

Location:
doc
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • doc/bibliography/cfa.bib

    rc13b2b8 r2ca35b1  
    62216221}
    62226222
     6223@article{Smith98,
     6224  keywords = {Polymorphic C},
     6225  contributor = {a3moss@uwaterloo.ca},
     6226  title={A sound polymorphic type system for a dialect of C},
     6227  author={Smith, Geoffrey and Volpano, Dennis},
     6228  journal={Science of computer programming},
     6229  volume={32},
     6230  number={1-3},
     6231  pages={49--72},
     6232  year={1998},
     6233  publisher={Elsevier}
     6234}
     6235
    62236236@book{Campbell74,
    62246237    keywords    = {path expressions},
  • doc/generic_types/generic_types.tex

    rc13b2b8 r2ca35b1  
    10231023\section{Related Work}
    10241024
    1025 
    1026 \subsection{Polymorphism}
     1025% \subsection{Polymorphism}
    10271026
    10281027\CC is the most similar language to \CFA;
     
    10341033In contrast, \CFA has a single facility for polymorphic code supporting type-safe separate-compilation of polymorphic functions and generic (opaque) types, which uniformly leverage the C procedural paradigm.
    10351034The key mechanism to support separate compilation is \CFA's \emph{explicit} use of assumed properties for a type.
    1036 Until \CC~\citep{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way to specify the requirements of a generic function in code beyond compilation errors during template expansion;
     1035Until \CC~\citet{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way to specify the requirements of a generic function in code beyond compilation errors during template expansion;
    10371036furthermore, \CC concepts are restricted to template polymorphism.
    10381037
     
    10421041In \CFA terms, all Cyclone polymorphism must be dtype-static.
    10431042While the Cyclone design provides the efficiency benefits discussed in Section~\ref{sec:generic-apps} for dtype-static polymorphism, it is more restrictive than \CFA's general model.
     1043\citet{Smith98} present Polymorphic C, an ML dialect with polymorphic functions and C-like syntax and pointer types; it lacks many of C's features, however, most notably struct types, and so is not a practical C replacement.
    10441044
    10451045\citet{obj-c-book} is an industrially successful extension to C.
    10461046However, Objective-C is a radical departure from C, using an object-oriented model with message-passing.
    1047 Objective-C did not support type-checked generics until recently~\citet{xcode7}, historically using less-efficient and more error-prone runtime checking of object types.
     1047Objective-C did not support type-checked generics until recently \citep{xcode7}, historically using less-efficient runtime checking of object types.
    10481048The~\citet{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage-collection to C;
    10491049these features are more intrusive additions than those provided by \CFA, in addition to the runtime overhead of reference-counting.
    1050 \citet{Vala} compiles to GObject-based C, and so adds the burden of learning a separate language syntax to the aforementioned demerits of GObject as a modernization path for the existing C code-bases.
    1051 Java~\citep{Java8} included generic types in Java~5;
    1052 Java's generic types are type-checked at compilation and type-erased at runtime, similar to \CFA's.
     1050\citet{Vala} compiles to GObject-based C, adding the burden of learning a separate language syntax to the aforementioned demerits of GObject as a modernization path for existing C code-bases.
     1051Java~\citep{Java8} included generic types in Java~5 which are type-checked at compilation and type-erased at runtime, similar to \CFA's.
    10531052However, in Java, each object carries its own table of method pointers, while \CFA passes the method pointers separately to maintain a C-compatible layout.
    10541053Java is also a garbage-collected, object-oriented language, with the associated resource usage and C-interoperability burdens.
     
    10641063\CFA, with its more modest safety features, allows direct ports of C code while maintaining the idiomatic style of the original source.
    10651064
    1066 
    1067 \subsection{Tuples/Variadics}
     1065% \subsection{Tuples/Variadics}
    10681066
    10691067Many programming languages have some form of tuple construct and/or variadic functions, \eg SETL, C, KW-C, \CC, D, Go, Java, ML, and Scala.
     
    10981096
    10991097There is ongoing work on a wide range of \CFA feature extensions, including reference types, exceptions, concurrent primitives and modules.
    1100 (While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these addition extensions.)
     1098(While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these additional extensions.)
    11011099In addition, there are interesting future directions for the polymorphism design.
    11021100Notably, \CC template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions.
    1103 \CFA polymorphic functions uses a dynamic virtual-dispatch.
    1104 The runtime overhead of this approach is low, but not as low as inlining, and it may be beneficial to provide a mechanism for performance-sensitive code.
     1101\CFA polymorphic functions use dynamic virtual-dispatch;
     1102the runtime overhead of this approach is low, but not as low as inlining, and it may be beneficial to provide a mechanism for performance-sensitive code.
    11051103Two promising approaches are an @inline@ annotation at polymorphic function call sites to create a template-specialization of the function (provided the code is visible) or placing an @inline@ annotation on polymorphic function-definitions to instantiate a specialized version for some set of types.
    11061104These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code-bloat.
Note: See TracChangeset for help on using the changeset viewer.