- Timestamp:
- Aug 10, 2018, 8:41:42 AM (6 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, no_list, persistent-indexer, pthread-emulation, qualifiedEnum
- Children:
- bd56b07
- Parents:
- 581743f
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/papers/general/Paper.tex
r581743f rd16f9fd 1 1 \documentclass[AMA,STIX1COL]{WileyNJD-v2} 2 \setlength\typewidth{170mm} 3 \setlength\textwidth{170mm} 2 4 3 5 \articletype{RESEARCH ARTICLE}% 4 6 5 \received{26 April 2016} 6 \revised{6 June 2016} 7 \accepted{6 June 2016} 8 7 \received{12 March 2018} 8 \revised{8 May 2018} 9 \accepted{28 June 2018} 10 11 \setlength\typewidth{168mm} 12 \setlength\textwidth{168mm} 9 13 \raggedbottom 10 14 … … 187 191 } 188 192 189 \title{\texorpdfstring{\protect\CFA : Adding Modern Programming Language Features to C}{Cforall : Adding Modern Programming Language Features to C}}193 \title{\texorpdfstring{\protect\CFA : Adding modern programming language features to C}{Cforall : Adding modern programming language features to C}} 190 194 191 195 \author[1]{Aaron Moss} 192 196 \author[1]{Robert Schluntz} 193 \author[1]{Peter A. Buhr*} 197 \author[1]{Peter A. Buhr} 198 \author[]{\textcolor{blue}{Q1 AUTHOR NAMES CORRECT}} 194 199 \authormark{MOSS \textsc{et al}} 195 200 196 \address[1]{\orgdiv{Cheriton School of Computer Science}, \orgname{University of Waterloo}, \orgaddress{\state{Waterloo, O N}, \country{Canada}}}197 198 \corres{ *Peter A. Buhr, Cheriton School of Computer Science, University of Waterloo, 200 University Avenue West, Waterloo, ON,N2L 3G1, Canada. \email{pabuhr{\char`\@}uwaterloo.ca}}201 \address[1]{\orgdiv{Cheriton School of Computer Science}, \orgname{University of Waterloo}, \orgaddress{\state{Waterloo, Ontario}, \country{Canada}}} 202 203 \corres{Peter A. Buhr, Cheriton School of Computer Science, University of Waterloo, 200 University Avenue West, Waterloo, ON N2L 3G1, Canada. \email{pabuhr{\char`\@}uwaterloo.ca}} 199 204 200 205 \fundingInfo{Natural Sciences and Engineering Research Council of Canada} 201 206 202 207 \abstract[Summary]{ 203 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems. 204 This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more. 205 Nevertheless, C, first standardized almost thirty years ago, lacks many features that make programming in more modern languages safer and more productive. 206 207 The goal of the \CFA project (pronounced ``C-for-all'') is to create an extension of C that provides modern safety and productivity features while still ensuring strong backwards compatibility with C and its programmers. 208 Prior projects have attempted similar goals but failed to honour C programming-style; 209 for instance, adding object-oriented or functional programming with garbage collection is a non-starter for many C developers. 210 Specifically, \CFA is designed to have an orthogonal feature-set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code-bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and programmers. 211 This paper presents a quick tour of \CFA features showing how their design avoids shortcomings of similar features in C and other C-like languages. 208 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating systems. 209 This installation base and the programmers producing it represent a massive software engineering investment spanning decades and likely to continue for decades more. 210 Nevertheless, C, which was first standardized almost 30 \textcolor{blue}{CHANGE ``40'' TO ``30''} years ago, lacks many features that make programming in more modern languages safer and more productive. 211 The goal of the \CFA project (pronounced ``C for all'') is to create an extension of C that provides modern safety and productivity features while still ensuring strong backward compatibility with C and its programmers. 212 Prior projects have attempted similar goals but failed to honor the C programming style; 213 for instance, adding object-oriented or functional programming with garbage collection is a nonstarter for many C developers. 214 Specifically, \CFA is designed to have an orthogonal feature set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and programmers. 215 This paper presents a quick tour of \CFA features, showing how their design avoids shortcomings of similar features in C and other C-like languages. 212 216 Experimental results are presented to validate several of the new features. 213 217 }% 214 218 215 \keywords{ generic types, tuple types, variadic types, polymorphic functions, C, Cforall}219 \keywords{C, Cforall, generic types, polymorphic functions, tuple types, variadic types} 216 220 217 221 218 222 \begin{document} 219 \linenumbers % comment out to turn off line numbering223 %\linenumbers % comment out to turn off line numbering 220 224 221 225 \maketitle … … 224 228 \section{Introduction} 225 229 226 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems. 227 This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more. 228 The TIOBE index~\cite{TIOBE} ranks the top 5 most \emph{popular} programming languages as: Java 15\%, \Textbf{C 12\%}, \Textbf{\CC 5.5\%}, Python 5\%, \Csharp 4.5\% = 42\%, where the next 50 languages are less than 4\% each, with a long tail. 229 The top 3 rankings over the past 30 years are: 230 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating systems. 231 This installation base and the programmers producing it represent a massive software engineering investment spanning decades and likely to continue for decades more. 232 The TIOBE index~\cite{TIOBE} \textcolor{blue}{CHANGE ``TIOBE'' TO ``The TIOBE index''} ranks the top five most \emph{popular} programming languages as Java 15\%, \Textbf{C 12\%}, \Textbf{\CC 5.5\%}, and Python 5\%, \Csharp 4.5\% = 42\%, where the next 50 languages are less than 4\% each with a long tail. 233 The top three rankings over the past 30 years are as follows. 234 \newpage 235 \textcolor{blue}{MOVE TABLE HERE} 230 236 \begin{center} 231 237 \setlength{\tabcolsep}{10pt} 232 \lstDeleteShortInline@% 233 \begin{tabular}{@{}rccccccc@{}} 234 & 2018 & 2013 & 2008 & 2003 & 1998 & 1993 & 1988 \\ \hline 235 Java & 1 & 2 & 1 & 1 & 18 & - & - \\ 238 \fontsize{9bp}{11bp}\selectfont 239 \lstDeleteShortInline@% 240 \begin{tabular}{@{}cccccccc@{}} 241 & 2018 & 2013 & 2008 & 2003 & 1998 & 1993 & 1988 \\ 242 Java & 1 & 2 & 1 & 1 & 18 & -- & -- \\ 236 243 \Textbf{C}& \Textbf{2} & \Textbf{1} & \Textbf{2} & \Textbf{2} & \Textbf{1} & \Textbf{1} & \Textbf{1} \\ 237 244 \CC & 3 & 4 & 3 & 3 & 2 & 2 & 5 \\ … … 239 246 \lstMakeShortInline@% 240 247 \end{center} 248 241 249 Love it or hate it, C is extremely popular, highly used, and one of the few systems languages. 242 250 In many cases, \CC is often used solely as a better C. 243 Nevertheless, C, first standardized almost fortyyears ago~\cite{ANSI89:C}, lacks many features that make programming in more modern languages safer and more productive.244 245 \CFA (pronounced ``C -for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that adds modern language-features to C, while maintaining source and runtime compatibility in the familiar C programming model.246 The four key design goals for \CFA~\cite{Bilson03} are :247 (1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;248 (2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler;249 (3) \CFA code must be at least as portable as standard C code;250 (4) Extensions introduced by \CFA must be translated in the most efficient way possible.251 These goals ensure existing C code-bases can be convertedto \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used.252 \CC is used similarly , but has the disadvantages of multiple legacy design-choices that cannot be updated,and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.253 254 All language sfeatures discussed in this paper are working, except some advanced exception-handling features.255 Not discussed in this paper are the integrated concurrency -constructs and user-level threading-library~\cite{Delisle18}.251 Nevertheless, C, which was first standardized almost 30 \textcolor{blue}{CHANGE ``40'' TO ``30''} years ago~\cite{ANSI89:C}, lacks many features that make programming in more modern languages safer and more productive. 252 253 \CFA (pronounced ``C for all'' and written \CFA or Cforall) is an evolutionary extension of the C programming language that adds modern language features to C, while maintaining source and runtime compatibility in the familiar C programming model. 254 The four key design goals for \CFA~\cite{Bilson03} are as follows: 255 (1) the behavior of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler; 256 (2) the standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler; 257 (3) the \CFA code must be at least as portable as standard C code; 258 (4) extensions introduced by \CFA must be translated in the most efficient way possible. 259 These goals ensure that the existing C code bases can be converted into \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used. 260 \CC is used similarly but has the disadvantages of multiple legacy design choices that cannot be updated and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project. 261 262 All language features discussed in this paper are working, except some advanced exception-handling features. 263 Not discussed in this paper are the integrated concurrency constructs and user-level threading library~\cite{Delisle18}. 256 264 \CFA is an \emph{open-source} project implemented as a source-to-source translator from \CFA to the gcc-dialect of C~\cite{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3). 257 265 % @plg2[9]% cd cfa-cc/src; cloc ArgTweak CodeGen CodeTools Common Concurrency ControlStruct Designators GenPoly InitTweak MakeLibCfa.cc MakeLibCfa.h Parser ResolvExpr SymTab SynTree Tuples driver prelude main.cc … … 269 277 % SUM: 223 8203 8263 46479 270 278 % ------------------------------------------------------------------------------- 271 The \CFA translator is 200+ files and 46 ,000+ lines of code written in C/\CC.272 A translator versus a compiler makes it easier and faster to generate and debug C object-code rather than intermediate, assembleror machine code;279 The \CFA translator is 200+ files and 46\,000+ lines of code written in C/\CC. 280 A translator versus a compiler makes it easier and faster to generate and debug the C object code rather than the intermediate, assembler, or machine code; 273 281 ultimately, a compiler is necessary for advanced features and optimal performance. 274 282 % The translator design is based on the \emph{visitor pattern}, allowing multiple passes over the abstract code-tree, which works well for incrementally adding new feature through additional visitor passes. 275 283 Two key translator components are expression analysis, determining expression validity and what operations are required for its implementation, and code generation, dealing with multiple forms of overloading, polymorphism, and multiple return values by converting them into C code for a C compiler that supports none of these features. 276 Details of these components are available in Bilson~\cite{Bilson03} Chapters 2 and 3,and form the base for the current \CFA translator.284 Details of these components are available in chapters 2 and 3 in the work of Bilson~\cite{Bilson03} and form the base for the current \CFA translator. 277 285 % @plg2[8]% cd cfa-cc/src; cloc libcfa 278 286 % ------------------------------------------------------------------------------- … … 289 297 % SUM: 100 1895 2785 11763 290 298 % ------------------------------------------------------------------------------- 291 The \CFA runtime system is 100+ files and 11 ,000+ lines of code, written in \CFA.299 The \CFA runtime system is 100+ files and 11\,000+ lines of code, written in \CFA. 292 300 Currently, the \CFA runtime is the largest \emph{user} of \CFA providing a vehicle to test the language features and implementation. 293 301 % @plg2[6]% cd cfa-cc/src; cloc tests examples benchmark … … 316 324 317 325 326 \vspace*{-6pt} 318 327 \section{Polymorphic Functions} 319 328 320 \CFA introduces both ad -hoc and parametric polymorphism to C, with a design originally formalized by Ditchfield~\cite{Ditchfield92},and first implemented by Bilson~\cite{Bilson03}.321 Shortcomings are identified in existing approaches to generic and variadic data types in C-like languages and how these shortcomings are avoided in \CFA.322 Specifically, the solution is both reusable and type -checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions.329 \CFA introduces both ad hoc and parametric polymorphism to C, with a design originally formalized by Ditchfield~\cite{Ditchfield92} and first implemented by Bilson~\cite{Bilson03}. 330 Shortcomings are identified in the existing approaches to generic and variadic data types in C-like languages and how these shortcomings are avoided in \CFA. 331 Specifically, the solution is both reusable and type checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions. 323 332 The new constructs are empirically compared with C and \CC approaches via performance experiments in Section~\ref{sec:eval}. 324 333 325 334 326 \subsection{Name Overloading} 335 \vspace*{-6pt} 336 \subsection{Name overloading} 327 337 \label{s:NameOverloading} 328 338 329 339 \begin{quote} 330 There are only two hard things in Computer Science: cache invalidation and \emph{naming things} --Phil Karlton340 ``There are only two hard things in Computer Science: cache invalidation and \emph{naming things}.''---Phil Karlton 331 341 \end{quote} 332 342 \vspace{-9pt} 333 C already has a limited form of ad -hoc polymorphism in its basic arithmetic operators, which apply to a variety of different types using identical syntax.343 C already has a limited form of ad hoc polymorphism in its basic arithmetic operators, which apply to a variety of different types using identical syntax. 334 344 \CFA extends the built-in operator overloading by allowing users to define overloads for any function, not just operators, and even any variable; 335 345 Section~\ref{sec:libraries} includes a number of examples of how this overloading simplifies \CFA programming relative to C. 336 346 Code generation for these overloaded functions and variables is implemented by the usual approach of mangling the identifier names to include a representation of their type, while \CFA decides which overload to apply based on the same ``usual arithmetic conversions'' used in C to disambiguate operator overloads. 337 As an example: 347 \textcolor{blue}{REMOVE ``We have the following as an example''} 348 \newpage 349 \textcolor{blue}{UPDATE FOLLOWING PROGRAM EXAMPLE WITH ADJUSTED COMMENTS TO FIT PAGE WIDTH.} 338 350 \begin{cfa} 339 351 int max = 2147483647; $\C[4in]{// (1)}$ … … 341 353 int max( int a, int b ) { return a < b ? b : a; } $\C{// (3)}$ 342 354 double max( double a, double b ) { return a < b ? b : a; } $\C{// (4)}\CRT$ 343 max( 7, -max ); $\C {// uses (3) and (1), by matching int from constant 7}$355 max( 7, -max ); $\C[3in]{// uses (3) and (1), by matching int from constant 7}$ 344 356 max( max, 3.14 ); $\C{// uses (4) and (2), by matching double from constant 3.14}$ 345 357 max( max, -max ); $\C{// ERROR, ambiguous}$ 346 int m = max( max, -max ); $\C{// uses (3) and (1) twice, by matching return type} $358 int m = max( max, -max ); $\C{// uses (3) and (1) twice, by matching return type}\CRT$ 347 359 \end{cfa} 348 360 … … 353 365 As is shown later, there are a number of situations where \CFA takes advantage of available type information to disambiguate, where other programming languages generate ambiguities. 354 366 355 \Celeven added @_Generic@ expressions ~\cite[\S~6.5.1.1]{C11}, which is used with preprocessor macros to provide ad-hoc polymorphism;367 \Celeven added @_Generic@ expressions (see section~6.5.1.1 of the ISO/IEC 9899~\cite{C11}), which is used with preprocessor macros to provide ad hoc polymorphism; 356 368 however, this polymorphism is both functionally and ergonomically inferior to \CFA name overloading. 357 The macro wrapping the generic expression imposes some limitations; 358 \eg, it cannot implement the example above, because the variables @max@ are ambiguous with the functions @max@. 369 The macro wrapping the generic expression imposes some limitations, for instance, it cannot implement the example above, because the variables @max@ are ambiguous with the functions @max@. 359 370 Ergonomic limitations of @_Generic@ include the necessity to put a fixed list of supported types in a single place and manually dispatch to appropriate overloads, as well as possible namespace pollution from the dispatch functions, which must all have distinct names. 360 \CFA supports @_Generic@ expressions for backward s compatibility, but it is an unnecessary mechanism. \TODO{actually implement that}371 \CFA supports @_Generic@ expressions for backward compatibility, but it is an unnecessary mechanism. 361 372 362 373 % http://fanf.livejournal.com/144696.html … … 365 376 366 377 367 \subsection{\texorpdfstring{\protect\lstinline{forall} Functions}{forall Functions}} 378 \vspace*{-10pt} 379 \subsection{\texorpdfstring{\protect\lstinline{forall} functions}{forall functions}} 368 380 \label{sec:poly-fns} 369 381 370 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) :382 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). \textcolor{blue}{REMOVE ``as follows''} 371 383 \begin{cfa} 372 384 `forall( otype T )` T identity( T val ) { return val; } … … 375 387 This @identity@ function can be applied to any complete \newterm{object type} (or @otype@). 376 388 The type variable @T@ is transformed into a set of additional implicit parameters encoding sufficient information about @T@ to create and return a variable of that type. 377 The \CFA implementation passes the size and alignment of the type represented by an @otype@ parameter, as well as an assignment operator, constructor, copy constructor and destructor.378 If this extra information is not needed, \egfor a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@).379 380 In \CFA, the polymorphic runtime -cost is spread over each polymorphic call, because more arguments are passed to polymorphic functions;381 the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual -function calls.382 A design advantage is that, unlike \CC template -functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat.383 384 Since bare polymorphic -types provide a restricted set of available operations, \CFA provides a \newterm{type assertion}~\cite[pp.~37-44]{Alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable.385 For example, the function @twice@ can be defined using the \CFA syntax for operator overloading :389 The \CFA implementation passes the size and alignment of the type represented by an @otype@ parameter, as well as an assignment operator, constructor, copy constructor, and destructor. 390 If this extra information is not needed, for instance, for a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@). 391 392 In \CFA, the polymorphic runtime cost is spread over each polymorphic call, because more arguments are passed to polymorphic functions; 393 the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual function calls. 394 A design advantage is that, unlike \CC template functions, \CFA polymorphic functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat. 395 396 Since bare polymorphic types provide a restricted set of available operations, \CFA provides a \newterm{type assertion}~\cite[pp.~37-44]{Alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type variable. 397 For example, the function @twice@ can be defined using the \CFA syntax for operator overloading. \textcolor{blue}{REMOVE ``as follows''} 386 398 \begin{cfa} 387 399 forall( otype T `| { T ?+?(T, T); }` ) T twice( T x ) { return x `+` x; } $\C{// ? denotes operands}$ 388 400 int val = twice( twice( 3.7 ) ); $\C{// val == 14}$ 389 401 \end{cfa} 390 which works for any type @T@ with a matching addition operator. 391 The polymorphism is achieved by creating a wrapper function for calling @+@ with @T@ bound to @double@, then passing this function to the first call of @twice@. 392 There is now the option of using the same @twice@ and converting the result to @int@ on assignment, or creating another @twice@ with type parameter @T@ bound to @int@ because \CFA uses the return type~\cite{Cormack81,Baker82,Ada} in its type analysis. 393 The first approach has a late conversion from @double@ to @int@ on the final assignment, while the second has an early conversion to @int@. 394 \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition. 402 This works for any type @T@ with a matching addition operator. 403 The polymorphism is achieved by creating a wrapper function for calling @+@ with the @T@ bound to @double@ and then passing this function to the first call of @twice@. 404 There is now the option of using the same @twice@ and converting the result into @int@ on assignment or creating another @twice@ with the type parameter @T@ bound to @int@ because \CFA uses the return type~\cite{Cormack81,Baker82,Ada} in its type analysis. 405 The first approach has a late conversion from @double@ to @int@ on the final assignment, whereas the second has an early conversion to @int@. 406 \CFA minimizes the number of conversions and their potential to lose information; 407 hence, it selects the first approach, which corresponds with C programmer intuition. 395 408 396 409 Crucial to the design of a new programming language are the libraries to access thousands of external software features. 397 Like \CC, \CFA inherits a massive compatible library -base, where other programming languages must rewrite or provide fragile inter-language communication with C.398 A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@ to binary search a sorted float array :410 Like \CC, \CFA inherits a massive compatible library base, where other programming languages must rewrite or provide fragile interlanguage communication with C. 411 A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@ to binary search a sorted float array. \textcolor{blue}{REMOVE ``as follows''} 399 412 \begin{cfa} 400 413 void * bsearch( const void * key, const void * base, size_t nmemb, size_t size, … … 406 419 double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp ); $\C{// search sorted array}$ 407 420 \end{cfa} 408 which can be augmented simply with generalized, type-safe, \CFA-overloaded wrappers: 421 This can be augmented simply with generalized, type-safe, \CFA-overloaded wrappers. 409 422 \begin{cfa} 410 423 forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) { … … 420 433 \end{cfa} 421 434 The nested function @comp@ provides the hidden interface from typed \CFA to untyped (@void *@) C, plus the cast of the result. 422 Providing a hidden @comp@ function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope. 423 As well, an alternate kind of return is made available: position versus pointer to found element. 424 \CC's type-system cannot disambiguate between the two versions of @bsearch@ because it does not use the return type in overload resolution, nor can \CC separately compile a template @bsearch@. 435 % FIX 436 Providing a hidden @comp@ function in \CC is awkward as lambdas do not use C calling conventions and template declarations cannot appear in block scope. 437 In addition, an alternate kind of return is made available: position versus pointer to found element. 438 \CC's type system cannot disambiguate between the two versions of @bsearch@ because it does not use the return type in overload resolution, nor can \CC separately compile a template @bsearch@. 425 439 426 440 \CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations (see Section~\ref{sec:libraries}). … … 432 446 \end{cfa} 433 447 434 Call -site inferencing and nested functions provide a localized form of inheritance.448 Call site inferencing and nested functions provide a localized form of inheritance. 435 449 For example, the \CFA @qsort@ only sorts in ascending order using @<@. 436 However, it is trivial to locally change this behavio ur:450 However, it is trivial to locally change this behavior. 437 451 \begin{cfa} 438 452 forall( otype T | { int ?<?( T, T ); } ) void qsort( const T * arr, size_t size ) { /* use C qsort */ } 439 453 int main() { 440 int ?<?( double x, double y ) { return x `>` y; } $\C{// locally override behavio ur}$454 int ?<?( double x, double y ) { return x `>` y; } $\C{// locally override behavior}$ 441 455 qsort( vals, 10 ); $\C{// descending sort}$ 442 456 } 443 457 \end{cfa} 444 458 The local version of @?<?@ performs @?>?@ overriding the built-in @?<?@ so it is passed to @qsort@. 445 Hence, programmers can easily form local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.446 447 To reduce duplication, it is possible to distribute a group of @forall@ (and storage-class qualifiers) over functions/types, s o each block declaration is prefixed by the group (see example in Appendix~\ref{s:CforallStack}).459 Therefore, programmers can easily form local environments, adding and modifying appropriate functions, to maximize the reuse of other existing functions and types. 460 461 To reduce duplication, it is possible to distribute a group of @forall@ (and storage-class qualifiers) over functions/types, such that each block declaration is prefixed by the group (see the example in Appendix~\ref{s:CforallStack}). 448 462 \begin{cfa} 449 463 forall( otype `T` ) { $\C{// distribution block, add forall qualifier to declarations}$ … … 456 470 457 471 458 \vspace*{-2pt}459 472 \subsection{Traits} 460 473 461 \CFA provides \newterm{traits} to name a group of type assertions, where the trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration: 462 474 \CFA provides \newterm{traits} to name a group of type assertions, where the trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration. 463 475 \begin{cquote} 464 476 \lstDeleteShortInline@% … … 487 499 \end{cquote} 488 500 489 Note ,the @sumable@ trait does not include a copy constructor needed for the right side of @?+=?@ and return;490 it is provided by @otype@, which is syntactic sugar for the following trait :501 Note that the @sumable@ trait does not include a copy constructor needed for the right side of @?+=?@ and return; 502 it is provided by @otype@, which is syntactic sugar for the following trait. 491 503 \begin{cfa} 492 504 trait otype( dtype T | sized(T) ) { // sized is a pseudo-trait for types with known size and alignment … … 497 509 }; 498 510 \end{cfa} 499 Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete type: stack -allocatable, default or copy-initialized, assigned, and deleted.500 501 In summation, the \CFA type -system uses \newterm{nominal typing} for concrete types, matching with the C type-system, and \newterm{structural typing} for polymorphic types.511 Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete type: stack allocatable, default or copy initialized, assigned, and deleted. 512 513 In summation, the \CFA type system uses \newterm{nominal typing} for concrete types, matching with the C type system, and \newterm{structural typing} for polymorphic types. 502 514 Hence, trait names play no part in type equivalence; 503 515 the names are simply macros for a list of polymorphic assertions, which are expanded at usage sites. 504 Nevertheless, trait names form a logical subtype -hierarchy with @dtype@ at the top, where traits often contain overlapping assertions, \eg operator @+@.505 Traits are used like interfaces in Java or abstract base -classes in \CC, but without the nominal inheritance-relationships.506 Instead, each polymorphic function (or generic type) defines the structural type needed for its execution (polymorphic type -key), and this key is fulfilled at each call site from the lexical environment, which is similar toGo~\cite{Go} interfaces.507 Hence, new lexical scopes and nested functions are used extensively to create local subtypes, as in the @qsort@ example, without having to manage a nominal -inheritance hierarchy.516 Nevertheless, trait names form a logical subtype hierarchy with @dtype@ at the top, where traits often contain overlapping assertions, \eg operator @+@. 517 Traits are used like interfaces in Java or abstract base classes in \CC, but without the nominal inheritance relationships. 518 Instead, each polymorphic function (or generic type) defines the structural type needed for its execution (polymorphic type key), and this key is fulfilled at each call site from the lexical environment, which is similar to the Go~\cite{Go} interfaces. 519 Hence, new lexical scopes and nested functions are used extensively to create local subtypes, as in the @qsort@ example, without having to manage a nominal inheritance hierarchy. 508 520 % (Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.) 509 521 … … 536 548 537 549 A significant shortcoming of standard C is the lack of reusable type-safe abstractions for generic data structures and algorithms. 538 Broadly speaking, there are three approaches to implement abstract data -structures in C.539 One approach is to write bespoke data -structures for each context in which they are needed.540 While this approach is flexible and supports integration with the C type -checker and tooling, it is also tedious and error-prone, especially for more complex data structures.541 A second approach is to use @void *@-based polymorphism, \eg the C standard -library functions @bsearch@ and @qsort@, which allowreuse of code with common functionality.542 However, basing all polymorphism on @void *@ eliminates the type -checker's ability to ensure that argument types are properly matched, often requiring a number of extra function parameters, pointer indirection, and dynamic allocation that is not otherwiseneeded.543 A third approach to generic code is to use preprocessor macros, which does allow the generated code to be both generic and type -checked, but errors may be difficult to interpret.550 Broadly speaking, there are three approaches to implement abstract data structures in C. 551 One approach is to write bespoke data structures for each context in which they are needed. 552 While this approach is flexible and supports integration with the C type checker and tooling, it is also tedious and error prone, especially for more complex data structures. 553 A second approach is to use @void *@-based polymorphism, \eg the C standard library functions @bsearch@ and @qsort@, which allow for the reuse of code with common functionality. 554 However, basing all polymorphism on @void *@ eliminates the type checker's ability to ensure that argument types are properly matched, often requiring a number of extra function parameters, pointer indirection, and dynamic allocation that is otherwise not needed. 555 A third approach to generic code is to use preprocessor macros, which does allow the generated code to be both generic and type checked, but errors may be difficult to interpret. 544 556 Furthermore, writing and using preprocessor macros is unnatural and inflexible. 545 557 546 \CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data -types.547 \CFA generic types integrate efficiently and naturally with the existing polymorphic functions, while retaining backward scompatibility with C and providing separate compilation.558 \CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data types. 559 \CFA generic types integrate efficiently and naturally with the existing polymorphic functions, while retaining backward compatibility with C and providing separate compilation. 548 560 However, for known concrete parameters, the generic-type definition can be inlined, like \CC templates. 549 561 550 A generic type can be declared by placing a @forall@ specifier on a @struct@ or @union@ declaration , and instantiated using a parenthesized list of types after the type name:562 A generic type can be declared by placing a @forall@ specifier on a @struct@ or @union@ declaration and instantiated using a parenthesized list of types after the type name. 551 563 \begin{cquote} 552 564 \lstDeleteShortInline@% … … 576 588 577 589 \CFA classifies generic types as either \newterm{concrete} or \newterm{dynamic}. 578 Concrete types have a fixed memory layout regardless of type parameters, wh iledynamic types vary in memory layout depending on their type parameters.590 Concrete types have a fixed memory layout regardless of type parameters, whereas dynamic types vary in memory layout depending on their type parameters. 579 591 A \newterm{dtype-static} type has polymorphic parameters but is still concrete. 580 592 Polymorphic pointers are an example of dtype-static types; 581 given some type variable @T@, @T@ is a polymorphic type, as is @T *@, but @T *@ has a fixed size and can thereforebe represented by @void *@ in code generation.582 583 \CFA generic types also allow checked argument -constraints.584 For example, the following declaration of a sorted set -type ensures the set key supports equality and relational comparison:593 given some type variable @T@, @T@ is a polymorphic type, as is @T *@, but @T *@ has a fixed size and can, therefore, be represented by @void *@ in code generation. 594 595 \CFA generic types also allow checked argument constraints. 596 For example, the following declaration of a sorted set type ensures the set key supports equality and relational comparison. 585 597 \begin{cfa} 586 598 forall( otype Key | { _Bool ?==?(Key, Key); _Bool ?<?(Key, Key); } ) struct sorted_set; … … 588 600 589 601 590 \subsection{Concrete Generic-Types}591 592 The \CFA translator template -expands concrete generic-types into new structure types, affording maximal inlining.593 To enable inter -operation among equivalent instantiations of a generic type, the translator saves the set of instantiations currently in scope and reuses the generated structure declarations where appropriate.594 A function declaration that accepts or returns a concrete generic -type produces a declaration for the instantiated structure in the same scope, which all callers may reuse.595 For example, the concrete instantiation for @pair( const char *, int )@ is :602 \subsection{Concrete generic types} 603 604 The \CFA translator template expands concrete generic types into new structure types, affording maximal inlining. 605 To enable interoperation among equivalent instantiations of a generic type, the translator saves the set of instantiations currently in scope and reuses the generated structure declarations where appropriate. 606 A function declaration that accepts or returns a concrete generic type produces a declaration for the instantiated structure in the same scope, which all callers may reuse. 607 For example, the concrete instantiation for @pair( const char *, int )@ is \textcolor{blue}{REMOVE ``as follows.''} 596 608 \begin{cfa} 597 609 struct _pair_conc0 { … … 600 612 \end{cfa} 601 613 602 A concrete generic -type with dtype-static parameters is also expanded to a structure type, but this type is used for all matching instantiations.603 In the above example, the @pair( F *, T * )@ parameter to @value@ is such a type; its expansion is below and it is used as the type of the variables @q@ and @r@ as well, with casts for member access where appropriate:614 A concrete generic type with dtype-static parameters is also expanded to a structure type, but this type is used for all matching instantiations. 615 In the above example, the @pair( F *, T * )@ parameter to @value@ is such a type; its expansion is below, and it is used as the type of the variables @q@ and @r@ as well, with casts for member access where appropriate. 604 616 \begin{cfa} 605 617 struct _pair_conc1 { … … 609 621 610 622 611 \subsection{Dynamic Generic-Types} 612 613 Though \CFA implements concrete generic-types efficiently, it also has a fully general system for dynamic generic types. 614 As mentioned in Section~\ref{sec:poly-fns}, @otype@ function parameters (in fact all @sized@ polymorphic parameters) come with implicit size and alignment parameters provided by the caller. 615 Dynamic generic-types also have an \newterm{offset array} containing structure-member offsets. 616 A dynamic generic-@union@ needs no such offset array, as all members are at offset 0, but size and alignment are still necessary. 617 Access to members of a dynamic structure is provided at runtime via base-displacement addressing with the structure pointer and the member offset (similar to the @offsetof@ macro), moving a compile-time offset calculation to runtime. 623 \subsection{Dynamic generic types} 624 625 Though \CFA implements concrete generic types efficiently, it also has a fully general system for dynamic generic types. 626 As mentioned in Section~\ref{sec:poly-fns}, @otype@ function parameters (in fact, all @sized@ polymorphic parameters) come with implicit size and alignment parameters provided by the caller. 627 Dynamic generic types also have an \newterm{offset array} containing structure-member offsets. 628 A dynamic generic @union@ needs no such offset array, as all members are at offset 0, but size and alignment are still necessary. 629 Access to members of a dynamic structure is provided at runtime via base displacement addressing 630 % FIX 631 using the structure pointer and the member offset (similar to the @offsetof@ macro), moving a compile-time offset calculation to runtime. 618 632 619 633 The offset arrays are statically generated where possible. 620 If a dynamic generic -type is declared to be passed or returned by value from a polymorphic function, the translator can safely assume the generic type is complete (\ie has a known layout) at any call-site, and the offset array is passed from the caller;634 If a dynamic generic type is declared to be passed or returned by value from a polymorphic function, the translator can safely assume that the generic type is complete (\ie has a known layout) at any call site, and the offset array is passed from the caller; 621 635 if the generic type is concrete at the call site, the elements of this offset array can even be statically generated using the C @offsetof@ macro. 622 As an example, the body of the second @value@ function is implemented as :636 As an example, the body of the second @value@ function is implemented as \textcolor{blue}{REMOVE ``follows.''} 623 637 \begin{cfa} 624 638 _assign_T( _retval, p + _offsetof_pair[1] ); $\C{// return *p.second}$ 625 639 \end{cfa} 626 @_assign_T@ is passed in as an implicit parameter from @otype T@, and takes two @T *@ (@void *@ in the generated code), a destination and a source; @_retval@ is the pointer to a caller-allocated buffer for the return value, the usual \CFA method to handle dynamically-sized return types. 627 @_offsetof_pair@ is the offset array passed into @value@; this array is generated at the call site as: 640 \newpage 641 \noindent 642 \textcolor{blue}{NO PARAGRAPH INDENT} Here, @_assign_T@ is passed in as an implicit parameter from @otype T@, and takes two @T *@ (@void *@ in the generated code), a destination and a source, and @_retval@ is the pointer to a caller-allocated buffer for the return value, the usual \CFA method to handle dynamically sized return types. 643 @_offsetof_pair@ is the offset array passed into @value@; 644 this array is generated at the call site as \textcolor{blue}{REMOVE ``follows.''} 628 645 \begin{cfa} 629 646 size_t _offsetof_pair[] = { offsetof( _pair_conc0, first ), offsetof( _pair_conc0, second ) } 630 647 \end{cfa} 631 648 632 In some cases the offset arrays cannot be statically generated.633 For instance, modularity is generally provided in C by including an opaque forward -declaration of a structure and associated accessor and mutator functions in a header file, with the actual implementations in a separately-compiled @.c@ file.634 \CFA supports this pattern for generic types, but the caller does not know the actual layout or size of the dynamic generic -type,and only holds it by a pointer.649 In some cases, the offset arrays cannot be statically generated. 650 For instance, modularity is generally provided in C by including an opaque forward declaration of a structure and associated accessor and mutator functions in a header file, with the actual implementations in a separately compiled @.c@ file. 651 \CFA supports this pattern for generic types, but the caller does not know the actual layout or size of the dynamic generic type and only holds it by a pointer. 635 652 The \CFA translator automatically generates \newterm{layout functions} for cases where the size, alignment, and offset array of a generic struct cannot be passed into a function from that function's caller. 636 653 These layout functions take as arguments pointers to size and alignment variables and a caller-allocated array of member offsets, as well as the size and alignment of all @sized@ parameters to the generic structure (un@sized@ parameters are forbidden from being used in a context that affects layout). … … 642 659 Whether a type is concrete, dtype-static, or dynamic is decided solely on the @forall@'s type parameters. 643 660 This design allows opaque forward declarations of generic types, \eg @forall(otype T)@ @struct Box@ -- like in C, all uses of @Box(T)@ can be separately compiled, and callers from other translation units know the proper calling conventions to use. 644 If the definition of a structure type is included in deciding whether a generic type is dynamic or concrete, some further types may be recognized as dtype-static (\eg @forall(otype T)@ @struct unique_ptr { T * p }@ does not depend on @T@ for its layout, but the existence of an @otype@ parameter means that it \emph{could}.), but preserving separate compilation (and the associated C compatibility) in the existing design is judged to be an appropriate trade-off. 661 If the definition of a structure type is included in deciding whether a generic type is dynamic or concrete, some further types may be recognized as dtype-static (\eg @forall(otype T)@ @struct unique_ptr { T * p }@ does not depend on @T@ for its layout, but the existence of an @otype@ parameter means that it \emph{could}.); 662 however, preserving separate compilation (and the associated C compatibility) in the existing design is judged to be an appropriate trade-off. 645 663 646 664 … … 655 673 } 656 674 \end{cfa} 657 Since @pair( T *, T * )@ is a concrete type, there are no implicit parameters passed to @lexcmp@, so the generated code is identical to a function written in standard C using @void *@, yet the \CFA version is type-checked to ensure the members of both pairs and the arguments to the comparison function match in type. 658 659 Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \newterm{tag-structures}. 660 Sometimes information is only used for type-checking and can be omitted at runtime, \eg: 675 Since @pair( T *, T * )@ is a concrete type, there are no implicit parameters passed to @lexcmp@; 676 hence, the generated code is identical to a function written in standard C using @void *@, yet the \CFA version is type checked to ensure members of both pairs and arguments to the comparison function match in type. 677 678 Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \newterm{tag structures}. 679 Sometimes, information is only used for type checking and can be omitted at runtime. \textcolor{blue}{REMOVE ``As an example, we have the following''} 661 680 \begin{cquote} 662 681 \lstDeleteShortInline@% … … 677 696 half_marathon; 678 697 scalar(litres) two_pools = pool + pool; 679 `marathon + pool;` 698 `marathon + pool;` // ERROR, mismatched types 680 699 \end{cfa} 681 700 \end{tabular} 682 701 \lstMakeShortInline@% 683 702 \end{cquote} 684 @scalar@ is a dtype-static type, so all uses have a single structure definition, containing @unsigned long@, and can share the same implementations of common functions like @?+?@. 703 Here, @scalar@ is a dtype-static type; 704 hence, all uses have a single structure definition, containing @unsigned long@, and can share the same implementations of common functions like @?+?@. 685 705 These implementations may even be separately compiled, unlike \CC template functions. 686 However, the \CFA type -checker ensures matching types are used by all calls to @?+?@, preventing nonsensical computations like adding a length to a volume.706 However, the \CFA type checker ensures matching types are used by all calls to @?+?@, preventing nonsensical computations like adding a length to a volume. 687 707 688 708 … … 690 710 \label{sec:tuples} 691 711 692 In many languages, functions can return at mostone value;712 In many languages, functions can return, at most, one value; 693 713 however, many operations have multiple outcomes, some exceptional. 694 714 Consider C's @div@ and @remquo@ functions, which return the quotient and remainder for a division of integer and float values, respectively. … … 701 721 double r = remquo( 13.5, 5.2, &q ); $\C{// return remainder, alias quotient}$ 702 722 \end{cfa} 703 @div@ aggregates the quotient/remainder in a structure, while@remquo@ aliases a parameter to an argument.723 Here, @div@ aggregates the quotient/remainder in a structure, whereas @remquo@ aliases a parameter to an argument. 704 724 Both approaches are awkward. 705 Alternatively, a programming language can directly support returning multiple values, \eg in \CFA: 725 % FIX 726 Alternatively, a programming language can directly support returning multiple values, \eg \CFA provides the following. \textcolor{blue}{REPLACE ``in \CFA, we have the following'' WITH ``\CFA provides the following''} 706 727 \begin{cfa} 707 728 [ int, int ] div( int num, int den ); $\C{// return two integers}$ … … 714 735 This approach is straightforward to understand and use; 715 736 therefore, why do few programming languages support this obvious feature or provide it awkwardly? 716 To answer, there are complex consequences that cascade through multiple aspects of the language, especially the type -system.717 This section show these consequences and how \CFA handles them.737 To answer, there are complex consequences that cascade through multiple aspects of the language, especially the type system. 738 This section shows these consequences and how \CFA handles them. 718 739 719 740 720 741 \subsection{Tuple Expressions} 721 742 722 The addition of multiple-return-value functions (MRVF ) are \emph{useless} without a syntax for accepting multiple values at the call-site.743 The addition of multiple-return-value functions (MRVFs) is \emph{useless} without a syntax for accepting multiple values at the call site. 723 744 The simplest mechanism for capturing the return values is variable assignment, allowing the values to be retrieved directly. 724 745 As such, \CFA allows assigning multiple values from a function into multiple variables, using a square-bracketed list of lvalue expressions (as above), called a \newterm{tuple}. 725 746 726 However, functions also use \newterm{composition} (nested calls), with the direct consequence that MRVFs must also support composition to be orthogonal with single-returning-value functions (SRVF ), \eg:747 However, functions also use \newterm{composition} (nested calls), with the direct consequence that MRVFs must also support composition to be orthogonal with single-returning-value functions (SRVFs), \eg, \CFA provides the following. \textcolor{blue}{REPLACE ``As an example, we have the following'' WITH ``\CFA provides the following''} 727 748 \begin{cfa} 728 749 printf( "%d %d\n", div( 13, 5 ) ); $\C{// return values seperated into arguments}$ 729 750 \end{cfa} 730 751 Here, the values returned by @div@ are composed with the call to @printf@ by flattening the tuple into separate arguments. 731 However, the \CFA type-system must support significantly more complex composition :752 However, the \CFA type-system must support significantly more complex composition. 732 753 \begin{cfa} 733 754 [ int, int ] foo$\(_1\)$( int ); $\C{// overloaded foo functions}$ … … 736 757 `bar`( foo( 3 ), foo( 3 ) ); 737 758 \end{cfa} 738 The type-resolver only has the tuple return-types to resolve the call to @bar@ as the @foo@ parameters are identical, which involves unifying the possible @foo@ functions with @bar@'s parameter list. 739 No combination of @foo@s are an exact match with @bar@'s parameters, so the resolver applies C conversions. 759 The type resolver only has the tuple return types to resolve the call to @bar@ as the @foo@ parameters are identical, which involves unifying the possible @foo@ functions with @bar@'s parameter list. 760 No combination of @foo@s is an exact match with @bar@'s parameters; 761 thus, the resolver applies C conversions. 762 % FIX 740 763 The minimal cost is @bar( foo@$_1$@( 3 ), foo@$_2$@( 3 ) )@, giving (@int@, {\color{ForestGreen}@int@}, @double@) to (@int@, {\color{ForestGreen}@double@}, @double@) with one {\color{ForestGreen}safe} (widening) conversion from @int@ to @double@ versus ({\color{red}@double@}, {\color{ForestGreen}@int@}, {\color{ForestGreen}@int@}) to ({\color{red}@int@}, {\color{ForestGreen}@double@}, {\color{ForestGreen}@double@}) with one {\color{red}unsafe} (narrowing) conversion from @double@ to @int@ and two safe conversions. 741 764 742 765 743 \subsection{Tuple Variables}766 \subsection{Tuple variables} 744 767 745 768 An important observation from function composition is that new variable names are not required to initialize parameters from an MRVF. 746 \CFA also allows declaration of tuple variables that can be initialized from an MRVF, since it can be awkward to declare multiple variables of different types, \eg: 769 \CFA also allows declaration of tuple variables that can be initialized from an MRVF, since it can be awkward to declare multiple variables of different types. 770 \newpage 747 771 \begin{cfa} 748 772 [ int, int ] qr = div( 13, 5 ); $\C{// tuple-variable declaration and initialization}$ 749 773 [ double, double ] qr = div( 13.5, 5.2 ); 750 774 \end{cfa} 751 where the tuple variable-name serves the same purpose as the parameter name(s).775 Here, the tuple variable name serves the same purpose as the parameter name(s). 752 776 Tuple variables can be composed of any types, except for array types, since array sizes are generally unknown in C. 753 777 754 One way to access the tuple -variable components is with assignment or composition:778 One way to access the tuple variable components is with assignment or composition. 755 779 \begin{cfa} 756 780 [ q, r ] = qr; $\C{// access tuple-variable components}$ 757 781 printf( "%d %d\n", qr ); 758 782 \end{cfa} 759 \CFA also supports \newterm{tuple indexing} to access single components of a tuple expression :783 \CFA also supports \newterm{tuple indexing} to access single components of a tuple expression. \textcolor{blue}{REMOVE ``as follows''} 760 784 \begin{cfa} 761 785 [int, int] * p = &qr; $\C{// tuple pointer}$ … … 768 792 769 793 770 \subsection{Flattening and Restructuring}794 \subsection{Flattening and restructuring} 771 795 772 796 In function call contexts, tuples support implicit flattening and restructuring conversions. 773 797 Tuple flattening recursively expands a tuple into the list of its basic components. 774 Tuple structuring packages a list of expressions into a value of tuple type , \eg:798 Tuple structuring packages a list of expressions into a value of tuple type. 775 799 \begin{cfa} 776 800 int f( int, int ); … … 783 807 h( x, y ); $\C{// flatten and structure}$ 784 808 \end{cfa} 785 In the call to @f@, @x@ is implicitly flattened so the components of @x@ are passed as t he two arguments.809 In the call to @f@, @x@ is implicitly flattened so the components of @x@ are passed as two arguments. 786 810 In the call to @g@, the values @y@ and @10@ are structured into a single argument of type @[int, int]@ to match the parameter type of @g@. 787 Finally, in the call to @h@, @x@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component of @x@ and @y@ are structured into the second argument of type @[int, int]@.788 The flexible structure of tuples permits a simple and expressive function call syntax to work seamlessly with both SRVF and MRVF, andwith any number of arguments of arbitrarily complex structure.789 790 791 \subsection{Tuple Assignment}811 Finally, in the call to @h@, @x@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component \textcolor{blue}{CHANGE ``components'' TO ``component''} of @x@ and @y@ are structured into the second argument of type @[int, int]@. 812 The flexible structure of tuples permits a simple and expressive function call syntax to work seamlessly with both SRVFs and MRVFs \textcolor{blue}{REMOVE ``and''} with any number of arguments of arbitrarily complex structure. 813 814 815 \subsection{Tuple assignment} 792 816 793 817 An assignment where the left side is a tuple type is called \newterm{tuple assignment}. 794 There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non -tuple type, called \newterm{multiple} and \newterm{mass assignment}, respectively.818 There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a nontuple type, called \newterm{multiple} and \newterm{mass assignment}, respectively. 795 819 \begin{cfa} 796 820 int x = 10; … … 802 826 [y, x] = 3.14; $\C{// mass assignment}$ 803 827 \end{cfa} 804 Both kinds of tuple assignment have parallel semantics, so that each value on the left and right side is evaluated before any assignments occur.828 Both kinds of tuple assignment have parallel semantics, so that each value on the left and right sides is evaluated before any assignments occur. 805 829 As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function, \eg, @[x, y] = [y, x]@. 806 This semantics means mass assignment differs from C cascading assignment (\eg @a = b = c@) in that conversions are applied in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment. 807 For example, @[y, x] = 3.14@ performs the assignments @y = 3.14@ and @x = 3.14@, yielding @y == 3.14@ and @x == 3@; 808 whereas, C cascading assignment @y = x = 3.14@ performs the assignments @x = 3.14@ and @y = x@, yielding @3@ in @y@ and @x@. 830 This semantics means mass assignment differs from C cascading 831 \newpage 832 assignment (\eg @a = b = c@) in that conversions are applied in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment. 833 For example, @[y, x] = 3.14@ performs the assignments @y = 3.14@ and @x = 3.14@, yielding @y == 3.14@ and @x == 3@, whereas C cascading assignment @y = x = 3.14@ performs the assignments @x = 3.14@ and @y = x@, yielding @3@ in @y@ and @x@. 809 834 Finally, tuple assignment is an expression where the result type is the type of the left-hand side of the assignment, just like all other assignment expressions in C. 810 This example shows mass, multiple, and cascading assignment used in one expression :835 This example shows mass, multiple, and cascading assignment used in one expression. 811 836 \begin{cfa} 812 837 [void] f( [int, int] ); … … 815 840 816 841 817 \subsection{Member Access}818 819 It is also possible to access multiple members from a single expression using a \newterm{member -access}.820 The result is a single tuple-valued expression whose type is the tuple of the types of the members , \eg:842 \subsection{Member access} 843 844 It is also possible to access multiple members from a single expression using a \newterm{member access}. 845 The result is a single tuple-valued expression whose type is the tuple of the types of the members. 821 846 \begin{cfa} 822 847 struct S { int x; double y; char * z; } s; … … 832 857 [int, int, int] y = x.[2, 0, 2]; $\C{// duplicate: [y.0, y.1, y.2] = [x.2, x.0.x.2]}$ 833 858 \end{cfa} 834 It is also possible for a member access to contain other member accesses , \eg:859 It is also possible for a member access to contain other member accesses. \textcolor{blue}{REMOVE ``, as follows.''} 835 860 \begin{cfa} 836 861 struct A { double i; int j; }; … … 899 924 900 925 Tuples also integrate with \CFA polymorphism as a kind of generic type. 901 Due to the implicit flattening and structuring conversions involved in argument passing, @otype@ and @dtype@ parameters are restricted to matching only with non -tuple types, \eg:926 Due to the implicit flattening and structuring conversions involved in argument passing, @otype@ and @dtype@ parameters are restricted to matching only with nontuple types. 902 927 \begin{cfa} 903 928 forall( otype T, dtype U ) void f( T x, U * y ); 904 929 f( [5, "hello"] ); 905 930 \end{cfa} 906 where@[5, "hello"]@ is flattened, giving argument list @5, "hello"@, and @T@ binds to @int@ and @U@ binds to @const char@.931 Here, @[5, "hello"]@ is flattened, giving argument list @5, "hello"@, and @T@ binds to @int@ and @U@ binds to @const char@. 907 932 Tuples, however, may contain polymorphic components. 908 933 For example, a plus operator can be written to sum two triples. … … 922 947 g( 5, 10.21 ); 923 948 \end{cfa} 949 \newpage 924 950 Hence, function parameter and return lists are flattened for the purposes of type unification allowing the example to pass expression resolution. 925 951 This relaxation is possible by extending the thunk scheme described by Bilson~\cite{Bilson03}. … … 932 958 933 959 934 \subsection{Variadic Tuples}960 \subsection{Variadic tuples} 935 961 \label{sec:variadic-tuples} 936 962 937 To define variadic functions, \CFA adds a new kind of type parameter, @ttype@ (tuple type).938 Matching against a @ttype@ parameter consumes all remaining argument components and packages them into a tuple, binding to the resulting tuple of types.939 In a given parameter list, there must be at mostone @ttype@ parameter that occurs last, which matches normal variadic semantics, with a strong feeling of similarity to \CCeleven variadic templates.963 To define variadic functions, \CFA adds a new kind of type parameter, \ie @ttype@ (tuple type). 964 Matching against a @ttype@ parameter consumes all the remaining argument components and packages them into a tuple, binding to the resulting tuple of types. 965 In a given parameter list, there must be, at most, one @ttype@ parameter that occurs last, which matches normal variadic semantics, with a strong feeling of similarity to \CCeleven variadic templates. 940 966 As such, @ttype@ variables are also called \newterm{argument packs}. 941 967 … … 943 969 Since nothing is known about a parameter pack by default, assertion parameters are key to doing anything meaningful. 944 970 Unlike variadic templates, @ttype@ polymorphic functions can be separately compiled. 945 For example, a generalized @sum@ function:971 For example, the following is a \textcolor{blue}{CHANGE ``As an example, we have the following'' TO ``For example, the following is a''} generalized @sum@ function. 946 972 \begin{cfa} 947 973 int sum$\(_0\)$() { return 0; } … … 952 978 \end{cfa} 953 979 Since @sum@\(_0\) does not accept any arguments, it is not a valid candidate function for the call @sum(10, 20, 30)@. 954 In order to call @sum@\(_1\), @10@ is matched with @x@, and the argument resolution moves on to the argument pack @rest@, which consumes the remainder of the argument list and @Params@ is bound to @[20, 30]@.980 In order to call @sum@\(_1\), @10@ is matched with @x@, and the argument resolution moves on to the argument pack @rest@, which consumes the remainder of the argument list, and @Params@ is bound to @[20, 30]@. 955 981 The process continues until @Params@ is bound to @[]@, requiring an assertion @int sum()@, which matches @sum@\(_0\) and terminates the recursion. 956 982 Effectively, this algorithm traces as @sum(10, 20, 30)@ $\rightarrow$ @10 + sum(20, 30)@ $\rightarrow$ @10 + (20 + sum(30))@ $\rightarrow$ @10 + (20 + (30 + sum()))@ $\rightarrow$ @10 + (20 + (30 + 0))@. 957 983 958 It is reasonable to take the @sum@ function a step further to enforce a minimum number of arguments :984 It is reasonable to take the @sum@ function a step further to enforce a minimum number of arguments. 959 985 \begin{cfa} 960 986 int sum( int x, int y ) { return x + y; } … … 963 989 } 964 990 \end{cfa} 965 One more step permits the summation of any sumable type with all arguments of the same type :991 One more step permits the summation of any sumable type with all arguments of the same type. 966 992 \begin{cfa} 967 993 trait sumable( otype T ) { … … 977 1003 Unlike C variadic functions, it is unnecessary to hard code the number and expected types. 978 1004 Furthermore, this code is extendable for any user-defined type with a @?+?@ operator. 979 Summing arbitrary heterogeneous lists is possible with similar code by adding the appropriate type variables and addition operators.1005 Summing \textcolor{blue}{REMOVE ``up''} arbitrary heterogeneous lists is possible with similar code by adding the appropriate type variables and addition operators. 980 1006 981 1007 It is also possible to write a type-safe variadic print function to replace @printf@: … … 992 1018 This example showcases a variadic-template-like decomposition of the provided argument list. 993 1019 The individual @print@ functions allow printing a single element of a type. 994 The polymorphic @print@ allows printing any list of types, where aseach individual type has a @print@ function.1020 The polymorphic @print@ allows printing any list of types, where each individual type has a @print@ function. 995 1021 The individual print functions can be used to build up more complicated @print@ functions, such as @S@, which cannot be done with @printf@ in C. 996 1022 This mechanism is used to seamlessly print tuples in the \CFA I/O library (see Section~\ref{s:IOLibrary}). 997 1023 998 1024 Finally, it is possible to use @ttype@ polymorphism to provide arbitrary argument forwarding functions. 999 For example, it is possible to write @new@ as a library function :1025 For example, it is possible to write @new@ as a library function. 1000 1026 \begin{cfa} 1001 1027 forall( otype R, otype S ) void ?{}( pair(R, S) *, R, S ); … … 1006 1032 \end{cfa} 1007 1033 The @new@ function provides the combination of type-safe @malloc@ with a \CFA constructor call, making it impossible to forget constructing dynamically allocated objects. 1008 This function provides the type -safety of @new@ in \CC, without the need to specify the allocated type again, thanksto return-type inference.1034 This function provides the type safety of @new@ in \CC, without the need to specify the allocated type again, due to return-type inference. 1009 1035 1010 1036 … … 1012 1038 1013 1039 Tuples are implemented in the \CFA translator via a transformation into \newterm{generic types}. 1014 For each $N$, the first time an $N$-tuple is seen in a scope a generic type with $N$ type parameters is generated, \eg: 1040 For each $N$, the first time an $N$-tuple is seen in a scope, a generic type with $N$ type parameters is generated. 1041 For example, the following \textcolor{blue}{CHANGE ``, as follows:'' TO ``For example, the following''} 1015 1042 \begin{cfa} 1016 1043 [int, int] f() { … … 1019 1046 } 1020 1047 \end{cfa} 1021 is transformed into :1048 is transformed into 1022 1049 \begin{cfa} 1023 1050 forall( dtype T0, dtype T1 | sized(T0) | sized(T1) ) struct _tuple2 { … … 1085 1112 1086 1113 The various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions. 1087 A variable is generated to store the value produced by a statement expression, since its members may need to be constructed with a non -trivial constructor and it may need to be referred to multiple time, \eg in a unique expression.1114 A variable is generated to store the value produced by a statement expression, since its members may need to be constructed with a nontrivial constructor and it may need to be referred to multiple time, \eg in a unique expression. 1088 1115 The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language. 1089 1116 However, there are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this restriction is not new. … … 1093 1120 \section{Control Structures} 1094 1121 1095 \CFA identifies inconsistent, problematic, and missing control structures in C, a ndextends, modifies, and adds control structures to increase functionality and safety.1096 1097 1098 \subsection{\texorpdfstring{\protect\lstinline@if@ Statement}{if Statement}}1099 1100 The @if@ expression allows declarations, similar to @for@ declaration expression:1122 \CFA identifies inconsistent, problematic, and missing control structures in C, as well as extends, modifies, and adds control structures to increase functionality and safety. 1123 1124 1125 \subsection{\texorpdfstring{\protect\lstinline@if@ statement}{if statement}} 1126 1127 The @if@ expression allows declarations, similar to the @for@ declaration expression. 1101 1128 \begin{cfa} 1102 1129 if ( int x = f() ) ... $\C{// x != 0}$ … … 1105 1132 \end{cfa} 1106 1133 Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the @if@ expression, and the results are combined using the logical @&&@ operator.\footnote{\CC only provides a single declaration always compared not equal to 0.} 1107 The scope of the declaration(s) is local to the @if@ statement but exist within both the ``then'' and ``else'' clauses.1108 1109 1110 \subsection{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}1134 The scope of the declaration(s) is local to the @if@ statement but exists within both the ``then'' and ``else'' clauses. 1135 1136 1137 \subsection{\texorpdfstring{\protect\lstinline@switch@ statement}{switch statement}} 1111 1138 1112 1139 There are a number of deficiencies with the C @switch@ statements: enumerating @case@ lists, placement of @case@ clauses, scope of the switch body, and fall through between case clauses. 1113 1140 1114 C has no shorthand for specifying a list of case values, whether the list is non -contiguous or contiguous\footnote{C provides this mechanism via fall through.}.1115 \CFA provides a shorthand for a non -contiguous list:1141 C has no shorthand for specifying a list of case values, whether the list is noncontiguous or contiguous\footnote{C provides this mechanism via fall through.}. 1142 \CFA provides a shorthand for a noncontiguous list: 1116 1143 \begin{cquote} 1117 1144 \lstDeleteShortInline@% … … 1128 1155 \lstMakeShortInline@% 1129 1156 \end{cquote} 1130 for a contiguous list:\footnote{gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, as a space is required after a number, otherwise the first period is a decimal point.} 1157 for a contiguous list:\footnote{gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, as a space is required after a number; 1158 otherwise, the first period is a decimal point.} 1131 1159 \begin{cquote} 1132 1160 \lstDeleteShortInline@% … … 1159 1187 } 1160 1188 \end{cfa} 1161 \CFA precludes this form of transfer \emph{into} a control structure because it causes undefined behaviour, especially with respect to missed initialization, and provides very limited functionality.1162 1163 C allows placement of declaration within the @switch@ body and unreachable code at the start, resulting in undefined behaviour:1189 \CFA precludes this form of transfer \emph{into} a control structure because it causes an undefined behavior, especially with respect to missed initialization, and provides very limited functionality. 1190 1191 C allows placement of declaration within the @switch@ body and unreachable code at the start, resulting in an undefined behavior. 1164 1192 \begin{cfa} 1165 1193 switch ( x ) { … … 1178 1206 1179 1207 C @switch@ provides multiple entry points into the statement body, but once an entry point is selected, control continues across \emph{all} @case@ clauses until the end of the @switch@ body, called \newterm{fall through}; 1180 @case@ clauses are made disjoint by the @break@ statement. 1208 @case@ clauses are made disjoint by the @break@ 1209 \newpage 1210 \noindent 1211 statement. 1181 1212 While fall through \emph{is} a useful form of control flow, it does not match well with programmer intuition, resulting in errors from missing @break@ statements. 1182 For backward s compatibility, \CFA provides a \emph{new} control structure,@choose@, which mimics @switch@, but reverses the meaning of fall through (see Figure~\ref{f:ChooseSwitchStatements}), similar to Go.1213 For backward compatibility, \CFA provides a \emph{new} control structure, \ie @choose@, which mimics @switch@, but reverses the meaning of fall through (see Figure~\ref{f:ChooseSwitchStatements}), similar to Go. 1183 1214 1184 1215 \begin{figure} 1185 1216 \centering 1217 \fontsize{9bp}{11bp}\selectfont 1186 1218 \lstDeleteShortInline@% 1187 1219 \begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}} … … 1220 1252 \end{tabular} 1221 1253 \lstMakeShortInline@% 1222 \caption{\lstinline|choose| versus \lstinline|switch| Statements}1254 \caption{\lstinline|choose| versus \lstinline|switch| statements} 1223 1255 \label{f:ChooseSwitchStatements} 1256 \vspace*{-11pt} 1224 1257 \end{figure} 1225 1258 1226 Finally, Figure~\ref{f:FallthroughStatement} shows @fallthrough@ may appear in contexts other than terminating a @case@ clause , and have an explicit transfer label allowing separate cases but common final-code for a set of cases.1259 Finally, Figure~\ref{f:FallthroughStatement} shows @fallthrough@ may appear in contexts other than terminating a @case@ clause and have an explicit transfer label allowing separate cases but common final code for a set of cases. 1227 1260 The target label must be below the @fallthrough@ and may not be nested in a control structure, \ie @fallthrough@ cannot form a loop, and the target label must be at the same or higher level as the containing @case@ clause and located at the same level as a @case@ clause; 1228 1261 the target label may be case @default@, but only associated with the current @switch@/@choose@ statement. … … 1230 1263 \begin{figure} 1231 1264 \centering 1265 \fontsize{9bp}{11bp}\selectfont 1232 1266 \lstDeleteShortInline@% 1233 1267 \begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}} … … 1258 1292 \end{tabular} 1259 1293 \lstMakeShortInline@% 1260 \caption{\lstinline|fallthrough| Statement}1294 \caption{\lstinline|fallthrough| statement} 1261 1295 \label{f:FallthroughStatement} 1296 \vspace*{-11pt} 1262 1297 \end{figure} 1263 1298 1264 1299 1265 \subsection{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}} 1300 \vspace*{-8pt} 1301 \subsection{\texorpdfstring{Labeled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labeled continue / break}} 1266 1302 1267 1303 While C provides @continue@ and @break@ statements for altering control flow, both are restricted to one level of nesting for a particular control structure. 1268 Unfortunately, this restriction forces programmers to use @goto@ to achieve the equivalent control -flow for more than one level of nesting.1269 To prevent having to switch to the @goto@, \CFA extends the @continue@ and @break@ with a target label to support static multi-level exit~\cite{Buhr85}, as in Java.1304 Unfortunately, this restriction forces programmers to use @goto@ to achieve the equivalent control flow for more than one level of nesting. 1305 To prevent having to switch to the @goto@, \CFA extends @continue@ and @break@ with a target label to support static multilevel exit~\cite{Buhr85}, as in Java. 1270 1306 For both @continue@ and @break@, the target label must be directly associated with a @for@, @while@ or @do@ statement; 1271 1307 for @break@, the target label can also be associated with a @switch@, @if@ or compound (@{}@) statement. 1272 Figure~\ref{f:MultiLevelExit} shows @continue@ and @break@ indicating the specific control structure ,and the corresponding C program using only @goto@ and labels.1273 The innermost loop has 7 exit points, which cause continuation or termination of one or more of the 7 nested control-structures.1308 Figure~\ref{f:MultiLevelExit} shows @continue@ and @break@ indicating the specific control structure and the corresponding C program using only @goto@ and labels. 1309 The innermost loop has seven exit points, which cause a continuation or termination of one or more of the seven nested control structures. 1274 1310 1275 1311 \begin{figure} 1312 \fontsize{9bp}{11bp}\selectfont 1276 1313 \lstDeleteShortInline@% 1277 1314 \begin{tabular}{@{\hspace{\parindentlnth}}l|@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}} … … 1338 1375 \end{tabular} 1339 1376 \lstMakeShortInline@% 1340 \caption{Multi -level Exit}1377 \caption{Multilevel exit} 1341 1378 \label{f:MultiLevelExit} 1379 \vspace*{-5pt} 1342 1380 \end{figure} 1343 1381 1344 With respect to safety, both label led @continue@ and @break@ are a @goto@ restricted in the following ways:1345 \begin{ itemize}1382 With respect to safety, both labeled @continue@ and @break@ are @goto@ restricted in the following ways. 1383 \begin{list}{$\bullet$}{\topsep=4pt\itemsep=0pt\parsep=0pt} 1346 1384 \item 1347 1385 They cannot create a loop, which means only the looping constructs cause looping. … … 1349 1387 \item 1350 1388 They cannot branch into a control structure. 1351 This restriction prevents missing declarations and/or initializations at the start of a control structure resulting in undefined behaviour. 1352 \end{itemize} 1353 The advantage of the labelled @continue@/@break@ is allowing static multi-level exits without having to use the @goto@ statement, and tying control flow to the target control structure rather than an arbitrary point in a program. 1354 Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader (eye candy) that complex control-flow is occurring in the body of the control structure. 1389 This restriction prevents missing declarations and/or initializations at the start of a control structure resulting in an undefined behavior. 1390 \end{list} 1391 The advantage of the labeled @continue@/@break@ is allowing static multilevel exits without having to use the @goto@ statement and tying control flow to the target control structure rather than an arbitrary point in a program. 1392 Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader (eye candy) that complex control flow is 1393 occurring in the body of the control structure. 1355 1394 With @goto@, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader. 1356 Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.1395 Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting the existing constructs. 1357 1396 Otherwise, the implicit targets of the current @continue@ and @break@, \ie the closest enclosing loop or @switch@, change as certain constructs are added or removed. 1358 1397 1359 1398 1360 \subsection{Exception Handling} 1361 1362 The following framework for \CFA exception-handling is in place, excluding some runtime type-information and virtual functions. 1399 \vspace*{-5pt} 1400 \subsection{Exception handling} 1401 1402 The following framework for \CFA exception handling is in place, excluding some runtime type information and virtual functions. 1363 1403 \CFA provides two forms of exception handling: \newterm{fix-up} and \newterm{recovery} (see Figure~\ref{f:CFAExceptionHandling})~\cite{Buhr92b,Buhr00a}. 1364 Both mechanisms provide dynamic call to a handler using dynamic name -lookup, where fix-up has dynamic return and recovery has static return from the handler.1404 Both mechanisms provide dynamic call to a handler using dynamic name lookup, where fix-up has dynamic return and recovery has static return from the handler. 1365 1405 \CFA restricts exception types to those defined by aggregate type @exception@. 1366 1406 The form of the raise dictates the set of handlers examined during propagation: \newterm{resumption propagation} (@resume@) only examines resumption handlers (@catchResume@); \newterm{terminating propagation} (@throw@) only examines termination handlers (@catch@). 1367 If @resume@ or @throw@ ha ve no exception type, it is a reresume/rethrow, meaning the currentlyexception continues propagation.1407 If @resume@ or @throw@ has no exception type, it is a reresume/rethrow, which means that the current exception continues propagation. 1368 1408 If there is no current exception, the reresume/rethrow results in a runtime error. 1369 1409 1370 1410 \begin{figure} 1411 \fontsize{9bp}{11bp}\selectfont 1412 \lstDeleteShortInline@% 1371 1413 \begin{cquote} 1372 \lstDeleteShortInline@%1373 1414 \begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}} 1374 1415 \multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{Resumption}} & \multicolumn{1}{c@{}}{\textbf{Termination}} \\ … … 1401 1442 \end{cfa} 1402 1443 \end{tabular} 1403 \lstMakeShortInline@%1404 1444 \end{cquote} 1405 \caption{\CFA Exception Handling} 1445 \lstMakeShortInline@% 1446 \caption{\CFA exception handling} 1406 1447 \label{f:CFAExceptionHandling} 1448 \vspace*{-5pt} 1407 1449 \end{figure} 1408 1450 1409 The set of exception types in a list of catch clause may include both a resumption and termination handler:1451 The set of exception types in a list of catch clauses may include both a resumption and a termination handler. 1410 1452 \begin{cfa} 1411 1453 try { … … 1421 1463 The termination handler is available because the resumption propagation did not unwind the stack. 1422 1464 1423 An additional feature is conditional matching in a catch clause :1465 An additional feature is conditional matching in a catch clause. 1424 1466 \begin{cfa} 1425 1467 try { … … 1430 1472 catch ( IOError err ) { ... } $\C{// handler error from other files}$ 1431 1473 \end{cfa} 1432 where the throw inserts the failing file-handle into the I/O exception.1433 Conditional catch cannot be trivially mimicked by other mechanisms because once an exception is caught, handler clauses in that @try@ statement are no longer eligible. .1434 1435 The resumption raise can specify an alternate stack on which to raise an exception, called a \newterm{nonlocal raise} :1474 Here, the throw inserts the failing file handle into the I/O exception. 1475 Conditional catch cannot be trivially mimicked by other mechanisms because once an exception is caught, handler clauses in that @try@ statement are no longer eligible. 1476 1477 The resumption raise can specify an alternate stack on which to raise an exception, called a \newterm{nonlocal raise}. 1436 1478 \begin{cfa} 1437 1479 resume( $\emph{exception-type}$, $\emph{alternate-stack}$ ) … … 1441 1483 Nonlocal raise is restricted to resumption to provide the exception handler the greatest flexibility because processing the exception does not unwind its stack, allowing it to continue after the handler returns. 1442 1484 1443 To facilitate nonlocal raise, \CFA provides dynamic enabling and disabling of nonlocal exception -propagation.1444 The constructs for controlling propagation of nonlocal exceptions are the @enable@ and the @disable@ blocks:1485 To facilitate nonlocal raise, \CFA provides dynamic enabling and disabling of nonlocal exception propagation. 1486 The constructs for controlling propagation of nonlocal exceptions are the @enable@ and @disable@ blocks. 1445 1487 \begin{cquote} 1446 1488 \lstDeleteShortInline@% … … 1448 1490 \begin{cfa} 1449 1491 enable $\emph{exception-type-list}$ { 1450 // allow non -local raise1492 // allow nonlocal raise 1451 1493 } 1452 1494 \end{cfa} … … 1454 1496 \begin{cfa} 1455 1497 disable $\emph{exception-type-list}$ { 1456 // disallow non -local raise1498 // disallow nonlocal raise 1457 1499 } 1458 1500 \end{cfa} … … 1462 1504 The arguments for @enable@/@disable@ specify the exception types allowed to be propagated or postponed, respectively. 1463 1505 Specifying no exception type is shorthand for specifying all exception types. 1464 Both @enable@ and @disable@ blocks can be nested, turning propagation on/off on entry, and on exit, the specified exception types are restored to their prior state. 1465 Coroutines and tasks start with non-local exceptions disabled, allowing handlers to be put in place, before non-local exceptions are explicitly enabled. 1506 Both @enable@ and @disable@ blocks can be nested; 1507 turning propagation on/off on entry and on exit, the specified exception types are restored to their prior state. 1508 Coroutines and tasks start with nonlocal exceptions disabled, allowing handlers to be put in place, before nonlocal exceptions are explicitly enabled. 1466 1509 \begin{cfa} 1467 1510 void main( mytask & t ) { $\C{// thread starts here}$ 1468 // non -local exceptions disabled1469 try { $\C{// establish handles for non -local exceptions}$1470 enable { $\C{// allow non -local exception delivery}$1511 // nonlocal exceptions disabled 1512 try { $\C{// establish handles for nonlocal exceptions}$ 1513 enable { $\C{// allow nonlocal exception delivery}$ 1471 1514 // task body 1472 1515 } … … 1476 1519 \end{cfa} 1477 1520 1478 Finally, \CFA provides a Java like @finally@ clause after the catch clauses: 1521 \textcolor{blue}{PARAGRAPH INDENT} Finally, \CFA provides a Java-like @finally@ clause after the catch clauses. 1479 1522 \begin{cfa} 1480 1523 try { … … 1485 1528 } 1486 1529 \end{cfa} 1487 The finally clause is always executed, i.e., if the try block ends normally or if an exception is raised.1530 The finally clause is always executed, \ie, if the try block ends normally or if an exception is raised. 1488 1531 If an exception is raised and caught, the handler is run before the finally clause. 1489 1532 Like a destructor (see Section~\ref{s:ConstructorsDestructors}), a finally clause can raise an exception but not if there is an exception being propagated. 1490 Mimicking the @finally@ clause with mechanisms like R AII is non-trivial when there are multiple types and local accesses.1491 1492 1493 \subsection{\texorpdfstring{\protect\lstinline{with} Statement}{with Statement}}1533 Mimicking the @finally@ clause with mechanisms like Resource Aquisition Is Initialization (RAII) is nontrivial when there are multiple types and local accesses. 1534 1535 1536 \subsection{\texorpdfstring{\protect\lstinline{with} statement}{with statement}} 1494 1537 \label{s:WithStatement} 1495 1538 1496 Heterogeneous data isoften aggregated into a structure/union.1497 To reduce syntactic noise, \CFA provides a @with@ statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate member-qualification by opening a scope containing the member identifiers.1539 Heterogeneous data are often aggregated into a structure/union. 1540 To reduce syntactic noise, \CFA provides a @with@ statement (see section~4.F in the Pascal User Manual and Report~\cite{Pascal}) to elide aggregate member qualification by opening a scope containing the member identifiers. 1498 1541 \begin{cquote} 1499 1542 \vspace*{-\baselineskip}%??? … … 1523 1566 Object-oriented programming languages only provide implicit qualification for the receiver. 1524 1567 1525 In detail, the @with@ statement has the form :1568 In detail, the @with@ statement has the form 1526 1569 \begin{cfa} 1527 1570 $\emph{with-statement}$: … … 1529 1572 \end{cfa} 1530 1573 and may appear as the body of a function or nested within a function body. 1531 Each expression in the expression -list provides a type and object.1574 Each expression in the expression list provides a type and object. 1532 1575 The type must be an aggregate type. 1533 1576 (Enumerations are already opened.) 1534 The object is the implicit qualifier for the open structure -members.1577 The object is the implicit qualifier for the open structure members. 1535 1578 1536 1579 All expressions in the expression list are open in parallel within the compound statement, which is different from Pascal, which nests the openings from left to right. 1537 The difference between parallel and nesting occurs for members with the same name and type :1580 The difference between parallel and nesting occurs for members with the same name and type. 1538 1581 \begin{cfa} 1539 1582 struct S { int `i`; int j; double m; } s, w; $\C{// member i has same type in structure types S and T}$ … … 1549 1592 } 1550 1593 \end{cfa} 1551 For parallel semantics, both @s.i@ and @t.i@ are visible , so@i@ is ambiguous without qualification;1552 for nested semantics, @t.i@ hides @s.i@ , so@i@ implies @t.i@.1594 For parallel semantics, both @s.i@ and @t.i@ are visible and, therefore, @i@ is ambiguous without qualification; 1595 for nested semantics, @t.i@ hides @s.i@ and, therefore, @i@ implies @t.i@. 1553 1596 \CFA's ability to overload variables means members with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates. 1554 1597 Qualification or a cast is used to disambiguate. 1555 1598 1556 There is an interesting problem between parameters and the function -body @with@, \eg:1599 There is an interesting problem between parameters and the function body @with@. 1557 1600 \begin{cfa} 1558 1601 void ?{}( S & s, int i ) with ( s ) { $\C{// constructor}$ … … 1560 1603 } 1561 1604 \end{cfa} 1562 Here, the assignment @s.i = i@ means @s.i = s.i@, which is meaningless, and there is no mechanism to qualify the parameter @i@, making the assignment impossible using the function -body @with@.1563 To solve this problem, parameters are treated like an initialized aggregate :1605 Here, the assignment @s.i = i@ means @s.i = s.i@, which is meaningless, and there is no mechanism to qualify the parameter @i@, making the assignment impossible using the function body @with@. 1606 To solve this problem, parameters are treated like an initialized aggregate 1564 1607 \begin{cfa} 1565 1608 struct Params { … … 1568 1611 } params; 1569 1612 \end{cfa} 1570 and implicitly opened \emph{after} a function-body open, to give them higher priority: 1613 \newpage 1614 and implicitly opened \emph{after} a function body open, to give them higher priority 1571 1615 \begin{cfa} 1572 1616 void ?{}( S & s, int `i` ) with ( s ) `{` `with( $\emph{\color{red}params}$ )` { … … 1574 1618 } `}` 1575 1619 \end{cfa} 1576 Finally, a cast may be used to disambiguate among overload variables in a @with@ expression :1620 Finally, a cast may be used to disambiguate among overload variables in a @with@ expression 1577 1621 \begin{cfa} 1578 1622 with ( w ) { ... } $\C{// ambiguous, same name and no context}$ 1579 1623 with ( (S)w ) { ... } $\C{// unambiguous, cast}$ 1580 1624 \end{cfa} 1581 and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate :1625 and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate 1582 1626 \begin{cfa} 1583 1627 struct S { int i, j; } sv; … … 1603 1647 \CFA attempts to correct and add to C declarations, while ensuring \CFA subjectively ``feels like'' C. 1604 1648 An important part of this subjective feel is maintaining C's syntax and procedural paradigm, as opposed to functional and object-oriented approaches in other systems languages such as \CC and Rust. 1605 Maintaining the C approach means that C coding -patterns remain not only useable but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.1649 Maintaining the C approach means that C coding patterns remain not only useable but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development. 1606 1650 Nevertheless, some features from other approaches are undeniably convenient; 1607 1651 \CFA attempts to adapt these features to the C paradigm. 1608 1652 1609 1653 1610 \subsection{Alternative Declaration Syntax}1654 \subsection{Alternative declaration syntax} 1611 1655 1612 1656 C declaration syntax is notoriously confusing and error prone. 1613 For example, many C programmers are confused by a declaration as simple as :1657 For example, many C programmers are confused by a declaration as simple as the following. \textcolor{blue}{CHANGE ``simple a declaration as in'' TO ``declaration as simple as''} 1614 1658 \begin{cquote} 1615 1659 \lstDeleteShortInline@% … … 1623 1667 \lstMakeShortInline@% 1624 1668 \end{cquote} 1625 Is this an array of 5 pointers to integers or a pointer to an array of 5integers?1669 Is this an array of five pointers to integers or a pointer to an array of five integers? 1626 1670 If there is any doubt, it implies productivity and safety issues even for basic programs. 1627 1671 Another example of confusion results from the fact that a function name and its parameters are embedded within the return type, mimicking the way the return value is used at the function's call site. 1628 For example, a function returning a pointer to an array of integers is defined and used in the following way :1672 For example, a function returning a pointer to an array of integers is defined and used in the following way. 1629 1673 \begin{cfa} 1630 1674 int `(*`f`())[`5`]` {...}; $\C{// definition}$ … … 1634 1678 While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice. 1635 1679 1636 \CFA provides its own type, variable and function declarations, using a different syntax~\cite[pp.~856--859]{Buhr94a}. 1637 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right. 1680 \newpage 1681 \CFA provides its own type, variable, and function declarations, using a different syntax~\cite[pp.~856--859]{Buhr94a}. 1682 The new declarations place qualifiers to the left of the base type, whereas C declarations place qualifiers to the right. 1638 1683 The qualifiers have the same meaning but are ordered left to right to specify a variable's type. 1639 1684 \begin{cquote} … … 1661 1706 \lstMakeShortInline@% 1662 1707 \end{cquote} 1663 The only exception is bit-field specification, which always appear to the right of the base type.1708 The only exception is bit-field specification, which always appears to the right of the base type. 1664 1709 % Specifically, the character @*@ is used to indicate a pointer, square brackets @[@\,@]@ are used to represent an array or function return value, and parentheses @()@ are used to indicate a function parameter. 1665 1710 However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list. 1666 For instance, variables @x@ and @y@ of type pointer to integer are defined in \CFA as follows:1711 For instance, variables @x@ and @y@ of type pointer to integer are defined in \CFA as \textcolor{blue}{REMOVE ``follows.''} 1667 1712 \begin{cquote} 1668 1713 \lstDeleteShortInline@% … … 1727 1772 \end{comment} 1728 1773 1729 All specifiers (@extern@, @static@, \etc) and qualifiers (@const@, @volatile@, \etc) are used in the normal way with the new declarations and also appear left to right , \eg:1774 All specifiers (@extern@, @static@, \etc) and qualifiers (@const@, @volatile@, \etc) are used in the normal way with the new declarations and also appear left to right. 1730 1775 \begin{cquote} 1731 1776 \lstDeleteShortInline@% 1732 1777 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}} 1733 1778 \multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}} \\ 1734 \begin{cfa} 1779 \begin{cfa}[basicstyle=\linespread{0.9}\fontsize{9bp}{12bp}\selectfont\sf] 1735 1780 extern const * const int x; 1736 1781 static const * [5] const int y; 1737 1782 \end{cfa} 1738 1783 & 1739 \begin{cfa} 1784 \begin{cfa}[basicstyle=\linespread{0.9}\fontsize{9bp}{12bp}\selectfont\sf] 1740 1785 int extern const * const x; 1741 1786 static const int (* const y)[5] 1742 1787 \end{cfa} 1743 1788 & 1744 \begin{cfa} 1789 \begin{cfa}[basicstyle=\linespread{0.9}\fontsize{9bp}{12bp}\selectfont\sf] 1745 1790 // external const pointer to const int 1746 1791 // internal const pointer to array of 5 const int … … 1750 1795 \end{cquote} 1751 1796 Specifiers must appear at the start of a \CFA function declaration\footnote{\label{StorageClassSpecifier} 1752 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature .~\cite[\S~6.11.5(1)]{C11}}.1797 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature (see section~6.11.5(1) in ISO/IEC 9899~\cite{C11}).}. 1753 1798 1754 1799 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-function @sizeof@: … … 1771 1816 1772 1817 The syntax of the new function-prototype declaration follows directly from the new function-definition syntax; 1773 a s well, parameter names are optional, \eg:1818 also, parameter names are optional. 1774 1819 \begin{cfa} 1775 1820 [ int x ] f ( /* void */ ); $\C[2.5in]{// returning int with no parameters}$ … … 1779 1824 [ * int, int ] j ( int ); $\C{// returning pointer to int and int with int parameter}$ 1780 1825 \end{cfa} 1781 This syntax allows a prototype declaration to be created by cutting and pasting source text from the function-definition header (or vice versa).1782 Like C, it is possible to declare multiple function -prototypes in a single declaration, where the return type is distributed across \emph{all} function names in the declaration list, \eg:1826 This syntax allows a prototype declaration to be created by cutting and pasting the source text from the function-definition header (or vice versa). 1827 Like C, it is possible to declare multiple function prototypes in a single declaration, where the return type is distributed across \emph{all} function names in the declaration list. 1783 1828 \begin{cquote} 1784 1829 \lstDeleteShortInline@% … … 1795 1840 \lstMakeShortInline@% 1796 1841 \end{cquote} 1797 where\CFA allows the last function in the list to define its body.1798 1799 The syntax for pointers to \CFA functions specifies the pointer name on the right , \eg:1842 Here, \CFA allows the last function in the list to define its body. 1843 1844 The syntax for pointers to \CFA functions specifies the pointer name on the right. 1800 1845 \begin{cfa} 1801 1846 * [ int x ] () fp; $\C{// pointer to function returning int with no parameters}$ … … 1804 1849 * [ * int, int ] ( int ) jp; $\C{// pointer to function returning pointer to int and int with int parameter}\CRT$ 1805 1850 \end{cfa} 1806 Note, the name of the function pointer is specified last, as for other variable declarations. 1807 1808 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration. 1809 Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style. 1810 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX-like systems. 1851 \newpage 1852 \noindent 1853 Note that the name of the function pointer is specified last, as for other variable declarations. 1854 1855 Finally, new \CFA declarations may appear together with C declarations in the same program block but cannot be mixed within a specific declaration. 1856 Therefore, a programmer has the option of either continuing to use traditional C declarations or taking advantage of the new style. 1857 Clearly, both styles need to be supported for some time due to existing C-style header files, particularly for UNIX-like systems. 1811 1858 1812 1859 … … 1816 1863 All variables in C have an \newterm{address}, a \newterm{value}, and a \newterm{type}; 1817 1864 at the position in the program's memory denoted by the address, there exists a sequence of bits (the value), with the length and semantic meaning of this bit sequence defined by the type. 1818 The C type -system does not always track the relationship between a value and its address;1819 a value that does not have a corresponding address is called a \newterm{rvalue} (for ``right-hand value''), while a value that does have an address is called a\newterm{lvalue} (for ``left-hand value'').1820 For example, in @int x; x = 42;@ the variable expression @x@ on the left-hand -side of the assignment is a lvalue, while the constant expression @42@ on the right-hand-side of the assignment is arvalue.1821 Despite the nomenclature of ``left-hand'' and ``right-hand'', an expression's classification as lvalue or rvalue is entirely dependent on whether it has an address or not; in imperative programming, the address of a value is used for both reading and writing (mutating) a value, and as such, lvalues can be convertedto rvalues and read from, but rvalues cannot be mutated because they lack a location to store the updated value.1865 The C type system does not always track the relationship between a value and its address; 1866 a value that does not have a corresponding address is called an \newterm{rvalue} (for ``right-hand value''), whereas a value that does have an address is called an \newterm{lvalue} (for ``left-hand value''). 1867 For example, in @int x; x = 42;@ the variable expression @x@ on the left-hand side of the assignment is an lvalue, whereas the constant expression @42@ on the right-hand side of the assignment is an rvalue. 1868 Despite the nomenclature of ``left-hand'' and ``right-hand'', an expression's classification as an lvalue or an rvalue is entirely dependent on whether it has an address or not; in imperative programming, the address of a value is used for both reading and writing (mutating) a value, and as such, lvalues can be converted into rvalues and read from, but rvalues cannot be mutated because they lack a location to store the updated value. 1822 1869 1823 1870 Within a lexical scope, lvalue expressions have an \newterm{address interpretation} for writing a value or a \newterm{value interpretation} to read a value. 1824 For example, in @x = y@, @x@ has an address interpretation, wh ile@y@ has a value interpretation.1871 For example, in @x = y@, @x@ has an address interpretation, whereas @y@ has a value interpretation. 1825 1872 While this duality of interpretation is useful, C lacks a direct mechanism to pass lvalues between contexts, instead relying on \newterm{pointer types} to serve a similar purpose. 1826 1873 In C, for any type @T@ there is a pointer type @T *@, the value of which is the address of a value of type @T@. 1827 A pointer rvalue can be explicitly \newterm{dereferenced} to the pointed-to lvalue with the dereference operator @*?@, while the rvalue representing the address of a lvalue can be obtained with the address-of operator @&?@. 1828 1874 A pointer rvalue can be explicitly \newterm{dereferenced} to the pointed-to lvalue with the dereference operator @*?@, whereas the rvalue representing the address of an lvalue can be obtained with the address-of operator @&?@. 1829 1875 \begin{cfa} 1830 1876 int x = 1, y = 2, * p1, * p2, ** p3; … … 1834 1880 *p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15); 1835 1881 \end{cfa} 1836 1837 1882 Unfortunately, the dereference and address-of operators introduce a great deal of syntactic noise when dealing with pointed-to values rather than pointers, as well as the potential for subtle bugs because of pointer arithmetic. 1838 1883 For both brevity and clarity, it is desirable for the compiler to figure out how to elide the dereference operators in a complex expression such as the assignment to @*p2@ above. 1839 However, since C defines a number of forms of \newterm{pointer arithmetic}, two similar expressions involving pointers to arithmetic types (\eg @*p1 + x@ and @p1 + x@) may each have well-defined but distinct semantics, introducing the possibility that a programmer may write one when they mean the other ,and precluding any simple algorithm for elision of dereference operators.1884 However, since C defines a number of forms of \newterm{pointer arithmetic}, two similar expressions involving pointers to arithmetic types (\eg @*p1 + x@ and @p1 + x@) may each have well-defined but distinct semantics, introducing the possibility that a programmer may write one when they mean the other and precluding any simple algorithm for elision of dereference operators. 1840 1885 To solve these problems, \CFA introduces reference types @T &@; 1841 a @T &@ has exactly the same value as a @T *@, but where the @T *@ takes the address interpretation by default, a @T &@ takes the value interpretation by default, as below: 1842 1886 a @T &@ has exactly the same value as a @T *@, but where the @T *@ takes the address interpretation by default, a @T &@ takes the value interpretation by default, as below. 1843 1887 \begin{cfa} 1844 1888 int x = 1, y = 2, & r1, & r2, && r3; … … 1848 1892 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); $\C{// implicit dereferencing}$ 1849 1893 \end{cfa} 1850 1851 1894 Except for auto-dereferencing by the compiler, this reference example is exactly the same as the previous pointer example. 1852 Hence, a reference behaves like a variable name -- an lvalue expression which is interpreted as a value --but also has the type system track the address of that value.1853 One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in the reference variable declaration , so the previous example implicitly acts like:1854 1895 Hence, a reference behaves like a variable name---an lvalue expression that is interpreted as a value---but also has the type system track the address of that value. 1896 One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in the reference variable declaration; 1897 thus, the previous example implicitly acts like the following. 1855 1898 \begin{cfa} 1856 1899 `*`r2 = ((`*`r1 + `*`r2) * (`**`r3 - `*`r1)) / (`**`r3 - 15); 1857 1900 \end{cfa} 1858 1859 1901 References in \CFA are similar to those in \CC, with important improvements, which can be seen in the example above. 1860 1902 Firstly, \CFA does not forbid references to references. 1861 This provides a much more orthogonal design for library implementors, obviating the need for workarounds such as @std::reference_wrapper@.1903 This provides a much more orthogonal design for library \mbox{implementors}, obviating the need for workarounds such as @std::reference_wrapper@. 1862 1904 Secondly, \CFA references are rebindable, whereas \CC references have a fixed address. 1863 Rebinding allows \CFA references to be default -initialized (\eg to a null pointer\footnote{1864 While effort has been made into non-null reference checking in \CC and Java, the exercise seems moot for any non -managed languages (C/\CC), given that it only handles one of many different error situations, \eg using a pointer after its storage is deleted.}) and point to different addresses throughout their lifetime, like pointers.1905 Rebinding allows \CFA references to be default initialized (\eg to a null pointer\footnote{ 1906 While effort has been made into non-null reference checking in \CC and Java, the exercise seems moot for any nonmanaged languages (C/\CC), given that it only handles one of many different error situations, \eg using a pointer after its storage is deleted.}) and point to different addresses throughout their lifetime, like pointers. 1865 1907 Rebinding is accomplished by extending the existing syntax and semantics of the address-of operator in C. 1866 1908 1867 In C, the address of a lvalue is always a rvalue, as in general that address is not stored anywhere in memory,and does not itself have an address.1868 In \CFA, the address of a @T &@ is a lvalue @T *@, as the address of the underlying @T@ is stored in the reference,and can thus be mutated there.1909 In C, the address of an lvalue is always an rvalue, as, in general, that address is not stored anywhere in memory and does not itself have an address. 1910 In \CFA, the address of a @T &@ is an lvalue @T *@, as the address of the underlying @T@ is stored in the reference and can thus be mutated there. 1869 1911 The result of this rule is that any reference can be rebound using the existing pointer assignment semantics by assigning a compatible pointer into the address of the reference, \eg @&r1 = &x;@ above. 1870 1912 This rebinding occurs to an arbitrary depth of reference nesting; 1871 1913 loosely speaking, nested address-of operators produce a nested lvalue pointer up to the depth of the reference. 1872 1914 These explicit address-of operators can be thought of as ``cancelling out'' the implicit dereference operators, \eg @(&`*`)r1 = &x@ or @(&(&`*`)`*`)r3 = &(&`*`)r1@ or even @(&`*`)r2 = (&`*`)`*`r3@ for @&r2 = &r3@. 1873 More precisely: 1915 The precise rules are 1874 1916 \begin{itemize} 1875 1917 \item 1876 if @R@ is an rvalue of type @T &@$_1\cdots$ @&@$_r$, where $r \ge 1$ references (@&@ symbols), than @&R@ has type @T `*`&@$_{\color{red}2}\cdots$ @&@$_{\color{red}r}$, \ie @T@ pointer with $r-1$ references (@&@ symbols).1918 If @R@ is an rvalue of type @T &@$_1\cdots$ @&@$_r$, where $r \ge 1$ references (@&@ symbols), than @&R@ has type @T `*`&@$_{\color{red}2}\cdots$ @&@$_{\color{red}r}$, \ie @T@ pointer with $r-1$ references (@&@ symbols). 1877 1919 \item 1878 if @L@ is an lvalue of type @T &@$_1\cdots$ @&@$_l$, where $l \ge 0$ references (@&@ symbols), than @&L@ has type @T `*`&@$_{\color{red}1}\cdots$ @&@$_{\color{red}l}$, \ie @T@ pointer with $l$ references (@&@ symbols).1920 If @L@ is an lvalue of type @T &@$_1\cdots$ @&@$_l$, where $l \ge 0$ references (@&@ symbols), than @&L@ has type @T `*`&@$_{\color{red}1}\cdots$ @&@$_{\color{red}l}$, \ie @T@ pointer with $l$ references (@&@ symbols). 1879 1921 \end{itemize} 1880 Since pointers and references share the same internal representation, code using either is equally performant; in fact the \CFA compiler converts references to pointers internally, and the choice between them is made solely on convenience, \eg many pointer or value accesses. 1922 Since pointers and references share the same internal representation, code using either is equally performant; 1923 in fact, the \CFA compiler converts references into pointers internally, and the choice between them is made solely on convenience, \eg many pointer or value accesses. 1881 1924 1882 1925 By analogy to pointers, \CFA references also allow cv-qualifiers such as @const@: … … 1893 1936 There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, and return/temporary binding. 1894 1937 In each of these contexts, the address-of operator on the target lvalue is elided. 1895 The syntactic motivation is clearest when considering overloaded operator -assignment, \eg @int ?+=?(int &, int)@; given @int x, y@, the expected call syntax is @x += y@, not @&x += y@.1896 1897 More generally, this initialization of references from lvalues rather than pointers is an instance of a ``lvalue-to-reference'' conversion rather than an elision of the address-of operator;1938 The syntactic motivation is clearest when considering overloaded operator assignment, \eg @int ?+=?(int &, int)@; given @int x, y@, the expected call syntax is @x += y@, not @&x += y@. 1939 1940 More generally, this initialization of references from lvalues rather than pointers is an instance of an ``lvalue-to-reference'' conversion rather than an elision of the address-of operator; 1898 1941 this conversion is used in any context in \CFA where an implicit conversion is allowed. 1899 Similarly, use of athe value pointed to by a reference in an rvalue context can be thought of as a ``reference-to-rvalue'' conversion, and \CFA also includes a qualifier-adding ``reference-to-reference'' conversion, analogous to the @T *@ to @const T *@ conversion in standard C.1900 The final reference conversion included in \CFA is ``rvalue-to-reference'' conversion, implemented by means of an implicit temporary.1942 Similarly, use of the value pointed to by a reference in an rvalue context can be thought of as a ``reference-to-rvalue'' conversion, and \CFA also includes a qualifier-adding ``reference-to-reference'' conversion, analogous to the @T *@ to @const T *@ conversion in standard C. 1943 The final reference conversion included in \CFA is an ``rvalue-to-reference'' conversion, implemented by means of an implicit temporary. 1901 1944 When an rvalue is used to initialize a reference, it is instead used to initialize a hidden temporary value with the same lexical scope as the reference, and the reference is initialized to the address of this temporary. 1902 1945 \begin{cfa} … … 1906 1949 f( 3, x + y, (S){ 1.0, 7.0 }, (int [3]){ 1, 2, 3 } ); $\C{// pass rvalue to lvalue \(\Rightarrow\) implicit temporary}$ 1907 1950 \end{cfa} 1908 This allows complex values to be succinctly and efficiently passed to functions, without the syntactic overhead of explicit definition of a temporary variable or the runtime cost of pass-by-value. 1909 \CC allows a similar binding, but only for @const@ references; the more general semantics of \CFA are an attempt to avoid the \newterm{const poisoning} problem~\cite{Taylor10}, in which addition of a @const@ qualifier to one reference requires a cascading chain of added qualifiers. 1910 1911 1912 \subsection{Type Nesting} 1913 1914 Nested types provide a mechanism to organize associated types and refactor a subset of members into a named aggregate (\eg sub-aggregates @name@, @address@, @department@, within aggregate @employe@). 1915 Java nested types are dynamic (apply to objects), \CC are static (apply to the \lstinline[language=C++]@class@), and C hoists (refactors) nested types into the enclosing scope, meaning there is no need for type qualification. 1916 Since \CFA in not object-oriented, adopting dynamic scoping does not make sense; 1917 instead \CFA adopts \CC static nesting, using the member-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@'' (see Figure~\ref{f:TypeNestingQualification}). 1951 This allows complex values to be succinctly and efficiently passed to functions, without the syntactic overhead of the explicit definition of a temporary variable or the runtime cost of pass-by-value. 1952 \CC allows a similar binding, but only for @const@ references; the more general semantics of \CFA are an attempt to avoid the \newterm{const poisoning} problem~\cite{Taylor10}, in which the addition of a @const@ qualifier to one reference requires a cascading chain of added qualifiers. 1953 1954 1955 \subsection{Type nesting} 1956 1957 Nested types provide a mechanism to organize associated types and refactor a subset of members into a named aggregate (\eg subaggregates @name@, @address@, @department@, within aggregate @employe@). 1958 Java nested types are dynamic (apply to objects), \CC are static (apply to the \lstinline[language=C++]@class@), and C hoists (refactors) nested types into the enclosing scope, which means there is no need for type qualification. 1959 Since \CFA in not object oriented, adopting dynamic scoping does not make sense; 1960 instead, \CFA adopts \CC static nesting, using the member-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@'' (see Figure~\ref{f:TypeNestingQualification}). 1961 1918 1962 \begin{figure} 1919 1963 \centering 1964 \fontsize{9bp}{11bp}\selectfont\sf 1920 1965 \lstDeleteShortInline@% 1921 1966 \begin{tabular}{@{}l@{\hspace{3em}}l|l@{}} … … 1979 2024 \end{tabular} 1980 2025 \lstMakeShortInline@% 1981 \caption{Type Nesting / Qualification}2026 \caption{Type nesting / qualification} 1982 2027 \label{f:TypeNestingQualification} 2028 \vspace*{-8pt} 1983 2029 \end{figure} 2030 1984 2031 In the C left example, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope. 1985 2032 In the \CFA right example, the types are not hoisted and accessible. 1986 2033 1987 2034 1988 \subsection{Constructors and Destructors} 2035 \vspace*{-8pt} 2036 \subsection{Constructors and destructors} 1989 2037 \label{s:ConstructorsDestructors} 1990 2038 1991 One of the strengths (and weaknesses) of C is memory-management control, allowing resource release to be precisely specified versus unknown release with garbage-collected memory -management.2039 One of the strengths (and weaknesses) of C is memory-management control, allowing resource release to be precisely specified versus unknown release with garbage-collected memory management. 1992 2040 However, this manual approach is verbose, and it is useful to manage resources other than memory (\eg file handles) using the same mechanism as memory. 1993 \CC addresses these issues using R esource Aquisition Is Initialization (RAII), implemented by means of \newterm{constructor} and \newterm{destructor} functions;2041 \CC addresses these issues using RAII, implemented by means of \newterm{constructor} and \newterm{destructor} functions; 1994 2042 \CFA adopts constructors and destructors (and @finally@) to facilitate RAII. 1995 While constructors and destructors are a common feature of object-oriented programming -languages, they are an independent capability allowing \CFA to adopt them while retaining a procedural paradigm.1996 Specifically, \CFA constructors and destructors are denoted by name and first parameter -type versus name and nesting in an aggregate type.2043 While constructors and destructors are a common feature of object-oriented programming languages, they are an independent capability allowing \CFA to adopt them while retaining a procedural paradigm. 2044 Specifically, \CFA constructors and destructors are denoted by name and first parameter type versus name and nesting in an aggregate type. 1997 2045 Constructor calls seamlessly integrate with existing C initialization syntax, providing a simple and familiar syntax to C programmers and allowing constructor calls to be inserted into legacy C code with minimal code changes. 1998 2046 … … 2003 2051 The constructor and destructor have return type @void@, and the first parameter is a reference to the object type to be constructed or destructed. 2004 2052 While the first parameter is informally called the @this@ parameter, as in object-oriented languages, any variable name may be used. 2005 Both constructors and destructors allow additional parameters after the @this@ parameter for specifying values for initialization/de -initialization\footnote{2006 Destruction parameters are useful for specifying storage-management actions, such as de -initialize but not deallocate.}.2007 \begin{cfa} 2053 Both constructors and destructors allow additional parameters after the @this@ parameter for specifying values for initialization/deinitialization\footnote{ 2054 Destruction parameters are useful for specifying storage-management actions, such as deinitialize but not deallocate.}. 2055 \begin{cfa}[basicstyle=\linespread{0.9}\fontsize{9bp}{11bp}\selectfont\sf] 2008 2056 struct VLA { int size, * data; }; $\C{// variable length array of integers}$ 2009 2057 void ?{}( VLA & vla ) with ( vla ) { size = 10; data = alloc( size ); } $\C{// default constructor}$ … … 2014 2062 \end{cfa} 2015 2063 @VLA@ is a \newterm{managed type}\footnote{ 2016 A managed type affects the runtime environment versus a self-contained type.}: a type requiring a non -trivial constructor or destructor, or with a member of a managed type.2064 A managed type affects the runtime environment versus a self-contained type.}: a type requiring a nontrivial constructor or destructor, or with a member of a managed type. 2017 2065 A managed type is implicitly constructed at allocation and destructed at deallocation to ensure proper interaction with runtime resources, in this case, the @data@ array in the heap. 2018 For details of the code-generation placement of implicit constructor and destructor calls among complex executable statements see~\cite[\S~2.2]{Schluntz17}.2019 2020 \CFA also provides syntax for \newterm{initialization} and \newterm{copy} :2066 For details of the code-generation placement of implicit constructor and destructor calls among complex executable statements, see section~2.2 in the work of Schlintz~\cite{Schluntz17}. 2067 2068 \CFA also provides syntax for \newterm{initialization} and \newterm{copy}. \textcolor{blue}{REMOVE ``, as follows''} 2021 2069 \begin{cfa} 2022 2070 void ?{}( VLA & vla, int size, char fill = '\0' ) { $\C{// initialization}$ … … 2027 2075 } 2028 2076 \end{cfa} 2029 (Note ,the example is purposely simplified using shallow-copy semantics.)2030 An initialization constructor -call has the same syntax as a C initializer, except the initialization values are passed as arguments to a matching constructor (number and type of paremeters).2077 (Note that the example is purposely simplified using shallow-copy semantics.) 2078 An initialization constructor call has the same syntax as a C initializer, except that the initialization values are passed as arguments to a matching constructor (number and type of parameters). 2031 2079 \begin{cfa} 2032 2080 VLA va = `{` 20, 0 `}`, * arr = alloc()`{` 5, 0 `}`; 2033 2081 \end{cfa} 2034 Note , the use of a \newterm{constructor expression} to initialize the storage from the dynamic storage-allocation.2082 Note the use of a \newterm{constructor expression} to initialize the storage from the dynamic storage allocation. 2035 2083 Like \CC, the copy constructor has two parameters, the second of which is a value parameter with the same type as the first parameter; 2036 2084 appropriate care is taken to not recursively call the copy constructor when initializing the second parameter. … … 2038 2086 \CFA constructors may be explicitly called, like Java, and destructors may be explicitly called, like \CC. 2039 2087 Explicit calls to constructors double as a \CC-style \emph{placement syntax}, useful for construction of members in user-defined constructors and reuse of existing storage allocations. 2040 Like the other operators in \CFA, there is a concise syntax for constructor/destructor function calls :2088 Like the other operators in \CFA, there is a concise syntax for constructor/destructor function calls. 2041 2089 \begin{cfa} 2042 2090 { … … 2054 2102 To provide a uniform type interface for @otype@ polymorphism, the \CFA compiler automatically generates a default constructor, copy constructor, assignment operator, and destructor for all types. 2055 2103 These default functions can be overridden by user-generated versions. 2056 For compatibility with the standard behavio ur of C, the default constructor and destructor for all basic, pointer, and reference types do nothing, whilethe copy constructor and assignment operator are bitwise copies;2057 if default zero -initialization is desired, the default constructors can be overridden.2104 For compatibility with the standard behavior of C, the default constructor and destructor for all basic, pointer, and reference types do nothing, whereas the copy constructor and assignment operator are bitwise copies; 2105 if default zero initialization is desired, the default constructors can be overridden. 2058 2106 For user-generated types, the four functions are also automatically generated. 2059 2107 @enum@ types are handled the same as their underlying integral type, and unions are also bitwise copied and no-op initialized and destructed. 2060 2108 For compatibility with C, a copy constructor from the first union member type is also defined. 2061 For @struct@ types, each of the four functions areimplicitly defined to call their corresponding functions on each member of the struct.2062 To better simulate the behavio ur of C initializers, a set of \newterm{member constructors} is also generated for structures.2063 A constructor is generated for each non -empty prefix of a structure's member-list to copy-construct the members passed as parameters and default-construct the remaining members.2109 For @struct@ types, each of the four functions is implicitly defined to call their corresponding functions on each member of the struct. 2110 To better simulate the behavior of C initializers, a set of \newterm{member constructors} is also generated for structures. 2111 A constructor is generated for each nonempty prefix of a structure's member list to copy-construct the members passed as parameters and default-construct the remaining members. 2064 2112 To allow users to limit the set of constructors available for a type, when a user declares any constructor or destructor, the corresponding generated function and all member constructors for that type are hidden from expression resolution; 2065 similarly, the generated default constructor is hidden upon declaration of any constructor.2113 similarly, the generated default constructor is hidden upon the declaration of any constructor. 2066 2114 These semantics closely mirror the rule for implicit declaration of constructors in \CC\cite[p.~186]{ANSI98:C++}. 2067 2115 2068 In some circumstance programmers may not wish to have implicit constructor and destructor generation and calls. 2069 In these cases, \CFA provides the initialization syntax \lstinline|S x `@=` {}|, and the object becomes unmanaged, so implicit constructor and destructor calls are not generated. 2116 In some circumstance, programmers may not wish to have implicit constructor and destructor generation and calls. 2117 In these cases, \CFA provides the initialization syntax \lstinline|S x `@=` {}|, and the object becomes unmanaged; 2118 hence, implicit \mbox{constructor} and destructor calls are not generated. 2070 2119 Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics. 2071 2120 The same syntax can be used in a compound literal, \eg \lstinline|a = (VLA)`@`{ 0, 0x0 }|, to create a C-style literal. 2072 The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert to implicit initialization.2121 The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert into implicit initialization. 2073 2122 2074 2123 … … 2078 2127 \section{Literals} 2079 2128 2080 C already includes limited polymorphism for literals -- @0@ can be either an integer or a pointer literal, depending on context, whilethe syntactic forms of literals of the various integer and float types are very similar, differing from each other only in suffix.2081 In keeping with the general \CFA approach of adding features while respecting the ``C -style'' of doing things, C's polymorphic constants and typed literal syntax are extended to interoperate with user-defined types, while maintaining a backwards-compatible semantics.2129 C already includes limited polymorphism for literals---@0@ can be either an integer or a pointer literal, depending on context, whereas the syntactic forms of literals of the various integer and float types are very similar, differing from each other only in suffix. 2130 In keeping with the general \CFA approach of adding features while respecting the ``C style'' of doing things, C's polymorphic constants and typed literal syntax are extended to interoperate with user-defined types, while maintaining a backward-compatible semantics. 2082 2131 2083 2132 A simple example is allowing the underscore, as in Ada, to separate prefixes, digits, and suffixes in all \CFA constants, \eg @0x`_`1.ffff`_`ffff`_`p`_`128`_`l@, where the underscore is also the standard separator in C identifiers. 2084 \CC uses a single quote as a separator but it is restricted among digits, precluding its use in the literal prefix or suffix, \eg @0x1.ffff@@`'@@ffffp128l@, and causes problems with most IDEs, which must be extended to deal with this alternate use of the single quote.2133 \CC uses a single quote as a separator, but it is restricted among digits, precluding its use in the literal prefix or suffix, \eg @0x1.ffff@@`'@@ffffp128l@, and causes problems with most \textcolor{blue}{Q2 CHANGE ``IDEs'' TO ``integrated development environments (IDEs)''}, which must be extended to deal with this alternate use of the single quote. 2085 2134 2086 2135 … … 2125 2174 2126 2175 In C, @0@ has the special property that it is the only ``false'' value; 2127 by the standard, any value that compares equal to @0@ is false, wh ileany value that compares unequal to @0@ is true.2128 As such, an expression @x@ in any boolean context (such as the condition of an @if@ or @while@ statement, or the arguments to @&&@, @||@, or @?:@\,) can be rewritten as @x != 0@ without changing its semantics.2176 by the standard, any value that compares equal to @0@ is false, whereas any value that compares unequal to @0@ is true. 2177 As such, an expression @x@ in any Boolean context (such as the condition of an @if@ or @while@ statement, or the arguments to @&&@, @||@, or @?:@\,) can be rewritten as @x != 0@ without changing its semantics. 2129 2178 Operator overloading in \CFA provides a natural means to implement this truth-value comparison for arbitrary types, but the C type system is not precise enough to distinguish an equality comparison with @0@ from an equality comparison with an arbitrary integer or pointer. 2130 2179 To provide this precision, \CFA introduces a new type @zero_t@ as the type of literal @0@ (somewhat analagous to @nullptr_t@ and @nullptr@ in \CCeleven); … … 2132 2181 With this addition, \CFA rewrites @if (x)@ and similar expressions to @if ( (x) != 0 )@ or the appropriate analogue, and any type @T@ is ``truthy'' by defining an operator overload @int ?!=?( T, zero_t )@. 2133 2182 \CC makes types truthy by adding a conversion to @bool@; 2134 prior to the addition of explicit cast operators in \CCeleven, this approach had the pitfall of making truthy types transitively convert ableto any numeric type;2183 prior to the addition of explicit cast operators in \CCeleven, this approach had the pitfall of making truthy types transitively convertible into any numeric type; 2135 2184 \CFA avoids this issue. 2136 2185 … … 2143 2192 2144 2193 2145 \subsection{User Literals}2194 \subsection{User literals} 2146 2195 2147 2196 For readability, it is useful to associate units to scale literals, \eg weight (stone, pound, kilogram) or time (seconds, minutes, hours). 2148 The left of Figure~\ref{f:UserLiteral} shows the \CFA alternative call -syntax (postfix: literal argument before function name), using the backquote, to convert basic literals into user literals.2197 The left of Figure~\ref{f:UserLiteral} shows the \CFA alternative call syntax (postfix: literal argument before function name), using the backquote, to convert basic literals into user literals. 2149 2198 The backquote is a small character, making the unit (function name) predominate. 2150 For examples, the multi -precision integer-type in Section~\ref{s:MultiPrecisionIntegers} has user literals:2199 For examples, the multiprecision integer type in Section~\ref{s:MultiPrecisionIntegers} has the following user literals. 2151 2200 {\lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}} 2152 2201 \begin{cfa} … … 2154 2203 y = "12345678901234567890123456789"|`mp| + "12345678901234567890123456789"|`mp|; 2155 2204 \end{cfa} 2156 Because \CFA uses a standard function, all types and literals are applicable, as well as overloading and conversions, where @?`@ denotes a postfix-function name and @`@denotes a postfix-function call.2205 Because \CFA uses a standard function, all types and literals are applicable, as well as overloading and conversions, where @?`@ \textcolor{blue}{USE CHARACTER \lstinline@`@ NOT \textsf{'}} denotes a postfix-function name and @`@ \textcolor{blue}{USE CHARACTER \lstinline@`@ NOT `} denotes a postfix-function call. 2157 2206 }% 2158 2207 \begin{cquote} … … 2196 2245 \end{cquote} 2197 2246 2198 The right of Figure~\ref{f:UserLiteral} shows the equivalent \CC version using the underscore for the call -syntax.2247 The right of Figure~\ref{f:UserLiteral} shows the equivalent \CC version using the underscore for the call syntax. 2199 2248 However, \CC restricts the types, \eg @unsigned long long int@ and @long double@ to represent integral and floating literals. 2200 2249 After which, user literals must match (no conversions); … … 2203 2252 \begin{figure} 2204 2253 \centering 2254 \fontsize{9bp}{11bp}\selectfont 2205 2255 \lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}} 2206 2256 \lstDeleteShortInline@% … … 2258 2308 \end{tabular} 2259 2309 \lstMakeShortInline@% 2260 \caption{User Literal}2310 \caption{User literal} 2261 2311 \label{f:UserLiteral} 2262 2312 \end{figure} … … 2266 2316 \label{sec:libraries} 2267 2317 2268 As stated in Section~\ref{sec:poly-fns}, \CFA inherits a large corpus of library code, where other programming languages must rewrite or provide fragile inter -language communication with C.2318 As stated in Section~\ref{sec:poly-fns}, \CFA inherits a large corpus of library code, where other programming languages must rewrite or provide fragile interlanguage communication with C. 2269 2319 \CFA has replacement libraries condensing hundreds of existing C names into tens of \CFA overloaded names, all without rewriting the actual computations. 2270 In many cases, the interface is an inline wrapper providing overloading during compilation but zero cost at runtime.2320 In many cases, the interface is an inline wrapper providing overloading during compilation but of zero cost at runtime. 2271 2321 The following sections give a glimpse of the interface reduction to many C libraries. 2272 2322 In many cases, @signed@/@unsigned@ @char@, @short@, and @_Complex@ functions are available (but not shown) to ensure expression computations remain in a single type, as conversions can distort results. … … 2276 2326 2277 2327 C library @limits.h@ provides lower and upper bound constants for the basic types. 2278 \CFA name overloading is used to condense these typed constants , \eg:2328 \CFA name overloading is used to condense these typed constants. 2279 2329 \begin{cquote} 2280 2330 \lstDeleteShortInline@% … … 2295 2345 \lstMakeShortInline@% 2296 2346 \end{cquote} 2297 The result is a significant reduction in names to access typed constants , \eg:2347 The result is a significant reduction in names to access typed constants. \textcolor{blue}{REMOVE ``, as follows.''} 2298 2348 \begin{cquote} 2299 2349 \lstDeleteShortInline@% … … 2321 2371 2322 2372 C library @math.h@ provides many mathematical functions. 2323 \CFA function overloading is used to condense these mathematical functions , \eg:2373 \CFA function overloading is used to condense these mathematical functions. 2324 2374 \begin{cquote} 2325 2375 \lstDeleteShortInline@% … … 2340 2390 \lstMakeShortInline@% 2341 2391 \end{cquote} 2342 The result is a significant reduction in names to access math functions , \eg:2392 The result is a significant reduction in names to access math functions. \textcolor{blue}{REMOVE ``, as follows.''} 2343 2393 \begin{cquote} 2344 2394 \lstDeleteShortInline@% … … 2359 2409 \lstMakeShortInline@% 2360 2410 \end{cquote} 2361 While \Celeven has type-generic math ~\cite[\S~7.25]{C11}in @tgmath.h@ to provide a similar mechanism, these macros are limited, matching a function name with a single set of floating type(s).2411 While \Celeven has type-generic math (see section~7.25 of the ISO/IEC 9899\cite{C11}) in @tgmath.h@ to provide a similar mechanism, these macros are limited, matching a function name with a single set of floating type(s). 2362 2412 For example, it is impossible to overload @atan@ for both one and two arguments; 2363 instead the names @atan@ and @atan2@ are required (see Section~\ref{s:NameOverloading}).2364 The key observation is that only a restricted set of type-generic macros areprovided for a limited set of function names, which do not generalize across the type system, as in \CFA.2413 instead, the names @atan@ and @atan2@ are required (see Section~\ref{s:NameOverloading}). 2414 The key observation is that only a restricted set of type-generic macros is provided for a limited set of function names, which do not generalize across the type system, as in \CFA. 2365 2415 2366 2416 … … 2368 2418 2369 2419 C library @stdlib.h@ provides many general functions. 2370 \CFA function overloading is used to condense these utility functions , \eg:2420 \CFA function overloading is used to condense these utility functions. 2371 2421 \begin{cquote} 2372 2422 \lstDeleteShortInline@% … … 2387 2437 \lstMakeShortInline@% 2388 2438 \end{cquote} 2389 The result is a significant reduction in names to access utility functions, \eg:2439 The result is a significant reduction in names to access the utility functions. \textcolor{blue}{REMOVE ``, as follows.''} 2390 2440 \begin{cquote} 2391 2441 \lstDeleteShortInline@% … … 2406 2456 \lstMakeShortInline@% 2407 2457 \end{cquote} 2408 In addit on, there are polymorphic functions, like @min@ and @max@, that work on any type with operators@?<?@ or @?>?@.2409 2410 The following shows one example where \CFA \ emph{extends} an existing standard C interface to reduce complexity and provide safety.2411 C/\Celeven provide a number of complex and overlapping storage-management operation to support the following capabilities:2412 \begin{ description}%[topsep=3pt,itemsep=2pt,parsep=0pt]2458 In addition, there are polymorphic functions, like @min@ and @max@, that work on any type with operator @?<?@ or @?>?@. 2459 2460 The following shows one example where \CFA \textcolor{blue}{ADD SPACE} \emph{extends} an existing standard C interface to reduce complexity and provide safety. 2461 C/\Celeven provide a number of complex and overlapping storage-management operations to support the following capabilities. 2462 \begin{list}{}{\itemsep=0pt\parsep=0pt\labelwidth=0pt\leftmargin\parindent\itemindent-\leftmargin\let\makelabel\descriptionlabel} 2413 2463 \item[fill] 2414 2464 an allocation with a specified character. 2415 2465 \item[resize] 2416 2466 an existing allocation to decrease or increase its size. 2417 In either case, new storage may or may not be allocated and, if there is a new allocation, as much data from the existing allocation iscopied.2467 In either case, new storage may or may not be allocated, and if there is a new allocation, as much data from the existing allocation are copied. 2418 2468 For an increase in storage size, new storage after the copied data may be filled. 2469 \newpage 2419 2470 \item[align] 2420 2471 an allocation on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes. … … 2422 2473 allocation with a specified number of elements. 2423 2474 An array may be filled, resized, or aligned. 2424 \end{ description}2425 Table~\ref{t:StorageManagementOperations} shows the capabilities provided by C/\Celeven allocation -functions and how all the capabilities can be combined into two \CFA functions.2426 \CFA storage-management functions extend the C equivalents by overloading, providing shallow type -safety, and removing the need to specify the base allocation-size.2427 Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage -allocation performing the same operations with the same type safety.2475 \end{list} 2476 Table~\ref{t:StorageManagementOperations} shows the capabilities provided by C/\Celeven allocation functions and how all the capabilities can be combined into two \CFA functions. 2477 \CFA storage-management functions extend the C equivalents by overloading, providing shallow type safety, and removing the need to specify the base allocation size. 2478 Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage allocation performing the same operations with the same type safety. 2428 2479 2429 2480 \begin{table} 2430 \caption{Storage- Management Operations}2481 \caption{Storage-management operations} 2431 2482 \label{t:StorageManagementOperations} 2432 2483 \centering 2433 2484 \lstDeleteShortInline@% 2434 2485 \lstMakeShortInline~% 2435 \begin{tabular}{@{}r|r|l|l|l|l@{}} 2436 \multicolumn{1}{c}{}& & \multicolumn{1}{c|}{fill} & resize & align & array \\ 2437 \hline 2486 \begin{tabular}{@{}rrllll@{}} 2487 \multicolumn{1}{c}{}& & \multicolumn{1}{c}{fill} & resize & align & array \\ 2438 2488 C & ~malloc~ & no & no & no & no \\ 2439 2489 & ~calloc~ & yes (0 only) & no & no & yes \\ … … 2441 2491 & ~memalign~ & no & no & yes & no \\ 2442 2492 & ~posix_memalign~ & no & no & yes & no \\ 2443 \hline2444 2493 C11 & ~aligned_alloc~ & no & no & yes & no \\ 2445 \hline2446 2494 \CFA & ~alloc~ & yes/copy & no/yes & no & yes \\ 2447 2495 & ~align_alloc~ & yes & no & yes & yes \\ … … 2453 2501 \begin{figure} 2454 2502 \centering 2503 \fontsize{9bp}{11bp}\selectfont 2455 2504 \begin{cfa}[aboveskip=0pt,xleftmargin=0pt] 2456 2505 size_t dim = 10; $\C{// array dimension}$ … … 2490 2539 \end{tabular} 2491 2540 \lstMakeShortInline@% 2492 \caption{\CFA versus C Storage-Allocation}2541 \caption{\CFA versus C storage allocation} 2493 2542 \label{f:StorageAllocation} 2494 2543 \end{figure} 2495 2544 2496 2545 Variadic @new@ (see Section~\ref{sec:variadic-tuples}) cannot support the same overloading because extra parameters are for initialization. 2497 Hence, there are @new@ and @anew@ functions for single and array variables, and the fill value is the arguments to the constructor , \eg:2546 Hence, there are @new@ and @anew@ functions for single and array variables, and the fill value is the arguments to the constructor. 2498 2547 \begin{cfa} 2499 2548 struct S { int i, j; }; … … 2502 2551 S * as = anew( dim, 2, 3 ); $\C{// each array element initialized to 2, 3}$ 2503 2552 \end{cfa} 2504 Note ,\CC can only initialize array elements via the default constructor.2505 2506 Finally, the \CFA memory -allocator has \newterm{sticky properties} for dynamic storage: fill and alignment are remembered with an object's storage in the heap.2553 Note that \CC can only initialize array elements via the default constructor. 2554 2555 Finally, the \CFA memory allocator has \newterm{sticky properties} for dynamic storage: fill and alignment are remembered with an object's storage in the heap. 2507 2556 When a @realloc@ is performed, the sticky properties are respected, so that new storage is correctly aligned and initialized with the fill character. 2508 2557 … … 2511 2560 \label{s:IOLibrary} 2512 2561 2513 The goal of \CFA I/O is to simplify the common cases, while fully supporting polymorphism and user 2562 The goal of \CFA I/O is to simplify the common cases, while fully supporting polymorphism and user-defined types in a consistent way. 2514 2563 The approach combines ideas from \CC and Python. 2515 2564 The \CFA header file for the I/O library is @fstream@. … … 2540 2589 \lstMakeShortInline@% 2541 2590 \end{cquote} 2542 The \CFA form has half the characters of the \CC form ,and is similar to Python I/O with respect to implicit separators.2591 The \CFA form has half the characters of the \CC form and is similar to Python I/O with respect to implicit separators. 2543 2592 Similar simplification occurs for tuple I/O, which prints all tuple values separated by ``\lstinline[showspaces=true]@, @''. 2544 2593 \begin{cfa} … … 2573 2622 \lstMakeShortInline@% 2574 2623 \end{cquote} 2575 There is a weak similarity between the \CFA logical-or operator and the Shell pipe -operator for moving data, where data flows in the correct direction for input butthe opposite direction for output.2624 There is a weak similarity between the \CFA logical-or operator and the Shell pipe operator for moving data, where data flow in the correct direction for input but in the opposite direction for output. 2576 2625 \begin{comment} 2577 2626 The implicit separator character (space/blank) is a separator not a terminator. … … 2594 2643 \end{itemize} 2595 2644 \end{comment} 2596 There are functions to set and get the separator string ,and manipulators to toggle separation on and off in the middle of output.2597 2598 2599 \subsection{Multi -precision Integers}2645 There are functions to set and get the separator string and manipulators to toggle separation on and off in the middle of output. 2646 2647 2648 \subsection{Multiprecision integers} 2600 2649 \label{s:MultiPrecisionIntegers} 2601 2650 2602 \CFA has an interface to the GMP multi-precision signed-integers~\cite{GMP}, similar to the \CC interface provided by GMP.2603 The \CFA interface wraps GMP functions into operator functions to make programming with multi -precision integers identical to using fixed-sized integers.2604 The \CFA type name for multi -precision signed-integers is @Int@ and the header file is @gmp@.2605 Figure~\ref{f:GMPInterface} shows a multi -precision factorial-program contrasting the GMP interface in \CFA and C.2606 2607 \begin{figure} 2651 \CFA has an interface to the \textcolor{blue}{Q3 CHANGE ``GMP multiprecision'' TO ``GNU multiple precision (GMP)''} signed integers~\cite{GMP}, similar to the \CC interface provided by GMP. 2652 The \CFA interface wraps GMP functions into operator functions to make programming with multiprecision integers identical to using fixed-sized integers. 2653 The \CFA type name for multiprecision signed integers is @Int@ and the header file is @gmp@. 2654 Figure~\ref{f:GMPInterface} shows a multiprecision factorial program contrasting the GMP interface in \CFA and C. 2655 2656 \begin{figure}[b] 2608 2657 \centering 2658 \fontsize{9bp}{11bp}\selectfont 2609 2659 \lstDeleteShortInline@% 2610 2660 \begin{tabular}{@{}l@{\hspace{3\parindentlnth}}l@{}} … … 2637 2687 \end{tabular} 2638 2688 \lstMakeShortInline@% 2639 \caption{GMP Interface \CFA versus C}2689 \caption{GMP interface \CFA versus C} 2640 2690 \label{f:GMPInterface} 2641 2691 \end{figure} 2642 2692 2643 2693 2694 \vspace{-4pt} 2644 2695 \section{Polymorphism Evaluation} 2645 2696 \label{sec:eval} … … 2650 2701 % Though \CFA provides significant added functionality over C, these features have a low runtime penalty. 2651 2702 % In fact, it is shown that \CFA's generic programming can enable faster runtime execution than idiomatic @void *@-based C code. 2652 The experiment is a set of generic-stack micro -benchmarks~\cite{CFAStackEvaluation} in C, \CFA, and \CC (see implementations in Appendix~\ref{sec:BenchmarkStackImplementations}).2703 The experiment is a set of generic-stack microbenchmarks~\cite{CFAStackEvaluation} in C, \CFA, and \CC (see implementations in Appendix~\ref{sec:BenchmarkStackImplementations}). 2653 2704 Since all these languages share a subset essentially comprising standard C, maximal-performance benchmarks should show little runtime variance, differing only in length and clarity of source code. 2654 2705 A more illustrative comparison measures the costs of idiomatic usage of each language's features. 2655 Figure~\ref{fig:BenchmarkTest} shows the \CFA benchmark tests for a generic stack based on a singly linked -list.2706 Figure~\ref{fig:BenchmarkTest} shows the \CFA benchmark tests for a generic stack based on a singly linked list. 2656 2707 The benchmark test is similar for the other languages. 2657 2708 The experiment uses element types @int@ and @pair(short, char)@, and pushes $N=40M$ elements on a generic stack, copies the stack, clears one of the stacks, and finds the maximum value in the other stack. 2658 2709 2659 2710 \begin{figure} 2711 \fontsize{9bp}{11bp}\selectfont 2660 2712 \begin{cfa}[xleftmargin=3\parindentlnth,aboveskip=0pt,belowskip=0pt] 2661 2713 int main() { … … 2677 2729 } 2678 2730 \end{cfa} 2679 \caption{\protect\CFA Benchmark Test}2731 \caption{\protect\CFA benchmark test} 2680 2732 \label{fig:BenchmarkTest} 2733 \vspace*{-10pt} 2681 2734 \end{figure} 2682 2735 2683 The structure of each benchmark implemented is :C with @void *@-based polymorphism, \CFA with parametric polymorphism, \CC with templates, and \CC using only class inheritance for polymorphism, called \CCV.2736 The structure of each benchmark implemented is C with @void *@-based polymorphism, \CFA with parametric polymorphism, \CC with templates, and \CC using only class inheritance for polymorphism, called \CCV. 2684 2737 The \CCV variant illustrates an alternative object-oriented idiom where all objects inherit from a base @object@ class, mimicking a Java-like interface; 2685 hence runtime checks are necessary to safely down-cast objects.2686 The most notable difference among the implementations is in memory layout of generic types: \CFA and \CC inline the stack and pair elements into corresponding list and pair nodes, wh ile C and \CCV lack such a capability and instead must store generic objects via pointers to separately-allocated objects.2687 Note , the C benchmark uses unchecked casts as C has no runtime mechanism to perform such checks, while \CFA and \CC provide type-safety statically.2738 hence, runtime checks are necessary to safely downcast objects. 2739 The most notable difference among the implementations is in memory layout of generic types: \CFA and \CC inline the stack and pair elements into corresponding list and pair nodes, whereas C and \CCV lack such capability and, instead, must store generic objects via pointers to separately allocated objects. 2740 Note that the C benchmark uses unchecked casts as C has no runtime mechanism to perform such checks, whereas \CFA and \CC provide type safety statically. 2688 2741 2689 2742 Figure~\ref{fig:eval} and Table~\ref{tab:eval} show the results of running the benchmark in Figure~\ref{fig:BenchmarkTest} and its C, \CC, and \CCV equivalents. 2690 The graph plots the median of 5consecutive runs of each program, with an initial warm-up run omitted.2691 All code is compiled at \texttt{-O2} by gcc or g++ 6.4.0, with all \CC code compiled as \CCfourteen. 2692 The benchmarks are run on an Ubuntu 16.04 workstation with 16 GB of RAM and a 6-core AMD FX-6300 CPU with 3.5 GHz maximum clock frequency.2743 The graph plots the median of five consecutive runs of each program, with an initial warm-up run omitted. 2744 All code is compiled at \texttt{-O2} by gcc or g++ 6.4.0, with all \CC code compiled as \CCfourteen. \textcolor{blue}{CHANGE ``\CC{}fourteen'' TO ``\CCfourteen''} 2745 The benchmarks are run on an Ubuntu 16.04 workstation with 16 GB of RAM and a 6-core AMD FX-6300 CPU with 3.5 GHz \textcolor{blue}{REMOVE ``of''} maximum clock frequency. 2693 2746 2694 2747 \begin{figure} 2695 2748 \centering 2696 \ input{timing}2697 \caption{Benchmark Timing Results (smaller is better)}2749 \resizebox{0.7\textwidth}{!}{\input{timing}} 2750 \caption{Benchmark timing results (smaller is better)} 2698 2751 \label{fig:eval} 2752 \vspace*{-10pt} 2699 2753 \end{figure} 2700 2754 2701 2755 \begin{table} 2756 \vspace*{-10pt} 2702 2757 \caption{Properties of benchmark code} 2703 2758 \label{tab:eval} 2704 2759 \centering 2760 \vspace*{-4pt} 2705 2761 \newcommand{\CT}[1]{\multicolumn{1}{c}{#1}} 2706 \begin{tabular}{ rrrrr}2707 & \CT{C} & \CT{\CFA} & \CT{\CC} & \CT{\CCV} \\ \hline2708 maximum memory usage (MB) & 10 ,001 & 2,502 & 2,503 & 11,253 \\2762 \begin{tabular}{lrrrr} 2763 & \CT{C} & \CT{\CFA} & \CT{\CC} & \CT{\CCV} \\ 2764 maximum memory usage (MB) & 10\,001 & 2\,502 & 2\,503 & 11\,253 \\ 2709 2765 source code size (lines) & 201 & 191 & 125 & 294 \\ 2710 2766 redundant type annotations (lines) & 27 & 0 & 2 & 16 \\ 2711 2767 binary size (KB) & 14 & 257 & 14 & 37 \\ 2712 2768 \end{tabular} 2769 \vspace*{-16pt} 2713 2770 \end{table} 2714 2771 2715 The C and \CCV variants are generally the slowest with the largest memory footprint, because of their less-efficient memory layout and the pointer-indirection necessary to implement generic types;2772 The C and \CCV variants are generally the slowest with the largest memory footprint, due to their less-efficient memory layout and the pointer indirection necessary to implement generic types; 2716 2773 this inefficiency is exacerbated by the second level of generic types in the pair benchmarks. 2717 By contrast, the \CFA and \CC variants run in roughly equivalent time for both the integer and pair because of equivalent storage layout, with the inlined libraries (\ie no separate compilation) and greater maturity of the \CC compiler contributing to its lead.2718 \CCV is slower than C largely due to the cost of runtime type -checking of down-casts (implemented with @dynamic_cast@);2774 By contrast, the \CFA and \CC variants run in roughly equivalent time for both the integer and pair because of the equivalent storage layout, with the inlined libraries (\ie no separate compilation) and greater maturity of the \CC compiler contributing to its lead. 2775 \CCV is slower than C largely due to the cost of runtime type checking of downcasts (implemented with @dynamic_cast@). 2719 2776 The outlier for \CFA, pop @pair@, results from the complexity of the generated-C polymorphic code. 2720 2777 The gcc compiler is unable to optimize some dead code and condense nested calls; … … 2722 2779 Finally, the binary size for \CFA is larger because of static linking with the \CFA libraries. 2723 2780 2724 \CFA is also competitive in terms of source code size, measured as a proxy for programmer effort. The line counts in Table~\ref{tab:eval} include implementations of @pair@ and @stack@ types for all four languages for purposes of direct comparison, though it should be noted that \CFA and \CC have pre-written data structures in their standard libraries that programmers would generally use instead. Use of these standard library types has minimal impact on the performance benchmarks, but shrinks the \CFA and \CC benchmarks to 39 and 42 lines, respectively.2781 \CFA is also competitive in terms of source code size, measured as a proxy for programmer effort. The line counts in Table~\ref{tab:eval} include implementations of @pair@ and @stack@ types for all four languages for purposes of direct comparison, although it should be noted that \CFA and \CC have prewritten data structures in their standard libraries that programmers would generally use instead. Use of these standard library types has minimal impact on the performance benchmarks, but shrinks the \CFA and \CC benchmarks to 39 and 42 lines, respectively. 2725 2782 The difference between the \CFA and \CC line counts is primarily declaration duplication to implement separate compilation; a header-only \CFA library would be similar in length to the \CC version. 2726 On the other hand, C does not have a generic collections -library in its standard distribution, resulting in frequent reimplementation of such collection types by C programmers.2727 \CCV does not use the \CC standard template library by construction , and in factincludes the definition of @object@ and wrapper classes for @char@, @short@, and @int@ in its line count, which inflates this count somewhat, as an actual object-oriented language would include these in the standard library;2783 On the other hand, C does not have a generic collections library in its standard distribution, resulting in frequent reimplementation of such collection types by C programmers. 2784 \CCV does not use the \CC standard template library by construction and, in fact, includes the definition of @object@ and wrapper classes for @char@, @short@, and @int@ in its line count, which inflates this count somewhat, as an actual object-oriented language would include these in the standard library; 2728 2785 with their omission, the \CCV line count is similar to C. 2729 2786 We justify the given line count by noting that many object-oriented languages do not allow implementing new interfaces on library types without subclassing or wrapper types, which may be similarly verbose. 2730 2787 2731 Line -count is a fairly rough measure of code complexity;2732 another important factor is how much type information the programmer must specify manually, especially where that information is not compiler -checked.2733 Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs ,and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts, \eg @object@ to @integer@ when popping a stack.2788 Line count is a fairly rough measure of code complexity; 2789 another important factor is how much type information the programmer must specify manually, especially where that information is not compiler checked. 2790 Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts, \eg @object@ to @integer@ when popping a stack. 2734 2791 To quantify this manual typing, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is respecified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression. 2735 The \CC benchmark uses two redundant type annotations to create a new stack nodes, wh ilethe C and \CCV benchmarks have several such annotations spread throughout their code.2792 The \CC benchmark uses two redundant type annotations to create a new stack nodes, whereas the C and \CCV benchmarks have several such annotations spread throughout their code. 2736 2793 The \CFA benchmark is able to eliminate all redundant type annotations through use of the polymorphic @alloc@ function discussed in Section~\ref{sec:libraries}. 2737 2794 2738 We conjecture these results scale across most generic data-types as the underlying polymorphism implement is constant. 2739 2740 2795 We conjecture that these results scale across most generic data types as the underlying polymorphism implement is constant. 2796 2797 2798 \vspace*{-8pt} 2741 2799 \section{Related Work} 2742 2800 \label{s:RelatedWork} … … 2754 2812 \CC provides three disjoint polymorphic extensions to C: overloading, inheritance, and templates. 2755 2813 The overloading is restricted because resolution does not use the return type, inheritance requires learning object-oriented programming and coping with a restricted nominal-inheritance hierarchy, templates cannot be separately compiled resulting in compilation/code bloat and poor error messages, and determining how these mechanisms interact and which to use is confusing. 2756 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.2814 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. 2757 2815 The key mechanism to support separate compilation is \CFA's \emph{explicit} use of assumed type properties. 2758 Until \CC concepts~\cite{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way to specifythe requirements of a generic function beyond compilation errors during template expansion;2816 Until \CC concepts~\cite{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way of specifying the requirements of a generic function beyond compilation errors during template expansion; 2759 2817 furthermore, \CC concepts are restricted to template polymorphism. 2760 2818 2761 2819 Cyclone~\cite{Grossman06} also provides capabilities for polymorphic functions and existential types, similar to \CFA's @forall@ functions and generic types. 2762 Cyclone existential types can include function pointers in a construct similar to a virtual function -table, but these pointers must be explicitly initialized at some point in the code,a tedious and potentially error-prone process.2820 Cyclone existential types can include function pointers in a construct similar to a virtual function table, but these pointers must be explicitly initialized at some point in the code, which is a tedious and potentially error-prone process. 2763 2821 Furthermore, Cyclone's polymorphic functions and types are restricted to abstraction over types with the same layout and calling convention as @void *@, \ie only pointer types and @int@. 2764 2822 In \CFA terms, all Cyclone polymorphism must be dtype-static. 2765 2823 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. 2766 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. 2824 Smith and Volpano~\cite{Smith98} present Polymorphic C, an ML dialect with polymorphic functions, C-like syntax, and pointer types; 2825 it lacks many of C's features, most notably structure types, and hence, is not a practical C replacement. 2767 2826 2768 2827 Objective-C~\cite{obj-c-book} is an industrially successful extension to C. 2769 However, Objective-C is a radical departure from C, using an object-oriented model with message -passing.2828 However, Objective-C is a radical departure from C, using an object-oriented model with message passing. 2770 2829 Objective-C did not support type-checked generics until recently \cite{xcode7}, historically using less-efficient runtime checking of object types. 2771 The GObject~\cite{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage -collection to C;2772 these features are more intrusive additions than those provided by \CFA, in addition to the runtime overhead of reference -counting.2773 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.2774 Java~\cite{Java8} included generic types in Java~5, which are type -checked at compilation and type-erased at runtime, similar to \CFA's.2775 However, in Java, each object carries its own table of method pointers, wh ile\CFA passes the method pointers separately to maintain a C-compatible layout.2830 The GObject~\cite{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage collection to C; 2831 these features are more intrusive additions than those provided by \CFA, in addition to the runtime overhead of reference counting. 2832 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. 2833 Java~\cite{Java8} included generic types in Java~5, which are type checked at compilation and type erased at runtime, similar to \CFA's. 2834 However, in Java, each object carries its own table of method pointers, whereas \CFA passes the method pointers separately to maintain a C-compatible layout. 2776 2835 Java is also a garbage-collected, object-oriented language, with the associated resource usage and C-interoperability burdens. 2777 2836 2778 D~\cite{D}, Go, and Rust~\cite{Rust} are modern , compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in D and Goand \emph{traits} in Rust.2837 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. 2779 2838 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. 2780 2839 D and Go are garbage-collected languages, imposing the associated runtime overhead. 2781 2840 The necessity of accounting for data transfer between managed runtimes and the unmanaged C runtime complicates foreign-function interfaces to C. 2782 2841 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. 2783 D restricts garbage collection to its own heap by default, wh ile Rust is not garbage-collected, and thushas a lighter-weight runtime more interoperable with C.2842 D restricts garbage collection to its own heap by default, whereas Rust is not garbage collected and, thus, has a lighter-weight runtime more interoperable with C. 2784 2843 Rust also possesses much more powerful abstraction capabilities for writing generic code than Go. 2785 On the other hand, Rust's borrow -checker provides strong safety guarantees but is complex and difficult to learn and imposes a distinctly idiomatic programming style.2844 On the other hand, Rust's borrow checker provides strong safety guarantees but is complex and difficult to learn and imposes a distinctly idiomatic programming style. 2786 2845 \CFA, with its more modest safety features, allows direct ports of C code while maintaining the idiomatic style of the original source. 2787 2846 2788 2847 2789 \subsection{Tuples/Variadics} 2790 2848 \vspace*{-18pt} 2849 \subsection{Tuples/variadics} 2850 2851 \vspace*{-5pt} 2791 2852 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. 2792 2853 SETL~\cite{SETL} is a high-level mathematical programming language, with tuples being one of the primary data types. 2793 2854 Tuples in SETL allow subscripting, dynamic expansion, and multiple assignment. 2794 C provides variadic functions through @va_list@ objects, but the programmer is responsible for managing the number of arguments and their types, so the mechanism is type unsafe. 2855 C provides variadic functions through @va_list@ objects, but the programmer is responsible for managing the number of arguments and their types; 2856 thus, the mechanism is type unsafe. 2795 2857 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. 2796 2858 The main contributions of that work were adding MRVF, tuple mass and multiple assignment, and record-member access. 2797 \CCeleven introduced @std::tuple@ as a library variadic 2859 \CCeleven introduced @std::tuple@ as a library variadic-template structure. 2798 2860 Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values. 2799 2861 Operations include @std::get<N>@ to extract values, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons. 2800 \CCseventeen proposes \emph{structured bindings}~\cite{Sutter15} to eliminate pre-declaring variables anduse of @std::tie@ for binding the results.2801 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.2862 \CCseventeen \textcolor{blue}{CHANGE ``\CC{}seventeen TO ``\CCseventeen''} proposes \emph{structured bindings}~\cite{Sutter15} to eliminate predeclaring variables and the use of @std::tie@ for binding the results. 2863 This extension requires the use of @auto@ to infer the types of the new variables; hence, complicated expressions with a nonobvious type must be documented with some other mechanism. 2802 2864 Furthermore, structured bindings are not a full replacement for @std::tie@, as it always declares new variables. 2803 2865 Like \CC, D provides tuples through a library variadic-template structure. 2804 2866 Go does not have tuples but supports MRVF. 2805 Java's variadic functions appear similar to C's but are type -safe using homogeneous arrays, which are less useful than \CFA's heterogeneously-typed variadic functions.2867 Java's variadic functions appear similar to C's but are type safe using homogeneous arrays, which are less useful than \CFA's heterogeneously typed variadic functions. 2806 2868 Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML~\cite{sml}, Haskell, and Scala~\cite{Scala}, which decompose tuples using pattern matching. 2807 2869 2808 2870 2871 \vspace*{-18pt} 2809 2872 \subsection{C Extensions} 2810 2873 2811 \CC is the best known C-based language, and is similar to \CFA in that both are extensions to C with source and runtime backwards compatibility. 2812 Specific difference between \CFA and \CC have been identified in prior sections, with a final observation that \CFA has equal or fewer tokens to express the same notion in many cases. 2874 \vspace*{-5pt} 2875 \CC is the best known C-based language and is similar to \CFA in that both are extensions to C with source and runtime backward compatibility. 2876 Specific differences between \CFA and \CC have been identified in prior sections, with a final observation that \CFA has equal or fewer tokens to express the same notion in many cases. 2813 2877 The key difference in design philosophies is that \CFA is easier for C programmers to understand by maintaining a procedural paradigm and avoiding complex interactions among extensions. 2814 2878 \CC, on the other hand, has multiple overlapping features (such as the three forms of polymorphism), many of which have complex interactions with its object-oriented design. 2815 As a result, \CC has a steep learning curve for even experienced C programmers, especially when attempting to maintain performance equivalent to C legacy -code.2816 2817 There are several other C extension -languages with less usage and even more dramatic changes than \CC.2818 Objective-Cand Cyclone are two other extensions to C with different design goals than \CFA, as discussed above.2879 As a result, \CC has a steep learning curve for even experienced C programmers, especially when attempting to maintain performance equivalent to C legacy code. 2880 2881 There are several other C extension languages with less usage and even more dramatic changes than \CC. 2882 \mbox{Objective-C} and Cyclone are two other extensions to C with different design goals than \CFA, as discussed above. 2819 2883 Other languages extend C with more focused features. 2820 2884 $\mu$\CC~\cite{uC++book}, CUDA~\cite{Nickolls08}, ispc~\cite{Pharr12}, and Sierra~\cite{Leissa14} add concurrent or data-parallel primitives to C or \CC; 2821 data-parallel features have not yet been added to \CFA, but are easily incorporated within its design, wh ileconcurrency primitives similar to those in $\mu$\CC have already been added~\cite{Delisle18}.2822 Finally, CCured~\cite{Necula02} and Ironclad \CC~\cite{DeLozier13} attempt to provide a more memory-safe C by annotating pointer types with garbage collection information; type-checked polymorphism in \CFA covers several of C's memory-safety issues, but more aggressive approaches such as annotating all pointer types with their nullability or requiring runtime garbage collection are contradictory to \CFA's backward scompatibility goals.2885 data-parallel features have not yet been added to \CFA, but are easily incorporated within its design, whereas concurrency primitives similar to those in $\mu$\CC have already been added~\cite{Delisle18}. 2886 Finally, CCured~\cite{Necula02} and Ironclad \CC~\cite{DeLozier13} attempt to provide a more memory-safe C by annotating pointer types with garbage collection information; type-checked polymorphism in \CFA covers several of C's memory-safety issues, but more aggressive approaches such as annotating all pointer types with their nullability or requiring runtime garbage collection are contradictory to \CFA's backward compatibility goals. 2823 2887 2824 2888 2825 2889 \section{Conclusion and Future Work} 2826 2890 2827 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.2828 While other programming languages purport to be a better C, they are in factnew and interesting languages in their own right, but not C extensions.2829 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.2830 The contributions are a powerful type -system using parametric polymorphism and overloading, generic types, tuples, advanced control structures, and extended declarations, which all have complex interactions.2891 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. 2892 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. 2893 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. 2894 The contributions are a powerful type system using parametric polymorphism and overloading, generic types, tuples, advanced control structures, and extended declarations, which all have complex interactions. 2831 2895 The work is a challenging design, engineering, and implementation exercise. 2832 2896 On the surface, the project may appear as a rehash of similar mechanisms in \CC. 2833 2897 However, every \CFA feature is different than its \CC counterpart, often with extended functionality, better integration with C and its programmers, and always supporting separate compilation. 2834 All of these new features are being used by the \CFA development -team to build the \CFA runtime-system.2898 All of these new features are being used by the \CFA development team to build the \CFA runtime system. 2835 2899 Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable. 2836 2900 2837 2901 While all examples in the paper compile and run, there are ongoing efforts to reduce compilation time, provide better debugging, and add more libraries; 2838 2902 when this work is complete in early 2019, a public beta release will be available at \url{https://github.com/cforall/cforall}. 2839 There is also new work on a number of \CFA features, including arrays with size, runtime type -information, virtual functions, user-defined conversions, and modules.2840 While \CFA polymorphic functions use dynamic virtual -dispatch with low runtime overhead (see Section~\ref{sec:eval}), it is not as low as \CC template-inlining.2841 Hence it may be beneficial to provide a mechanism for performance-sensitive code.2842 Two 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 (\CC template specialization).2843 These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code -bloat.2844 In general, we believe separate compilation, producing smaller code, works well with loaded hardware -caches, which may offset the benefit of larger inlined-code.2903 There is also new work on a number of \CFA features, including arrays with size, runtime type information, virtual functions, user-defined conversions, and modules. 2904 While \CFA polymorphic functions use dynamic virtual dispatch with low runtime overhead (see Section~\ref{sec:eval}), it is not as low as \CC template inlining. 2905 Hence, it may be beneficial to provide a mechanism for performance-sensitive code. 2906 Two 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 (\CC template specialization). 2907 These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code bloat. 2908 In general, we believe separate compilation, producing smaller code, works well with loaded hardware caches, which may offset the benefit of larger inlined code. 2845 2909 2846 2910 2847 2911 \section{Acknowledgments} 2848 2912 2849 The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, Thierry Delisle, Andrew Beach and Brice Dobry on the features described in this paper,and thank Magnus Madsen for feedback on the writing.2850 Funding for this project has been provided by Huawei Ltd.\ (\url{http://www.huawei.com}), and Aaron Moss and Peter Buhr are partially funded by the Natural Sciences and Engineering Research Council of Canada.2913 The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, Thierry Delisle, Andrew Beach, and Brice Dobry on the features described in this paper and thank Magnus Madsen for feedback on the writing. 2914 Funding for this project was provided by Huawei Ltd (\url{http://www.huawei.com}), and Aaron Moss and Peter Buhr were partially funded by the Natural Sciences and Engineering Research Council of Canada. 2851 2915 2852 2916 {% … … 2931 2995 2932 2996 2997 \enlargethispage{1000pt} 2933 2998 \subsection{\CFA} 2934 2999 \label{s:CforallStack} … … 2997 3062 2998 3063 3064 \newpage 2999 3065 \subsection{\CC} 3000 3066
Note: See TracChangeset
for help on using the changeset viewer.