Changeset d893266a


Ignore:
Timestamp:
Mar 6, 2018, 3:43:42 PM (7 years ago)
Author:
Peter A. Buhr <pabuhr@…>
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, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
520145b
Parents:
ea46db7
Message:

more updates, and final open issues

Location:
doc
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • TabularUnified doc/bibliography/pl.bib

    rea46db7 rd893266a  
    14391439    contributer = {pabuhr@plg},
    14401440    author      = {Peter A. Buhr},
    1441     title       = {$\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Annotated Reference Manual, Version 6.1.0},
     1441    title       = {$\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Annotated Reference Manual, Version 7.0.0},
    14421442    institution = {School of Computer Science, University of Waterloo},
    14431443    address     = {Waterloo, Ontario, Canada, N2L 3G1},
    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}},
     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}},
    14471447}
    14481448

  • TabularUnified doc/papers/general/Paper.tex

    rea46db7 rd893266a  
    5858\setlength{\parindentlnth}{\parindent}
    5959
     60\newcommand{\LstBasicStyle}[1]{{\lst@basicstyle{\lst@basicstyle{#1}}}}
    6061\newcommand{\LstKeywordStyle}[1]{{\lst@basicstyle{\lst@keywordstyle{#1}}}}
    6162\newcommand{\LstCommentStyle}[1]{{\lst@basicstyle{\lst@commentstyle{#1}}}}
    … …  
    231232All of the features discussed in this paper are working, unless a feature states it is a future feature for completion.
    232233
     234Finally, it is impossible to describe a programming language without usages before definitions.
     235Therefore, syntax and semantics appear before explanations;
     236hence, patience is necessary until details are presented.
     237
    233238
    234239\section{Polymorphic Functions}
    … …  
    263268\end{cfa}
    264269\CFA maximizes the ability to reuse names to aggressively address the naming problem.
    265 In some cases, hundreds of names can be reduced to tens, resulting in a significant cognitive reduction for a programmer.
     270In some cases, hundreds of names can be reduced to tens, resulting in a significant cognitive reduction.
    266271In the above, the name @max@ has a consistent meaning, and a programmer only needs to remember the single concept: maximum.
    267272To 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).
    268273As 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.
    269274
    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}
     275\Celeven added @_Generic@ expressions, which is used in preprocessor macros to provide a form of ad-hoc polymorphism;
     276however, this polymorphism is both functionally and ergonomically inferior to \CFA name overloading.
     277The 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@.
     279Ergonomic 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.
     280For backwards compatibility, \CFA supports @_Generic@ expressions, but it is an unnecessary mechanism. \TODO{actually implement that}
    274281
    275282% http://fanf.livejournal.com/144696.html
    … …  
    286293int forty_two = identity( 42 );                         $\C{// T is bound to int, forty\_two == 42}$
    287294\end{cfa}
    288 The @identity@ function above can be applied to any complete \newterm{object type} (or @otype@).
     295This @identity@ function can be applied to any complete \newterm{object type} (or @otype@).
    289296The 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.
    290297The \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.
    291298If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@).
    292299
    293 In \CFA, the polymorphism runtime-cost is spread over each polymorphic call, due to passing more arguments to polymorphic functions;
     300In \CFA, the polymorphic runtime-cost is spread over each polymorphic call, because more arguments are passed to polymorphic functions;
    294301the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual-function calls.
    295302A design advantage is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat.
    … …  
    303310which works for any type @T@ with a matching addition operator.
    304311The 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@.
    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.
     312There 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.
    306313The first approach has a late conversion from @double@ to @int@ on the final assignment, while the second has an eager conversion to @int@.
    307314\CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition.
    … …  
    312319\begin{cfa}
    313320void * bsearch( const void * key, const void * base, size_t nmemb, size_t size,
    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 
     321                                         int (* compar)( const void *, const void * ));
     322int comp( const void * t1, const void * t2 ) {
     323         return *(double *)t1 < *(double *)t2 ? -1 : *(double *)t2 < *(double *)t1 ? 1 : 0;
     324}
    319325double key = 5.0, vals[10] = { /* 10 sorted float values */ };
    320326double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
    … …  
    324330forall( otype T | { int ?<?( T, T ); } ) T * bsearch( T key, const T * arr, size_t size ) {
    325331        int comp( const void * t1, const void * t2 ) { /* as above with double changed to T */ }
    326         return (T *)bsearch( &key, arr, size, sizeof(T), comp ); }
    327 
     332        return (T *)bsearch( &key, arr, size, sizeof(T), comp );
     333}
    328334forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
    329335        T * result = bsearch( key, arr, size ); $\C{// call first version}$
    330         return result ? result - arr : size; }  $\C{// pointer subtraction includes sizeof(T)}$
    331 
     336        return result ? result - arr : size;    $\C{// pointer subtraction includes sizeof(T)}$
     337}
    332338double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
    333339int posn = bsearch( 5.0, vals, 10 );
    … …  
    336342Providing a hidden @comp@ function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
    337343As well, an alternate kind of return is made available: position versus pointer to found element.
    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@.
     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@.
    339345
    340346\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}).
    … …  
    382388\begin{cfa}
    383389trait otype( dtype T | sized(T) ) {  // sized is a pseudo-trait for types with known size and alignment
    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}$
     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}$
    388394\end{cfa}
    389395Given 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.
    … …  
    429435One approach is to write bespoke data-structures for each context in which they are needed.
    430436While 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.
    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.
     437A 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.
    432438However, 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.
    433439A 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.
    434 Furthermore, writing and using preprocessor macros can be unnatural and inflexible.
     440Furthermore, writing and using preprocessor macros is unnatural and inflexible.
    435441
    436442\CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data-types.
    … …  
    444450        S second;
    445451};
    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 };
     452forall( otype T ) T value( pair( const char *, T ) p ) { return p.second; } $\C{// dynamic}$
     453forall( dtype F, otype T ) T value( pair( F *, T * ) p ) { return *p.second; } $\C{// concrete}$
     454
     455pair( const char *, int ) p = { "magic", 42 }; $\C{// dynamic}$
    450456int i = value( p );
    451 pair( void *, int * ) q = { 0, &p.second };
     457pair( void *, int * ) q = { 0, &p.second }; $\C{// concrete}$
    452458i = value( q );
    453459double d = 1.0;
    454 pair( double *, double * ) r = { &d, &d };
     460pair( double *, double * ) r = { &d, &d }; $\C{// concrete}$
    455461d = value( r );
    456462\end{cfa}
    … …  
    459465Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
    460466A type may have polymorphic parameters but still be concrete, called \newterm{dtype-static}.
    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.
     467Polymorphic 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.
    462468
    463469\CFA generic types also allow checked argument-constraints.
    … …  
    475481For example, the concrete instantiation for @pair( const char *, int )@ is:
    476482\begin{cfa}
    477 struct _pair_conc1 {
     483struct _pair_conc0 {
    478484        const char * first;
    479485        int second;
    … …  
    482488
    483489A concrete generic-type with dtype-static parameters is also expanded to a structure type, but this type is used for all matching instantiations.
    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 {
     490In 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}
     492struct _pair_conc1 {
    487493        void * first;
    488494        void * second;
    … …  
    496502As 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.
    497503Dynamic generic-types also have an \newterm{offset array} containing structure-member offsets.
    498 A dynamic generic-union needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.
     504A dynamic generic-@union@ needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.
    499505Access 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.
    500506
    … …  
    503509if 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.
    504510As 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 )@.
    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) }@.
     511The offset array @_offsetof_pair@ is generated at the call site as @size_t _offsetof_pair[] = { offsetof(_pair_conc0, first), offsetof(_pair_conc0, second) }@.
    506512
    507513In some cases the offset arrays cannot be statically generated.
    … …  
    586592\subsection{Tuple Expressions}
    587593
    588 The addition of multiple-return-value functions (MRVF) are useless without a syntax for accepting multiple values at the call-site.
     594The addition of multiple-return-value functions (MRVF) are \emph{useless} without a syntax for accepting multiple values at the call-site.
    589595The simplest mechanism for capturing the return values is variable assignment, allowing the values to be retrieved directly.
    590596As 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}.
    … …  
    822828\end{cfa}
    823829so the thunk provides flattening and structuring conversions to inferred functions, improving the compatibility of tuples and polymorphism.
    824 These thunks take advantage of gcc C nested-functions to produce closures that have the usual function-pointer signature.
     830These thunks take advantage of gcc C nested-functions to produce closures that have the usual function-pointer signature WHAT DOES THIS MEAN???.
    825831
    826832
    … …  
    878884        print(arg);  print(rest);
    879885}
    880 void print( char * x ) { printf( "%s", x ); }
     886void print( const char * x ) { printf( "%s", x ); }
    881887void print( int x ) { printf( "%d", x ); }
    882888void print( S s ) { print( "{ ", s.x, ",", s.y, " }" ); }
    … …  
    887893The polymorphic @print@ allows printing any list of types, where as each individual type has a @print@ function.
    888894The individual print functions can be used to build up more complicated @print@ functions, such as @S@, which cannot be done with @printf@ in C.
     895This mechanism is used to seamlessly print tuples in the \CFA I/O library (see Section~\ref{s:IOLibrary}).
    889896
    890897Finally, it is possible to use @ttype@ polymorphism to provide arbitrary argument forwarding functions.
    … …  
    10781085While 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.
    10791086For 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
    10801088Collectively, these enhancements reduce programmer burden and increase readability and safety.
    10811089
    … …  
    12371245\end{figure}
    12381246
    1239 Both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:
     1247With respect to safety, both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:
    12401248\begin{itemize}
    12411249\item
    … …  
    12501258With @goto@, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
    12511259Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
    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.
     1260Otherwise, the implicit targets of the current @continue@ and @break@, \ie the closest enclosing loop or @switch@, change as certain constructs are added or removed.
    12531261
    12541262
    12551263\subsection{Exception Handling}
    12561264
    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}).
     1265The 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}.
    12591267Both 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.
    12601268\CFA restricts exception types to those defined by aggregate type @exception@.
    … …  
    13331341resume( $\emph{alternate-stack}$ )
    13341342\end{cfa}
    1335 These overloads of @resume@ raise the specified exception or the currently propagating exception (reresume) at another coroutine or task~\cite{Delisle18}.
     1343These 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.}
    13361344Nonlocal 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.
    13371345
    … …  
    13581366Specifying no exception type is shorthand for specifying all exception types.
    13591367Both @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.
     1368Coroutines 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}
     1370void 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}
    13601379
    13611380Finally, \CFA provides a Java like  @finally@ clause after the catch clauses:
    … …  
    14611480Qualification or a cast is used to disambiguate.
    14621481
    1463 There is an interesting problem between parameters and the function @with@, \eg:
     1482There is an interesting problem between parameters and the function-body @with@, \eg:
    14641483\begin{cfa}
    14651484void ?{}( S & s, int i ) with ( s ) {           $\C{// constructor}$
    … …  
    14671486}
    14681487\end{cfa}
    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@.
     1488Here, 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@.
    14701489To solve this problem, parameters are treated like an initialized aggregate:
    14711490\begin{cfa}
    … …  
    14751494} params;
    14761495\end{cfa}
    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;
     1496and implicitly opened \emph{after} a function-body open, to give them higher priority:
     1497\begin{cfa}
     1498void ?{}( S & s, int `i` ) with ( s ) `with( $\emph{\color{red}params}$ )` {
     1499        s.i = `i`; j = 3; m = 5.5;
    14811500}
    14821501\end{cfa}
    … …  
    15391558While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
    15401559
    1541 \CFA provides its own type, variable and function declarations, using a different syntax.
     1560\CFA provides its own type, variable and function declarations, using a different syntax~\cite[pp.~856--859]{Buhr94a}.
    15421561The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right.
    15431562The qualifiers have the same meaning but are ordered left to right to specify a variable's type.
    … …  
    19511970}
    19521971\end{cfa}
    1953 (Note, the example is purposely kept simple by using shallow-copy semantics.)
     1972(Note, the example is purposely simplified using shallow-copy semantics.)
    19541973An 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).
    19551974\begin{cfa}
    … …  
    20042023C 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.
    20052024In 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.
    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@.
     2025
     2026A 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.
    20072028
    20082029
    … …  
    20142035\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
    20152036\begin{cfa}
    2016 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
     203720_`hh`     // signed char
     203821_`hhu`   // unsigned char
     203922_`h`       // signed short int
     204023_`uh`     // unsigned short int
     204124_`z`       // size_t
     2042\end{cfa}
     2043&
     2044\begin{cfa}
     204520_`L8`      // int8_t
     204621_`ul8`     // uint8_t
     204722_`l16`     // int16_t
     204823_`ul16`   // uint16_t
     204924_`l32`     // int32_t
     2050\end{cfa}
     2051&
     2052\begin{cfa}
     205325_`ul32`      // uint32_t
     205426_`l64`        // int64_t
     205527_`l64u`      // uint64_t
     205626_`L128`     // int128
     205727_`L128u`   // unsigned int128
    20372058\end{cfa}
    20382059\end{tabular}
    … …  
    20732094After which, user literals must match (no conversions);
    20742095hence, 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.
    20762096
    20772097\begin{figure}
    … …  
    21252145        w = 155|_lb|;
    21262146        w = 0b1111|_lb|;       // error, binary unsupported
    2127         w = 0${\color{red}'}$233|_lb|;          // quote separator
     2147        w = 0${\color{red}\LstBasicStyle{'}}$233|_lb|;          // quote separator
    21282148        w = 0x9b|_kg|;
    21292149        w = 5.5d|_st| + 8|_kg| + 25.01|_lb| + heavy;
    … …  
    22872307\begin{description}[topsep=3pt,itemsep=2pt,parsep=0pt]
    22882308\item[fill]
    2289 after allocation the storage is filled with a specified character.
     2309an allocation with a specified character.
    22902310\item[resize]
    2291 an existing allocation is decreased or increased in size.
     2311an existing allocation to decreased or increased its size.
    22922312In 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.
    22932313For an increase in storage size, new storage after the copied data may be filled.
    22942314\item[alignment]
    2295 an allocation starts on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes.
     2315an allocation on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes.
    22962316\item[array]
    2297 the allocation size is scaled to the specified number of array elements.
     2317allocation of the specified number of elements.
    22982318An array may be filled, resized, or aligned.
    22992319\end{description}
    23002320Table~\ref{t:StorageManagementOperations} shows the capabilities provided by C/\Celeven allocation-functions and how all the capabilities can be combined into two \CFA functions.
    23012321\CFA storage-management functions extend the C equivalents by overloading, providing shallow type-safety, and removing the need to specify the base allocation-size.
    2302 Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage-allocation operation performing the same operations with the same type safety.
     2322Figure~\ref{f:StorageAllocation} contrasts \CFA and C storage-allocation performing the same operations with the same type safety.
    23032323
    23042324\begin{table}
    … …  
    24432463\end{cfa}
    24442464\\
    2445 \textbf{output:}
    24462465&
    24472466\begin{cfa}[showspaces=true,aboveskip=0pt]
    … …  
    26772696\subsection{Control Structures / Declarations / Literals}
    26782697
     2698Java has default fall through like C/\CC.
     2699Pascal/Ada/Go/Rust do not have default fall through.
     2700\Csharp does not have fall through but still requires a break.
     2701Python uses dictionary mapping. \\
     2702\CFA choose is like Rust match.
     2703
     2704Java has labelled break/continue. \\
     2705Languages with and without exception handling.
     2706
     2707Alternative C declarations. \\
     2708Different references \\
     2709Constructors/destructors
     2710
     27110/1 Literals \\
     2712user defined: D, Objective-C
    26792713
    26802714\section{Conclusion and Future Work}
    … …  
    26832717While 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.
    26842718The 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.
    2685 The contributions are a powerful type-system using parametric polymorphism and overloading, generic types, and tuples, which all have complex interactions.
     2719The 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.
    26862720The work is a challenging design, engineering, and implementation exercise.
    26872721On the surface, the project may appear as a rehash of similar mechanisms in \CC.
    … …  
    26902724Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable.
    26912725
    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.
     2726There is ongoing work on a wide range of \CFA feature extensions, including arrays with size, user-defined conversions, concurrent primitives, and modules.
    26932727(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.)
    26942728In addition, there are interesting future directions for the polymorphism design.
    … …  
    27032737\section{Acknowledgments}
    27042738
    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.
     2739The 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.
     2740This 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.
    27072741
    27082742% 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.