Changes in / [520145b:caa649b]
- Location:
- doc
- Files:
-
- 2 edited
-
bibliography/pl.bib (modified) (1 diff)
-
papers/general/Paper.tex (modified) (40 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/bibliography/pl.bib
r520145b rcaa649b 1439 1439 contributer = {pabuhr@plg}, 1440 1440 author = {Peter A. Buhr}, 1441 title = {$\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Annotated Reference Manual, Version 7.0.0},1441 title = {$\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Annotated Reference Manual, Version 6.1.0}, 1442 1442 institution = {School of Computer Science, University of Waterloo}, 1443 1443 address = {Waterloo, Ontario, Canada, N2L 3G1}, 1444 month = dec,1445 year = 201 7,1446 note = {\href{http://plg.uwaterloo.ca/~usystem/pub/uSystem/u++- 7.0.0.sh}{http://\-plg.\-uwaterloo.\-ca/\-$\sim$usystem/\-pub/\-uSystem/\-u++-7.0.0.sh}},1444 month = jul, 1445 year = 2015, 1446 note = {\href{http://plg.uwaterloo.ca/~usystem/pub/uSystem/u++-6.1.0.sh}{http://\-plg.\-uwaterloo.\-ca/\-$\sim$usystem/\-pub/\-uSystem/\-u++-6.1.0.sh}}, 1447 1447 } 1448 1448 -
doc/papers/general/Paper.tex
r520145b rcaa649b 58 58 \setlength{\parindentlnth}{\parindent} 59 59 60 \newcommand{\LstBasicStyle}[1]{{\lst@basicstyle{\lst@basicstyle{#1}}}}61 60 \newcommand{\LstKeywordStyle}[1]{{\lst@basicstyle{\lst@keywordstyle{#1}}}} 62 61 \newcommand{\LstCommentStyle}[1]{{\lst@basicstyle{\lst@commentstyle{#1}}}} … … 232 231 All of the features discussed in this paper are working, unless a feature states it is a future feature for completion. 233 232 234 Finally, it is impossible to describe a programming language without usages before definitions.235 Therefore, syntax and semantics appear before explanations;236 hence, patience is necessary until details are presented.237 238 233 239 234 \section{Polymorphic Functions} … … 268 263 \end{cfa} 269 264 \CFA maximizes the ability to reuse names to aggressively address the naming problem. 270 In some cases, hundreds of names can be reduced to tens, resulting in a significant cognitive reduction .265 In some cases, hundreds of names can be reduced to tens, resulting in a significant cognitive reduction for a programmer. 271 266 In the above, the name @max@ has a consistent meaning, and a programmer only needs to remember the single concept: maximum. 272 267 To prevent significant ambiguities, \CFA uses the return type in selecting overloads, \eg in the assignment to @m@, the compiler use @m@'s type to unambiguously select the most appropriate call to function @max@ (as does Ada). 273 268 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. 274 269 275 \Celeven added @_Generic@ expressions, which is used in preprocessor macros to provide a form of ad-hoc polymorphism; 276 however, this polymorphism is both functionally and ergonomically inferior to \CFA name overloading. 277 The macro wrapping the generic expression imposes some limitations; 278 \eg, it cannot implement the example above, because the variables @max@ are ambiguous with the functions @max@. 279 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. 280 For backwards compatibility, \CFA supports @_Generic@ expressions, but it is an unnecessary mechanism. \TODO{actually implement that} 270 \Celeven added @_Generic@ expressions, which can be used in preprocessor macros to provide a form of ad-hoc polymorphism; however, this polymorphism is both functionally and ergonomically inferior to \CFA name overloading. 271 The macro wrapping the generic expression imposes some limitations; as an example, it could not implement the example above, because the variables @max@ would collide with the functions @max@. 272 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 functions dispatched to, which must all have distinct names. 273 Though name-overloading removes a major use-case for @_Generic@ expressions, \CFA implements @_Generic@ for backwards-compatibility purposes. \TODO{actually implement that} 281 274 282 275 % http://fanf.livejournal.com/144696.html … … 293 286 int forty_two = identity( 42 ); $\C{// T is bound to int, forty\_two == 42}$ 294 287 \end{cfa} 295 Th is @identity@ functioncan be applied to any complete \newterm{object type} (or @otype@).288 The @identity@ function above can be applied to any complete \newterm{object type} (or @otype@). 296 289 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. 297 290 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. 298 291 If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@). 299 292 300 In \CFA, the polymorphi c runtime-cost is spread over each polymorphic call, because more arguments are passedto polymorphic functions;293 In \CFA, the polymorphism runtime-cost is spread over each polymorphic call, due to passing more arguments to polymorphic functions; 301 294 the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual-function calls. 302 295 A design advantage is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat. … … 310 303 which works for any type @T@ with a matching addition operator. 311 304 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@. 312 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.305 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. 313 306 The first approach has a late conversion from @double@ to @int@ on the final assignment, while the second has an eager conversion to @int@. 314 307 \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition. … … 319 312 \begin{cfa} 320 313 void * bsearch( const void * key, const void * base, size_t nmemb, size_t size, 321 int (* compar)( const void *, const void * )); 322 int comp( const void * t1, const void * t2 ) { 323 return *(double *)t1 < *(double *)t2 ? -1 : *(double *)t2 < *(double *)t1 ? 1 : 0; 324 } 314 int (* compar)( const void *, const void * )); 315 316 int comp( const void * t1, const void * t2 ) { return *(double *)t1 < *(double *)t2 ? -1 : 317 *(double *)t2 < *(double *)t1 ? 1 : 0; } 318 325 319 double key = 5.0, vals[10] = { /* 10 sorted float values */ }; 326 320 double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp ); $\C{// search sorted array}$ … … 330 324 forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) { 331 325 int comp( const void * t1, const void * t2 ) { /* as above with double changed to T */ } 332 return (T *)bsearch( &key, arr, size, sizeof(T), comp ); 333 } 326 return (T *)bsearch( &key, arr, size, sizeof(T), comp ); } 327 334 328 forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) { 335 329 T * result = bsearch( key, arr, size ); $\C{// call first version}$ 336 return result ? result - arr : size; $\C{// pointer subtraction includes sizeof(T)}$337 } 330 return result ? result - arr : size; } $\C{// pointer subtraction includes sizeof(T)}$ 331 338 332 double * val = bsearch( 5.0, vals, 10 ); $\C{// selection based on return type}$ 339 333 int posn = bsearch( 5.0, vals, 10 ); … … 342 336 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. 343 337 As well, an alternate kind of return is made available: position versus pointer to found element. 344 \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@.338 \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 templated @bsearch@. 345 339 346 340 \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}). … … 388 382 \begin{cfa} 389 383 trait otype( dtype T | sized(T) ) { // sized is a pseudo-trait for types with known size and alignment 390 void ?{}( T &); $\C{// default constructor}$391 void ?{}( T &, T ); $\C{// copy constructor}$392 void ?=?( T &, T ); $\C{// assignment operator}$393 void ^?{}( T &); }; $\C{// destructor}$384 void ?{}( T * ); $\C{// default constructor}$ 385 void ?{}( T *, T ); $\C{// copy constructor}$ 386 void ?=?( T *, T ); $\C{// assignment operator}$ 387 void ^?{}( T * ); }; $\C{// destructor}$ 394 388 \end{cfa} 395 389 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. … … 435 429 One approach is to write bespoke data-structures for each context in which they are needed. 436 430 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. 437 A second approach is to use @void *@--based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@, which allow reuse of code with common functionality.431 A second approach is to use @void *@--based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@, which allows reuse of code with common functionality. 438 432 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 otherwise needed. 439 433 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. 440 Furthermore, writing and using preprocessor macros isunnatural and inflexible.434 Furthermore, writing and using preprocessor macros can be unnatural and inflexible. 441 435 442 436 \CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data-types. … … 450 444 S second; 451 445 }; 452 forall( otype T ) T value( pair( const char *, T ) p ) { return p.second; } $\C{// dynamic}$453 forall( dtype F, otype T ) T value( pair( F *, T * ) p ) { return *p.second; } $\C{// concrete}$454 455 pair( const char *, int ) p = { "magic", 42 }; $\C{// dynamic}$446 forall( otype T ) T value( pair( const char *, T ) p ) { return p.second; } 447 forall( dtype F, otype T ) T value( pair( F *, T * ) p ) { return *p.second; } 448 449 pair( const char *, int ) p = { "magic", 42 }; 456 450 int i = value( p ); 457 pair( void *, int * ) q = { 0, &p.second }; $\C{// concrete}$451 pair( void *, int * ) q = { 0, &p.second }; 458 452 i = value( q ); 459 453 double d = 1.0; 460 pair( double *, double * ) r = { &d, &d }; $\C{// concrete}$454 pair( double *, double * ) r = { &d, &d }; 461 455 d = value( r ); 462 456 \end{cfa} … … 465 459 Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters. 466 460 A type may have polymorphic parameters but still be concrete, called \newterm{dtype-static}. 467 Polymorphic pointers are an example of dtype-static , \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@ is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation.461 Polymorphic pointers are an example of dtype-static types, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@ is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation. 468 462 469 463 \CFA generic types also allow checked argument-constraints. … … 481 475 For example, the concrete instantiation for @pair( const char *, int )@ is: 482 476 \begin{cfa} 483 struct _pair_conc 0{477 struct _pair_conc1 { 484 478 const char * first; 485 479 int second; … … 488 482 489 483 A concrete generic-type with dtype-static parameters is also expanded to a structure type, but this type is used for all matching instantiations. 490 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:491 \begin{cfa} 492 struct _pair_conc 1{484 In the above example, the @pair( F *, T * )@ parameter to @value_p@ 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: 485 \begin{cfa} 486 struct _pair_conc0 { 493 487 void * first; 494 488 void * second; … … 502 496 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. 503 497 Dynamic generic-types also have an \newterm{offset array} containing structure-member offsets. 504 A dynamic generic- @union@needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.498 A dynamic generic-union needs no such offset array, as all members are at offset 0, but size and alignment are still necessary. 505 499 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. 506 500 … … 509 503 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. 510 504 As an example, @p.second@ in the @value@ function above is implemented as @*(p + _offsetof_pair[1])@, where @p@ is a @void *@, and @_offsetof_pair@ is the offset array passed into @value@ for @pair( const char *, T )@. 511 The offset array @_offsetof_pair@ is generated at the call site as @size_t _offsetof_pair[] = { offsetof(_pair_conc 0, first), offsetof(_pair_conc0, second) }@.505 The offset array @_offsetof_pair@ is generated at the call site as @size_t _offsetof_pair[] = { offsetof(_pair_conc1, first), offsetof(_pair_conc1, second) }@. 512 506 513 507 In some cases the offset arrays cannot be statically generated. … … 592 586 \subsection{Tuple Expressions} 593 587 594 The addition of multiple-return-value functions (MRVF) are \emph{useless}without a syntax for accepting multiple values at the call-site.588 The addition of multiple-return-value functions (MRVF) are useless without a syntax for accepting multiple values at the call-site. 595 589 The simplest mechanism for capturing the return values is variable assignment, allowing the values to be retrieved directly. 596 590 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}. … … 828 822 \end{cfa} 829 823 so the thunk provides flattening and structuring conversions to inferred functions, improving the compatibility of tuples and polymorphism. 830 These thunks take advantage of gcc C nested-functions to produce closures that have the usual function-pointer signature WHAT DOES THIS MEAN???.824 These thunks take advantage of gcc C nested-functions to produce closures that have the usual function-pointer signature. 831 825 832 826 … … 884 878 print(arg); print(rest); 885 879 } 886 void print( c onst char * x ) { printf( "%s", x ); }880 void print( char * x ) { printf( "%s", x ); } 887 881 void print( int x ) { printf( "%d", x ); } 888 882 void print( S s ) { print( "{ ", s.x, ",", s.y, " }" ); } … … 893 887 The polymorphic @print@ allows printing any list of types, where as each individual type has a @print@ function. 894 888 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. 895 This mechanism is used to seamlessly print tuples in the \CFA I/O library (see Section~\ref{s:IOLibrary}).896 889 897 890 Finally, it is possible to use @ttype@ polymorphism to provide arbitrary argument forwarding functions. … … 1085 1078 While the ability to fall through \emph{is} a useful form of control flow, it does not match well with programmer intuition, resulting in many errors from missing @break@ statements. 1086 1079 For backwards compatibility, \CFA provides a \emph{new} control structure, @choose@, which mimics @switch@, but reverses the meaning of fall through (see Figure~\ref{f:ChooseSwitchStatements}). 1087 1088 1080 Collectively, these enhancements reduce programmer burden and increase readability and safety. 1089 1081 … … 1245 1237 \end{figure} 1246 1238 1247 With respect to safety, both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:1239 Both labelled @continue@ and @break@ are a @goto@ restricted in the following ways: 1248 1240 \begin{itemize} 1249 1241 \item … … 1258 1250 With @goto@, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader. 1259 1251 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. 1260 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.1252 The implicit targets of the current @continue@ and @break@, \ie the closest enclosing loop or @switch@, change as certain constructs are added or removed. 1261 1253 1262 1254 1263 1255 \subsection{Exception Handling} 1264 1256 1265 The following framework for \CFA exception handling is in place, excluding some run-time type-information and dynamic casts.1266 \CFA provides two forms of exception handling: \newterm{fix-up} and \newterm{recovery} (see Figure~\ref{f:CFAExceptionHandling}) ~\cite{Buhr92b,Buhr00a}.1257 The following framework for \CFA exception handling is in place, excluding a run-time type information and dynamic casts. 1258 \CFA provides two forms of exception handling: \newterm{fix-up} and \newterm{recovery} (see Figure~\ref{f:CFAExceptionHandling}). 1267 1259 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. 1268 1260 \CFA restricts exception types to those defined by aggregate type @exception@. … … 1341 1333 resume( $\emph{alternate-stack}$ ) 1342 1334 \end{cfa} 1343 These overloads of @resume@ raise the specified exception or the currently propagating exception (reresume) at another \CFA coroutine or task~\cite{Delisle18}.\footnote{\CFA coroutine and concurrency features are discussed in a separately submitted paper.}1335 These overloads of @resume@ raise the specified exception or the currently propagating exception (reresume) at another coroutine or task~\cite{Delisle18}. 1344 1336 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 handle returns. 1345 1337 … … 1366 1358 Specifying no exception type is shorthand for specifying all exception types. 1367 1359 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. 1368 Coroutines and tasks start with non-local exceptions disabled, allowing handlers to be put in place, before non-local exceptions are explicitly enabled.1369 \begin{cfa}1370 void main( mytask & c ) {1371 try {1372 enable { $\C{// now allow non-local exception delivery}$1373 // task body1374 }1375 // appropriate catchResume/catch1376 }1377 }1378 \end{cfa}1379 1360 1380 1361 Finally, \CFA provides a Java like @finally@ clause after the catch clauses: … … 1480 1461 Qualification or a cast is used to disambiguate. 1481 1462 1482 There is an interesting problem between parameters and the function -body@with@, \eg:1463 There is an interesting problem between parameters and the function @with@, \eg: 1483 1464 \begin{cfa} 1484 1465 void ?{}( S & s, int i ) with ( s ) { $\C{// constructor}$ … … 1486 1467 } 1487 1468 \end{cfa} 1488 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@.1469 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 @with@. 1489 1470 To solve this problem, parameters are treated like an initialized aggregate: 1490 1471 \begin{cfa} … … 1494 1475 } params; 1495 1476 \end{cfa} 1496 and implicitly opened \emph{after} a function -bodyopen, to give them higher priority:1497 \begin{cfa} 1498 void ?{}( S & s, int `i`) with ( s ) `with( $\emph{\color{red}params}$ )` {1499 s.i = `i`; j = 3; m = 5.5;1477 and implicitly opened \emph{after} a function open, to give them higher priority: 1478 \begin{cfa} 1479 void ?{}( S & s, int i ) with ( s ) `with( $\emph{\color{red}params}$ )` { 1480 s.i = i; j = 3; m = 5.5; 1500 1481 } 1501 1482 \end{cfa} … … 1558 1539 While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice. 1559 1540 1560 \CFA provides its own type, variable and function declarations, using a different syntax ~\cite[pp.~856--859]{Buhr94a}.1541 \CFA provides its own type, variable and function declarations, using a different syntax. 1561 1542 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right. 1562 1543 The qualifiers have the same meaning but are ordered left to right to specify a variable's type. … … 1970 1951 } 1971 1952 \end{cfa} 1972 (Note, the example is purposely simplifiedusing shallow-copy semantics.)1953 (Note, the example is purposely kept simple by using shallow-copy semantics.) 1973 1954 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). 1974 1955 \begin{cfa} … … 2023 2004 C already includes limited polymorphism for literals -- @0@ can be either an integer or a pointer literal, depending on context, while the syntactic forms of literals of the various integer and float types are very similar, differing from each other only in suffix. 2024 2005 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. 2025 2026 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. 2027 \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. 2006 A trivial 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@. 2028 2007 2029 2008 … … 2035 2014 \begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}} 2036 2015 \begin{cfa} 2037 20 _`hh` // signed char2038 21 _`hhu` // unsigned char2039 22 _`h` // signed short int2040 23 _`uh` // unsigned short int2041 24 _`z`// size_t2042 \end{cfa} 2043 & 2044 \begin{cfa} 2045 20 _`L8` // int8_t2046 21 _`ul8` // uint8_t2047 22 _`l16` // int16_t2048 23 _`ul16` // uint16_t2049 24 _`l32` // int32_t2050 \end{cfa} 2051 & 2052 \begin{cfa} 2053 25 _`ul32` // uint32_t2054 26 _`l64` // int64_t2055 27 _`l64u` // uint64_t2056 26 _`L128` // int1282057 27 _`L128u` // unsigned int1282016 20`_hh` // signed char 2017 21`_hhu` // unsigned char 2018 22`_h` // signed short int 2019 23`_uh` // unsigned short int 2020 24`z` // size_t 2021 \end{cfa} 2022 & 2023 \begin{cfa} 2024 20`_L8` // int8_t 2025 21`_ul8` // uint8_t 2026 22`_l16` // int16_t 2027 23`_ul16` // uint16_t 2028 24`_l32` // int32_t 2029 \end{cfa} 2030 & 2031 \begin{cfa} 2032 25`_ul32` // uint32_t 2033 26`_l64` // int64_t 2034 27`_l64u` // uint64_t 2035 26`_L128` // int128 2036 27`_L128u` // unsigned int128 2058 2037 \end{cfa} 2059 2038 \end{tabular} … … 2094 2073 After which, user literals must match (no conversions); 2095 2074 hence, it is necessary to overload the unit with all appropriate types. 2075 Finally, the use of the single quote as a separator is restricted to digits, precluding its use in the literal prefix or suffix, and causes problems with most IDEs, which must be extended to deal with this alternate use of the single quote. 2096 2076 2097 2077 \begin{figure} … … 2145 2125 w = 155|_lb|; 2146 2126 w = 0b1111|_lb|; // error, binary unsupported 2147 w = 0${\color{red} \LstBasicStyle{'}}$233|_lb|; // quote separator2127 w = 0${\color{red}'}$233|_lb|; // quote separator 2148 2128 w = 0x9b|_kg|; 2149 2129 w = 5.5d|_st| + 8|_kg| + 25.01|_lb| + heavy; … … 2307 2287 \begin{description}[topsep=3pt,itemsep=2pt,parsep=0pt] 2308 2288 \item[fill] 2309 a n allocationwith a specified character.2289 after allocation the storage is filled with a specified character. 2310 2290 \item[resize] 2311 an existing allocation to decreased or increased itssize.2291 an existing allocation is decreased or increased in size. 2312 2292 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 is copied. 2313 2293 For an increase in storage size, new storage after the copied data may be filled. 2314 2294 \item[alignment] 2315 an allocation on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes.2295 an allocation starts on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes. 2316 2296 \item[array] 2317 allocation of the specified number ofelements.2297 the allocation size is scaled to the specified number of array elements. 2318 2298 An array may be filled, resized, or aligned. 2319 2299 \end{description} 2320 2300 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. 2321 2301 \CFA storage-management functions extend the C equivalents by overloading, providing shallow type-safety, and removing the need to specify the base allocation-size. 2322 Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage-allocation performing the same operations with the same type safety.2302 Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage-allocation operation performing the same operations with the same type safety. 2323 2303 2324 2304 \begin{table} … … 2463 2443 \end{cfa} 2464 2444 \\ 2445 \textbf{output:} 2465 2446 & 2466 2447 \begin{cfa}[showspaces=true,aboveskip=0pt] … … 2696 2677 \subsection{Control Structures / Declarations / Literals} 2697 2678 2698 Java has default fall through like C/\CC.2699 Pascal/Ada/Go/Rust do not have default fall through.2700 \Csharp does not have fall through but still requires a break.2701 Python uses dictionary mapping. \\2702 \CFA choose is like Rust match.2703 2704 Java has labelled break/continue. \\2705 Languages with and without exception handling.2706 2707 Alternative C declarations. \\2708 Different references \\2709 Constructors/destructors2710 2711 0/1 Literals \\2712 user defined: D, Objective-C2713 2679 2714 2680 \section{Conclusion and Future Work} … … 2717 2683 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. 2718 2684 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. 2719 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.2685 The contributions are a powerful type-system using parametric polymorphism and overloading, generic types, and tuples, which all have complex interactions. 2720 2686 The work is a challenging design, engineering, and implementation exercise. 2721 2687 On the surface, the project may appear as a rehash of similar mechanisms in \CC. … … 2724 2690 Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable. 2725 2691 2726 There is ongoing work on a wide range of \CFA feature extensions, including arrays with size, user-defined conversions, concurrent primitives, and modules.2692 There is ongoing work on a wide range of \CFA feature extensions, including arrays with size, exceptions, concurrent primitives, modules, and user-defined conversions. 2727 2693 (While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these additional extensions.) 2728 2694 In addition, there are interesting future directions for the polymorphism design. … … 2737 2703 \section{Acknowledgments} 2738 2704 2739 The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, Thierry Delisle, and Andrew Beachon the features described in this paper, and thank Magnus Madsen for feedback in the writing.2740 This work is supported through a corporate partnership with Huawei Ltd.\ (\url{http://www.huawei.com}), and Aaron Moss and Peter Buhr are partiallyfunded by the Natural Sciences and Engineering Research Council of Canada.2705 The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, and Thierry Delisle on the features described in this paper, and thank Magnus Madsen for feedback in the writing. 2706 This work is supported through a corporate partnership with Huawei Ltd.\ (\url{http://www.huawei.com}), and Aaron Moss and Peter Buhr are funded by the Natural Sciences and Engineering Research Council of Canada. 2741 2707 2742 2708 % the first author's \grantsponsor{NSERC-PGS}{NSERC PGS D}{http://www.nserc-crsng.gc.ca/Students-Etudiants/PG-CS/BellandPostgrad-BelletSuperieures_eng.asp} scholarship.
Note:
See TracChangeset
for help on using the changeset viewer.