Changeset d1ef1b0 for doc/aaron_comp_II

Aug 6, 2016, 3:37:44 PM (5 years ago)
Aaron Moss <a3moss@…>
aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc

Finished traits subsection of Comp II draft

1 edited


  • doc/aaron_comp_II/comp_II.tex

    ra2f920f rd1ef1b0  
    135135For instance, ©twice© could have been defined as below, using the \CFA syntax for operator overloading:
    137 forall(otype S | { S ?+?(S, S); })
     137forall(otype S | { ®S ?+?(S, S);® })
    138138S twice(S x) { return x + x; }  // (2)
    149149\CFA provides \emph{traits} as a means to name a group of type assertions, as in the example below:
    151 trait has_magnitude(otype T) {
     151®trait has_magnitude(otype T)® {
    152152    bool ?<?(T, T);        // comparison operator for T
    153153    T -?(T);               // negation operator for T
    170 Semantically, a trait is merely a named list of type assertions, but they can be used in many of the same situations where an interface in Java or an abstract base class in \CC would be used.
     170Semantically, a trait is simply a named list of type assertions, but one can be used for many of the same purposes that an interface in Java or an abstract base class in \CC would be used for.
    171171Unlike Java interfaces or \CC base classes, \CFA types do not explicitly state any inheritance relationship to traits they satisfy; this can be considered a form of structural inheritance, similar to interface implementation in Go, as opposed to the nominal inheritance model of Java and \CC.
    172 % TODO talk about modelling of nominal inheritance with structural inheritance, possibility of investigating some resolver algorithms that require nominal
     172Nominal inheritance can be simulated with traits using marker variables or functions:
     174trait nominal(otype T) {
     175    ®T is_nominal;®
     178int is_nominal;  // int now satisfies the nominal trait
     180    char is_nominal; // char satisfies the nominal trait
     182// char no longer satisfies the nominal trait here 
     185Traits, however, are significantly more powerful than nominal-inheritance interfaces; firstly, due to the scoping rules of the declarations which satisfy a trait's type assertions, a type may not satisfy a trait everywhere that the type is declared, as with ©char© and the ©nominal© trait above.
     186Secondly, traits may be used to declare a relationship between multiple types, a property which may be difficult or impossible to represent in nominal-inheritance type systems:
     188trait pointer_like(®otype Ptr, otype El®) {
     189    lvalue El *?(Ptr); // Ptr can be dereferenced into a modifiable value of type El
     192struct list {
     193    int value;
     194    list *next;  // may omit "struct" on type names in \CFA
     197typedef list* list_iterator;
     199lvalue int *?( list_iterator it ) {
     200    return it->value;
     204In the example above, ©list_iterator, int© satisfies ©pointer_like© by the given function, and ©list_iterator, list© also satisfies ©pointer_like© by the default pointer dereference operator.
     205While a nominal-inheritance system with associated types could model one of those two relationships by making ©El© an associated type of ©Ptr© in the ©pointer_like© implementation, few such systems could model both relationships simultaneously.
     207The flexibility of \CFA's implicit trait satisfaction mechanism provides user programmers with a great deal of power, but also blocks some optimization approaches for expression resolution.
     208The ability of types to begin to or cease to satisfy traits when declarations go into or out of scope makes caching of trait satisfaction judgements difficult, and the ability of traits to take multiple type parameters could lead to a combinatorial explosion of work in any attempt to pre-compute trait satisfaction relationships.
     209On the other hand, the addition of a nominal inheritance mechanism to \CFA's type system or replacement of \CFA's trait satisfaction system with a more object-oriented inheritance model and investigation of possible expression resolution optimizations for such a system may be an interesting avenue of further research.
    174211\subsection{Name Overloading}
Note: See TracChangeset for help on using the changeset viewer.