Ignore:
Timestamp:
Apr 7, 2017, 6:25:23 PM (5 years ago)
Author:
Rob Schluntz <rschlunt@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
2ccb93c
Parents:
c51b5a3
Message:

thesis conclusions and editting pass

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/rob_thesis/conclusions.tex

    rc51b5a3 rf92aa32  
    33%======================================================================
    44
    5 Conclusion paragraphs.
     5\section{Constructors and Destructors}
     6\CFA supports the RAII idiom using constructors and destructors.
     7There are many engineering challenges in introducing constructors and destructors, partially since \CFA is not an object-oriented language.
     8By making use of managed types, \CFA programmers are afforded an extra layer of safety and ease of use in comparison to C programmers.
     9While constructors and destructors provide a sensible default behaviour, \CFA allows experienced programmers to declare unmanaged objects to take control of object management for performance reasons.
     10Constructors and destructors as named functions fit the \CFA polymorphism model perfectly, allowing polymorphic code to use managed types seamlessly.
     11
     12\section{Tuples}
     13\CFA can express functions with multiple return values in a way that is simple, concise, and safe.
     14The addition of multiple-return-value functions naturally requires a way to use multiple return values, which begets tuple types.
     15Tuples provide two useful notions of assignment: multiple assignment, allowing simple, yet expressive assignment between multiple variables, and mass assignment, allowing a lossless assignment of a single value across multiple variables.
     16Tuples have a flexible structure that allows the \CFA type-system to decide how to restructure tuples, making it syntactically simple to pass tuples between functions.
     17Tuple types can be combined with polymorphism and tuple conversions can apply during assertion inference to produce a cohesive feel.
     18
     19\section{Variadic Functions}
     20Type-safe variadic functions of a similar feel to variadic templates are added to \CFA.
     21The new variadic functions can express complicated recursive algorithms.
     22Unlike variadic templates, it is possible to write @new@ as a library routine and to separately compile @ttype@ polymorphic functions.
     23Variadic functions are statically type checked and provide a user experience that is consistent with that of tuples and polymorphic functions.
    624
    725\section{Future Work}
    8 
    926\subsection{Constructors and Destructors}
    10 % TODO: discuss move semantics; they haven't been implemented, but could be. Currently looking at alternative models.
    11 
    12 % TODO: discuss exceptions
    13 
    14 % TODO: fix return value destruction in full compiler
    15 
    16 % TODO: once deleted functions are added, unions can have deleted standard functions, like C++11 (may not need to mention this again...)
    17 
    18 % TODO: better study and fix the ways @= objects interact with the rest of the world (e.g. provide @= equivalent for assignment, or otherwise have @= objects default to using intrinsic/autogen ops?)
    19 
    20 
     27Both \CC and Rust support move semantics, which expand the user's control of memory management by providing the ability to transfer ownership of large data, rather than forcing potentially expensive copy semantics.
     28\CFA currently does not support move semantics, partially due to the complexity of the model.
     29The design space is currently being explored with the goal of finding an alternative to move semantics that provides necessary performance benefits, while reducing the amount of repetition required to create a new type, along with the cognitive burden placed on the user.
     30
     31Exception handling is among the features expected to be added to \CFA in the near future.
     32For exception handling to properly interact with the rest of the language, it must ensure all RAII guarantees continue to be met.
     33That is, when an exception is raised, it must properly unwind the stack by calling the destructors for any objects that live between the raise and the handler.
     34This can be accomplished either by augmenting the translator to properly emit code that executes the destructors, or by switching destructors to hook into the GCC @cleanup@ attribute \cite[6.32.1]{GCCExtensions}.
     35
     36The @cleanup@ attribute, which is attached to a variable declaration, takes a function name as an argument and schedules that routine to be executed when the variable goes out of scope.
     37\begin{cfacode}
     38struct S { int x; };
     39void __dtor_S(struct S *);
     40{
     41  __attribute__((cleanup(__dtor_S))) struct S s;
     42} // calls __dtor_S(&s)
     43\end{cfacode}
     44This mechanism is known and understood by GCC, so that the destructor is properly called in any situation where a variable goes out of scope, including function returns, branches, and built-in GCC exception handling mechanisms using libunwind.
     45
     46A caveat of this approach is that the @cleanup@ attribute only permits a name that refers to a function that consumes a single argument of type @T *@ for a variable of type @T@.
     47This means that any destructor that consumes multiple arguments (e.g., because it is polymorphic) or any destructor that is a function pointer (e.g., because it is an assertion parameter) must be called through a local thunk.
     48For example,
     49\begin{cfacode}
     50forall(otype T)
     51struct Box {
     52  T x;
     53};
     54forall(otype T) void ^?{}(Box(T) * x);
     55
     56forall(otype T)
     57void f(T x) {
     58  T y = x;
     59  Box(T) z = { x };
     60}
     61\end{cfacode}
     62currently generates the following
     63\begin{cfacode}
     64void _dtor_BoxT(  // consumes more than 1 parameter due to assertions
     65  void (*_adapter_PTT)(void (*)(), void *, void *),
     66  void (*_adapter_T_PTT)(void (*)(), void *, void *, void *),
     67  long unsigned int _sizeof_T,
     68  long unsigned int _alignof_T,
     69  void *(*_assign_T_PTT)(void *, void *),
     70  void (*_ctor_PT)(void *),
     71  void (*_ctor_PTT)(void *, void *),
     72  void (*_dtor_PT)(void *),
     73  void *x
     74);
     75
     76void f(
     77  void (*_adapter_PTT)(void (*)(), void *, void *),
     78  void (*_adapter_T_PTT)(void (*)(), void *, void *, void *),
     79  long unsigned int _sizeof_T,
     80  long unsigned int _alignof_T,
     81  void *(*_assign_TT)(void *, void *),
     82  void (*_ctor_T)(void *),
     83  void (*_ctor_TT)(void *, void *),
     84  void (*_dtor_T)(void *),
     85  void *x
     86){
     87  void *y = __builtin_alloca(_sizeof_T);
     88  // constructor call elided
     89
     90  // generic layout computation elided
     91  long unsigned int _sizeof_BoxT = ...;
     92  void *z = __builtin_alloca(_sizeof_BoxT);
     93  // constructor call elided
     94
     95  _dtor_BoxT(  // ^?{}(&z); -- _dtor_BoxT has > 1 arguments
     96    _adapter_PTT,
     97    _adapter_T_PTT,
     98    _sizeof_T,
     99    _alignof_T,
     100    _assign_TT,
     101    _ctor_T,
     102    _ctor_TT,
     103    _dtor_T,
     104    z
     105  );
     106  _dtor_T(y);  // ^?{}(&y); -- _dtor_T is a function pointer
     107}
     108\end{cfacode}
     109Further to this point, every distinct array type will require a thunk for its destructor, where array destructor code is currently inlined, since array destructors hard code the length of the array.
     110
     111For function call temporaries, new scopes have to be added for destructor ordering to remain consistent.
     112In particular, the translator currently destroys argument and return value temporary objects as soon as the statement they were created for ends.
     113In order for this behaviour to be maintained, new scopes have to be added around every statement that contains a function call.
     114Since a nested expression can raise an exception, care must be taken when destroying temporary objects.
     115One way to achieve this is to split statements at every function call, to provide the correct scoping to destroy objects as necessary.
     116For example,
     117\begin{cfacode}
     118struct S { ... };
     119void ?{}(S *, S);
     120void ^?{}(S *);
     121
     122S f();
     123S g(S);
     124
     125g(f());
     126\end{cfacode}
     127would generate
     128\begin{cfacode}
     129struct S { ... };
     130void _ctor_S(struct S *, struct S);
     131void _dtor_S(struct S *);
     132
     133{
     134  __attribute__((cleanup(_dtor_S))) struct S _tmp1 = f();
     135  __attribute__((cleanup(_dtor_S))) struct S _tmp2 =
     136    (_ctor_S(&_tmp2, _tmp1), _tmp2);
     137  __attribute__((cleanup(_dtor_S))) struct S _tmp3 = g(_tmp2);
     138} // destroy _tmp3, _tmp2, _tmp1
     139\end{cfacode}
     140Note that destructors must be registered after the temporary is fully initialized, since it is possible for initialization expressions to raise exceptions, and a destructor should never be called on an uninitialized object.
     141This requires a slightly strange looking initializer for constructor calls, where a comma expression is used to produce the value of the object being initialized, after the constructor call, conceptually bitwise copying the initialized data into itself.
     142Since this copy is wholly unnecessary, it is easily optimized away.
     143
     144A second approach is to attach an accompanying boolean to every temporary that records whether the object contains valid data, and thus whether the value should be destructed.
     145\begin{cfacode}
     146struct S { ... };
     147void _ctor_S(struct S *, struct S);
     148void _dtor_S(struct S *);
     149
     150struct __tmp_bundle_S {
     151  bool valid;
     152  struct S value;
     153};
     154
     155void _dtor_tmpS(struct __tmp_bundle_S * ret) {
     156  if (ret->valid) {
     157    _dtor_S(&ret->value);
     158  }
     159}
     160
     161{
     162  __attribute__((cleanup(_dtor_tmpS))) struct __tmp_bundle_S _tmp1 = { 0 };
     163  __attribute__((cleanup(_dtor_tmpS))) struct __tmp_bundle_S _tmp2 = { 0 };
     164  __attribute__((cleanup(_dtor_tmpS))) struct __tmp_bundle_S _tmp3 = { 0 };
     165  _tmp2.value = g(
     166    (_ctor_S(
     167      &_tmp2.value,
     168      (_tmp1.value = f(), _tmp1.valid = 1, _tmp1.value)
     169    ), _tmp2.valid = 1, _tmp2.value)
     170  ), _tmp3.valid = 1, _tmp3.value;
     171} // destroy _tmp3, _tmp2, _tmp1
     172\end{cfacode}
     173In particular, the boolean is set immediately after argument construction and immediately after return value copy.
     174The boolean is checked as a part of the @cleanup@ routine, forwarding to the object's destructor if the object is valid.
     175One such type and @cleanup@ routine needs to be generated for every type used in a function parameter or return value.
     176
     177The former approach generates much simpler code, however splitting expressions requires care to ensure that expression evaluation order does not change.
     178Expression ordering has to be performed by a full compiler, so it is possible that the latter approach would be more suited to the \CFA prototype, whereas the former approach is clearly the better option in a full compiler.
     179More investigation is needed to determine whether the translator's current design can easily handle proper expression ordering.
     180
     181As discussed in Section \ref{s:implicit_copy_construction}, return values are destructed with a different @this@ pointer than they are constructed with.
     182This problem can be easily fixed once a full \CFA compiler is built, since it would have full control over the call/return mechanism.
     183In particular, since the callee is aware of where it needs to place the return value, it can construct the return value directly, rather than bitwise copy the internal data.
     184
     185Currently, the special functions are always auto-generated, except for generic types where the type parameter does not have assertions for the corresponding operation.
     186For example,
     187\begin{cfacode}
     188forall(dtype T | sized(T) | { void ?{}(T *); })
     189struct S { T x; };
     190\end{cfacode}
     191will only auto-generate the default constructor for @S@, since the member @x@ is missing the other 3 special functions.
     192Once deleted functions have been added, function generation can make use of this information to disable generation of special functions when a member has a deleted function.
     193For example,
     194\begin{cfacode}
     195struct A {};
     196void ?{}(A *) = delete;
     197struct S { A x; };  // does not generate void ?{}(S *);
     198\end{cfacode}
     199
     200Unmanaged objects and their interactions with the managed \CFA environment are an open problem that deserves greater attention.
     201In particular, the interactions between unmanaged objects and copy semantics are subtle and can easily lead to errors.
     202It is possible that the compiler should mark some of these situations as errors by default, and possibly conditionally emit warnings for some situations.
     203Another possibility is to construct, destruct, and assign unmanaged objects using the intrinsic and auto-generated functions.
     204A more thorough examination of the design space for this problem is required.
     205
     206Currently, the \CFA translator does not support any warnings.
     207Ideally, the translator should support optional warnings in the case where it can detect that an object has been constructed twice.
     208For example, forwarding constructor calls are guaranteed to initialize the entire object, so redundant constructor calls can cause problems such as memory leaks, while looking innocuous to a novice user.
     209\begin{cfacode}
     210struct B { ... };
     211struct A {
     212        B x, y, z;
     213};
     214void ?{}(A * a, B x) {
     215        // y, z implicitly default constructed
     216        (&a->x){ ... }; // explicitly construct x
     217} // constructs an entire A
     218void ?{}(A * a) {
     219        (&a->y){}; // initialize y
     220        a{ (B){ ... } }; // forwarding constructor call
     221                         // initializes entire object, including y
     222}
     223\end{cfacode}
     224
     225Finally, while constructors provide a mechanism for establishing invariants, there is currently no mechanism for maintaining invariants without resorting to opaque types.
     226That is, structure fields can be accessed and modified by any block of code without restriction, so while it's possible to ensure that an object is initially set to a valid state, it isn't possible to ensure that it remains in a consistent state throughout its lifetime.
     227A popular technique for ensuring consistency in object-oriented programming languages is to provide access modifiers such as @private@, which provides compile-time checks that only privileged code accesses private data.
     228This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged.
     229One possibility is to tie access control into an eventual module system.
    21230
    22231\subsection{Tuples}
    23 
    24 % TODO: named return values are not currently implemented in CFA - tie in with named tuples?
    25 
    26 % TODO: tuples are allowed in expressions, exact meaning is defined by operator overloading (e.g. can add tuples). An important caveat to note is that it is currently impossible to allow adding two triples but prevent adding a pair with a quadruple (single flattening/structuring conversions are implicit, only total number of components matters). May be able to solve this with more nuanced conversion rules
     232Named result values are planned, but not yet implemented.
     233This feature ties nicely into named tuples, as seen in D and Swift.
     234
     235Currently, tuple flattening and structuring conversions are 0-cost.
     236This makes tuples conceptually very simple to work with, but easily causes unnecessary ambiguity in situations where the type system should be able to differentiate between alternatives.
     237Adding an appropriate cost function to tuple conversions will allow tuples to interact with the rest of the programming language more cohesively.
    27238
    28239\subsection{Variadic Functions}
    29 % TODO: look into 'nicer' expansion syntax
    30 
    31 % TODO: consider more sophisticated argument matching algorithms, e.g. forall(ttype Params) void f(Params, Params); f(1,2); f(1,2,3,4); => f([1], [2]); f([1,2], [3,4]); => okay if Params can be bound to a type that is consistent throughout the expression's type
    32 
    33 
     240Use of @ttype@ functions currently relies heavily on recursion.
     241\CC has opened variadic templates up so that recursion isn't strictly necessary in some cases, and it would be interesting to see if any such cases can be applied to \CFA.
     242
     243\CC supports variadic templated data types, making it possible to express arbitrary length tuples, arbitrary parameter function objects, and more with generic types.
     244Currently, \CFA does not support @ttype@-parameter generic types, though there does not appear to be a technical reason that it cannot.
     245Notably, opening up support for this makes it possible to implement the exit form of scope guard (see section \ref{s:ResMgmt}), making it possible to call arbitrary functions at scope exit in idiomatic \CFA.
Note: See TracChangeset for help on using the changeset viewer.