# Changeset 3ce0c915

Ignore:
Timestamp:
Feb 2, 2018, 4:00:09 PM (4 years ago)
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
d03fa6d
Parents:
11b7028 (diff), d7d4702 (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.
Message:

Merge branch 'master' of plg.uwaterloo.ca:/u/cforall/software/cfa/cfa-cc

Files:
11 edited

Unmodified
Removed

• ## doc/papers/general/Paper.tex

 r11b7028 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects. This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more. The \cite{TIOBE} ranks the top 5 most popular programming languages as: Java 16\%, \Textbf{C 7\%}, \Textbf{\CC 5\%}, \Csharp 4\%, Python 4\% = 36\%, where the next 50 languages are less than 3\% each with a long tail. The TIOBE\cite{TIOBE} ranks the top 5 most popular programming languages as: Java 16\%, \Textbf{C 7\%}, \Textbf{\CC 5\%}, \Csharp 4\%, Python 4\% = 36\%, where the next 50 languages are less than 3\% each with a long tail. The top 3 rankings over the past 30 years are: \lstDeleteShortInline@% \label{sec:poly-fns} \CFA{}\hspace{1pt}'s polymorphism was originally formalized by \cite{Ditchfield92}, and first implemented by \cite{Bilson03}. \CFA{}\hspace{1pt}'s polymorphism was originally formalized by Ditchfield\cite{Ditchfield92}, and first implemented by Bilson\cite{Bilson03}. The signature feature of \CFA is parametric-polymorphic functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a @forall@ clause (giving the language its name): \begin{lstlisting} } \end{lstlisting} Within the block, the nested version of @<@ performs @>@ and this local version overrides the built-in @<@ so it is passed to @qsort@. Within the block, the nested version of @??@ and this local version overrides the built-in @?0 = 5;                                                                     $\C{// change quotient}$ bar( qr.1, qr );                                                      $\C{// pass remainder and quotient/remainder}$ rem = [42, div( 13, 5 )].0.1;                         $\C{// access 2nd component of 1st component of tuple expression}$ rem = [div( 13, 5 ), 42].0.1;                         $\C{// access 2nd component of 1st component of tuple expression}$ \end{lstlisting} \end{lstlisting} Hence, function parameter and return lists are flattened for the purposes of type unification allowing the example to pass expression resolution. This relaxation is possible by extending the thunk scheme described by~\cite{Bilson03}. This relaxation is possible by extending the thunk scheme described by Bilson\cite{Bilson03}. Whenever a candidate's parameter structure does not exactly match the formal parameter's structure, a thunk is generated to specialize calls to the actual function: \begin{lstlisting} \end{comment} \section{Improved Procedural Paradigm} It is important to the design team that \CFA subjectively `feel like'' C to user programmers. An important part of this subjective feel is maintaining C's procedural programming paradigm, as opposed to the object-oriented paradigm of other systems languages such as \CC and Rust. Maintaining this procedural paradigm means that coding patterns that work in C will remain not only functional but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development. Nonetheless, some features of object-oriented languages are undeniably convienient, and the \CFA design team has attempted to adapt them to a procedural paradigm so as to incorporate their benefits into \CFA; two of these features are resource management and name scoping. \subsection{Constructors and Destructors} One of the strengths of C is the control over memory management it gives programmers, allowing resource release to be more consistent and precisely timed than is possible with garbage-collected memory management. However, this manual approach to memory management is often verbose, and it is useful to manage resources other than memory (\eg file handles) using the same mechanism as memory. \CC is well-known for an approach to manual memory management that addresses both these issues, Resource Allocation Is Initialization (RAII), implemented by means of special \emph{constructor} and \emph{destructor} functions; we have implemented a similar feature in \CFA. \TODO{Fill out section. Mention field-constructors and at-equal escape hatch to C-style initialization. Probably pull some text from Rob's thesis for first draft.} \subsection{with Statement} In any programming language, some functions have a naturally close relationship with a particular data type. Object-oriented programming allows this close relationship to be codified in the language by making such functions \emph{class methods} of their related data type. Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type. When writing C functions in an object-oriented style, this un-prefixed access is swiftly missed, as access to fields of a @Foo* f@ requires an extra three characters @f->@ every time, which disrupts coding flow and clutters the produced code. \TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.} \section{References} \TODO{Pull draft text from user manual; make sure to discuss nested references and rebind operator drawn from lvalue-addressof operator} \section{Evaluation} In 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. The key mechanism to support separate compilation is \CFA's \emph{explicit} use of assumed properties for a type. Until \CC~\cite{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; Until \CC concepts~\cite{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; furthermore, \CC concepts are restricted to template polymorphism. In \CFA terms, all Cyclone polymorphism must be dtype-static. While 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. \cite{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 structure types, and so is not a practical C replacement. \cite{obj-c-book} is an industrially successful extension to C. Smith and Volpano~\cite{Smith98} present Polymorphic C, an ML dialect with polymorphic functions, C-like syntax, and pointer types; it lacks many of C's features, however, most notably structure types, and so is not a practical C replacement. Objective-C~\cite{obj-c-book} is an industrially successful extension to C. However, Objective-C is a radical departure from C, using an object-oriented model with message-passing. Objective-C did not support type-checked generics until recently \cite{xcode7}, historically using less-efficient runtime checking of object types. The~\cite{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage-collection to C; The GObject~\cite{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage-collection to C; these features are more intrusive additions than those provided by \CFA, in addition to the runtime overhead of reference-counting. \cite{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. Vala~\cite{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. Java~\cite{Java8} included generic types in Java~5, which are type-checked at compilation and type-erased at runtime, similar to \CFA's. However, in Java, each object carries its own table of method pointers, while \CFA passes the method pointers separately to maintain a C-compatible layout. Java is also a garbage-collected, object-oriented language, with the associated resource usage and C-interoperability burdens. D~\cite{D}, Go, and~\cite{Rust} are modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in D and Go and \emph{traits} in Rust. D~\cite{D}, Go, and Rust~\cite{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 a significant departure 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. \CCeleven introduced @std::tuple@ as a library variadic template structure. Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values. Operations include @std::get@ to extract vales, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons. Operations include @std::get@ to extract values, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons. \CCseventeen proposes \emph{structured bindings}~\cite{Sutter15} to eliminate pre-declaring variables and use of @std::tie@ for binding the results. 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. The goal of \CFA is to provide an evolutionary pathway for large C development-environments to be more productive and safer, while respecting the talent and skill of C programmers. While other programming languages purport to be a better C, they are in fact new and interesting languages in their own right, but not C extensions. The purpose of this paper is to introduce \CFA, and showcase two language features that illustrate the \CFA type-system and approaches taken to achieve the goal of evolutionary C extension. The purpose of this paper is to introduce \CFA, and showcase language features that illustrate the \CFA type-system and approaches taken to achieve the goal of evolutionary C extension. The contributions are a powerful type-system using parametric polymorphism and overloading, generic types, and tuples, which all have complex interactions. The work is a challenging design, engineering, and implementation exercise.
• ## doc/theses/thierry_delisle/Makefile

 r11b7028 fig2dev -L pstex_t -p ${Build}/$@ $< >${Build}/$@_t %.tex: %.pstex #----------------------------------------------------------------------------------- # Tools to generate png files # to create a png we create a pdf and convert it to png %.png : build/%.pstex figures/%.tex echo${basename $@}${LaTeX} figures/${basename$@}.tex dvips build/${basename$@}.dvi -o build/${basename$@}.ps ps2pdf build/${basename$@}.ps convert -negate ${basename$@}.pdf $@ # creating a pdf of a figure requires generating some latex that just includes the figure figures/%.tex: build/%.pstex echo -n "\documentclass[preview]{standalone}\n" \ "\usepackage[T1]{fontenc}\n" \ "\end{document}" >$@ %.png : %.pstex %.tex echo ${basename$@} ${LaTeX} figures/${basename $@}.tex dvips build/${basename $@}.dvi -o build/${basename $@}.ps ps2pdf build/${basename $@}.ps convert -negate${basename $@}.pdf$@ # Local Variables: # # compile-command: "make" #

• ## src/driver/cfa.cc

 r11b7028 // Created On       : Tue Aug 20 13:44:49 2002 // Last Modified By : Peter A. Buhr // Last Modified On : Tue Jan 30 15:46:15 2018 // Update Count     : 161 // Last Modified On : Thu Feb  1 22:26:10 2018 // Update Count     : 163 // args[nargs] = "-D__int8_t_defined";                             // prevent gcc type-size attributes nargs += 1; args[nargs] = "-D__NO_STRING_INLINES";                  // prevent gcc strcmp unrolling nargs += 1; args[nargs] = ( *new string( string("-B") + Bprefix + "/" ) ).c_str(); nargs += 1;