Changes in / [520145b:caa649b]


Ignore:
Location:
doc
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • doc/bibliography/pl.bib

    r520145b rcaa649b  
    14391439    contributer = {pabuhr@plg},
    14401440    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},
    14421442    institution = {School of Computer Science, University of Waterloo},
    14431443    address     = {Waterloo, Ontario, Canada, N2L 3G1},
    1444     month       = dec,
    1445     year        = 2017,
    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}},
    14471447}
    14481448
  • doc/papers/general/Paper.tex

    r520145b rcaa649b  
    5858\setlength{\parindentlnth}{\parindent}
    5959
    60 \newcommand{\LstBasicStyle}[1]{{\lst@basicstyle{\lst@basicstyle{#1}}}}
    6160\newcommand{\LstKeywordStyle}[1]{{\lst@basicstyle{\lst@keywordstyle{#1}}}}
    6261\newcommand{\LstCommentStyle}[1]{{\lst@basicstyle{\lst@commentstyle{#1}}}}
     
    232231All of the features discussed in this paper are working, unless a feature states it is a future feature for completion.
    233232
    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 
    238233
    239234\section{Polymorphic Functions}
     
    268263\end{cfa}
    269264\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.
     265In some cases, hundreds of names can be reduced to tens, resulting in a significant cognitive reduction for a programmer.
    271266In the above, the name @max@ has a consistent meaning, and a programmer only needs to remember the single concept: maximum.
    272267To 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).
    273268As 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.
    274269
    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.
     271The 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@.
     272Ergonomic 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.
     273Though name-overloading removes a major use-case for @_Generic@ expressions, \CFA implements @_Generic@ for backwards-compatibility purposes. \TODO{actually implement that}
    281274
    282275% http://fanf.livejournal.com/144696.html
     
    293286int forty_two = identity( 42 );                         $\C{// T is bound to int, forty\_two == 42}$
    294287\end{cfa}
    295 This @identity@ function can be applied to any complete \newterm{object type} (or @otype@).
     288The @identity@ function above can be applied to any complete \newterm{object type} (or @otype@).
    296289The 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.
    297290The \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.
    298291If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@).
    299292
    300 In \CFA, the polymorphic runtime-cost is spread over each polymorphic call, because more arguments are passed to polymorphic functions;
     293In \CFA, the polymorphism runtime-cost is spread over each polymorphic call, due to passing more arguments to polymorphic functions;
    301294the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual-function calls.
    302295A design advantage is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat.
     
    310303which works for any type @T@ with a matching addition operator.
    311304The 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.
     305There 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.
    313306The first approach has a late conversion from @double@ to @int@ on the final assignment, while the second has an eager conversion to @int@.
    314307\CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition.
     
    319312\begin{cfa}
    320313void * 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
     316int comp( const void * t1, const void * t2 ) { return *(double *)t1 < *(double *)t2 ? -1 :
     317                                *(double *)t2 < *(double *)t1 ? 1 : 0; }
     318
    325319double key = 5.0, vals[10] = { /* 10 sorted float values */ };
    326320double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
     
    330324forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) {
    331325        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
    334328forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
    335329        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
    338332double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
    339333int posn = bsearch( 5.0, vals, 10 );
     
    342336Providing a hidden @comp@ function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
    343337As 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@.
    345339
    346340\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}).
     
    388382\begin{cfa}
    389383trait 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}$
    394388\end{cfa}
    395389Given 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.
     
    435429One approach is to write bespoke data-structures for each context in which they are needed.
    436430While 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.
     431A 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.
    438432However, 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.
    439433A 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 is unnatural and inflexible.
     434Furthermore, writing and using preprocessor macros can be unnatural and inflexible.
    441435
    442436\CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data-types.
     
    450444        S second;
    451445};
    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}$
     446forall( otype T ) T value( pair( const char *, T ) p ) { return p.second; }
     447forall( dtype F, otype T ) T value( pair( F *, T * ) p ) { return *p.second; }
     448
     449pair( const char *, int ) p = { "magic", 42 };
    456450int i = value( p );
    457 pair( void *, int * ) q = { 0, &p.second }; $\C{// concrete}$
     451pair( void *, int * ) q = { 0, &p.second };
    458452i = value( q );
    459453double d = 1.0;
    460 pair( double *, double * ) r = { &d, &d }; $\C{// concrete}$
     454pair( double *, double * ) r = { &d, &d };
    461455d = value( r );
    462456\end{cfa}
     
    465459Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
    466460A 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.
     461Polymorphic 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.
    468462
    469463\CFA generic types also allow checked argument-constraints.
     
    481475For example, the concrete instantiation for @pair( const char *, int )@ is:
    482476\begin{cfa}
    483 struct _pair_conc0 {
     477struct _pair_conc1 {
    484478        const char * first;
    485479        int second;
     
    488482
    489483A 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_conc1 {
     484In 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}
     486struct _pair_conc0 {
    493487        void * first;
    494488        void * second;
     
    502496As 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.
    503497Dynamic 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.
     498A dynamic generic-union needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.
    505499Access 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.
    506500
     
    509503if 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.
    510504As 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_conc0, first), offsetof(_pair_conc0, second) }@.
     505The offset array @_offsetof_pair@ is generated at the call site as @size_t _offsetof_pair[] = { offsetof(_pair_conc1, first), offsetof(_pair_conc1, second) }@.
    512506
    513507In some cases the offset arrays cannot be statically generated.
     
    592586\subsection{Tuple Expressions}
    593587
    594 The addition of multiple-return-value functions (MRVF) are \emph{useless} without a syntax for accepting multiple values at the call-site.
     588The addition of multiple-return-value functions (MRVF) are useless without a syntax for accepting multiple values at the call-site.
    595589The simplest mechanism for capturing the return values is variable assignment, allowing the values to be retrieved directly.
    596590As 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}.
     
    828822\end{cfa}
    829823so 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???.
     824These thunks take advantage of gcc C nested-functions to produce closures that have the usual function-pointer signature.
    831825
    832826
     
    884878        print(arg);  print(rest);
    885879}
    886 void print( const char * x ) { printf( "%s", x ); }
     880void print( char * x ) { printf( "%s", x ); }
    887881void print( int x ) { printf( "%d", x ); }
    888882void print( S s ) { print( "{ ", s.x, ",", s.y, " }" ); }
     
    893887The polymorphic @print@ allows printing any list of types, where as each individual type has a @print@ function.
    894888The 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}).
    896889
    897890Finally, it is possible to use @ttype@ polymorphism to provide arbitrary argument forwarding functions.
     
    10851078While 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.
    10861079For 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 
    10881080Collectively, these enhancements reduce programmer burden and increase readability and safety.
    10891081
     
    12451237\end{figure}
    12461238
    1247 With respect to safety, both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:
     1239Both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:
    12481240\begin{itemize}
    12491241\item
     
    12581250With @goto@, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
    12591251Finally, 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.
     1252The implicit targets of the current @continue@ and @break@, \ie the closest enclosing loop or @switch@, change as certain constructs are added or removed.
    12611253
    12621254
    12631255\subsection{Exception Handling}
    12641256
    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}.
     1257The 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}).
    12671259Both 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.
    12681260\CFA restricts exception types to those defined by aggregate type @exception@.
     
    13411333resume( $\emph{alternate-stack}$ )
    13421334\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.}
     1335These overloads of @resume@ raise the specified exception or the currently propagating exception (reresume) at another coroutine or task~\cite{Delisle18}.
    13441336Nonlocal 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.
    13451337
     
    13661358Specifying no exception type is shorthand for specifying all exception types.
    13671359Both @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 body
    1374                 }
    1375         // appropriate catchResume/catch
    1376         }
    1377 }
    1378 \end{cfa}
    13791360
    13801361Finally, \CFA provides a Java like  @finally@ clause after the catch clauses:
     
    14801461Qualification or a cast is used to disambiguate.
    14811462
    1482 There is an interesting problem between parameters and the function-body @with@, \eg:
     1463There is an interesting problem between parameters and the function @with@, \eg:
    14831464\begin{cfa}
    14841465void ?{}( S & s, int i ) with ( s ) {           $\C{// constructor}$
     
    14861467}
    14871468\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@.
     1469Here, 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@.
    14891470To solve this problem, parameters are treated like an initialized aggregate:
    14901471\begin{cfa}
     
    14941475} params;
    14951476\end{cfa}
    1496 and implicitly opened \emph{after} a function-body open, 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;
     1477and implicitly opened \emph{after} a function open, to give them higher priority:
     1478\begin{cfa}
     1479void ?{}( S & s, int i ) with ( s ) `with( $\emph{\color{red}params}$ )` {
     1480        s.i = i; j = 3; m = 5.5;
    15001481}
    15011482\end{cfa}
     
    15581539While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
    15591540
    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.
    15611542The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right.
    15621543The qualifiers have the same meaning but are ordered left to right to specify a variable's type.
     
    19701951}
    19711952\end{cfa}
    1972 (Note, the example is purposely simplified using shallow-copy semantics.)
     1953(Note, the example is purposely kept simple by using shallow-copy semantics.)
    19731954An 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).
    19741955\begin{cfa}
     
    20232004C 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.
    20242005In 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.
     2006A 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@.
    20282007
    20292008
     
    20352014\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
    20362015\begin{cfa}
    2037 20_`hh`     // signed char
    2038 21_`hhu`   // unsigned char
    2039 22_`h`       // signed short int
    2040 23_`uh`     // unsigned short int
    2041 24_`z`       // size_t
    2042 \end{cfa}
    2043 &
    2044 \begin{cfa}
    2045 20_`L8`      // int8_t
    2046 21_`ul8`     // uint8_t
    2047 22_`l16`     // int16_t
    2048 23_`ul16`   // uint16_t
    2049 24_`l32`     // int32_t
    2050 \end{cfa}
    2051 &
    2052 \begin{cfa}
    2053 25_`ul32`      // uint32_t
    2054 26_`l64`        // int64_t
    2055 27_`l64u`      // uint64_t
    2056 26_`L128`     // int128
    2057 27_`L128u`   // unsigned int128
     201620`_hh`     // signed char
     201721`_hhu`   // unsigned char
     201822`_h`       // signed short int
     201923`_uh`     // unsigned short int
     202024`z`         // size_t
     2021\end{cfa}
     2022&
     2023\begin{cfa}
     202420`_L8`      // int8_t
     202521`_ul8`     // uint8_t
     202622`_l16`     // int16_t
     202723`_ul16`   // uint16_t
     202824`_l32`     // int32_t
     2029\end{cfa}
     2030&
     2031\begin{cfa}
     203225`_ul32`      // uint32_t
     203326`_l64`        // int64_t
     203427`_l64u`      // uint64_t
     203526`_L128`     // int128
     203627`_L128u`   // unsigned int128
    20582037\end{cfa}
    20592038\end{tabular}
     
    20942073After which, user literals must match (no conversions);
    20952074hence, it is necessary to overload the unit with all appropriate types.
     2075Finally, 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.
    20962076
    20972077\begin{figure}
     
    21452125        w = 155|_lb|;
    21462126        w = 0b1111|_lb|;       // error, binary unsupported
    2147         w = 0${\color{red}\LstBasicStyle{'}}$233|_lb|;          // quote separator
     2127        w = 0${\color{red}'}$233|_lb|;          // quote separator
    21482128        w = 0x9b|_kg|;
    21492129        w = 5.5d|_st| + 8|_kg| + 25.01|_lb| + heavy;
     
    23072287\begin{description}[topsep=3pt,itemsep=2pt,parsep=0pt]
    23082288\item[fill]
    2309 an allocation with a specified character.
     2289after allocation the storage is filled with a specified character.
    23102290\item[resize]
    2311 an existing allocation to decreased or increased its size.
     2291an existing allocation is decreased or increased in size.
    23122292In 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.
    23132293For an increase in storage size, new storage after the copied data may be filled.
    23142294\item[alignment]
    2315 an allocation on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes.
     2295an allocation starts on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes.
    23162296\item[array]
    2317 allocation of the specified number of elements.
     2297the allocation size is scaled to the specified number of array elements.
    23182298An array may be filled, resized, or aligned.
    23192299\end{description}
    23202300Table~\ref{t:StorageManagementOperations} shows the capabilities provided by C/\Celeven allocation-functions and how all the capabilities can be combined into two \CFA functions.
    23212301\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.
     2302Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage-allocation operation performing the same operations with the same type safety.
    23232303
    23242304\begin{table}
     
    24632443\end{cfa}
    24642444\\
     2445\textbf{output:}
    24652446&
    24662447\begin{cfa}[showspaces=true,aboveskip=0pt]
     
    26962677\subsection{Control Structures / Declarations / Literals}
    26972678
    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/destructors
    2710 
    2711 0/1 Literals \\
    2712 user defined: D, Objective-C
    27132679
    27142680\section{Conclusion and Future Work}
     
    27172683While 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.
    27182684The 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.
     2685The contributions are a powerful type-system using parametric polymorphism and overloading, generic types, and tuples, which all have complex interactions.
    27202686The work is a challenging design, engineering, and implementation exercise.
    27212687On the surface, the project may appear as a rehash of similar mechanisms in \CC.
     
    27242690Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable.
    27252691
    2726 There is ongoing work on a wide range of \CFA feature extensions, including arrays with size, user-defined conversions, concurrent primitives, and modules.
     2692There is ongoing work on a wide range of \CFA feature extensions, including arrays with size, exceptions, concurrent primitives, modules, and user-defined conversions.
    27272693(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.)
    27282694In addition, there are interesting future directions for the polymorphism design.
     
    27372703\section{Acknowledgments}
    27382704
    2739 The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, Thierry Delisle, and Andrew Beach on 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 partially funded by the Natural Sciences and Engineering Research Council of Canada.
     2705The 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.
     2706This 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.
    27412707
    27422708% 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.