Changeset d1ef1b0 for doc/aaron_comp_II


Ignore:
Timestamp:
Aug 6, 2016, 3:37:44 PM (5 years ago)
Author:
Aaron Moss <a3moss@…>
Branches:
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
Children:
752dc70
Parents:
a2f920f
Message:

Finished traits subsection of Comp II draft

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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:
    136136\begin{lstlisting}
    137 forall(otype S | { S ?+?(S, S); })
     137forall(otype S | { ®S ?+?(S, S);® })
    138138S twice(S x) { return x + x; }  // (2)
    139139\end{lstlisting}
     
    149149\CFA provides \emph{traits} as a means to name a group of type assertions, as in the example below:
    150150\begin{lstlisting}
    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
     
    168168\end{lstlisting}
    169169
    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:
     173\begin{lstlisting}
     174trait nominal(otype T) {
     175    ®T is_nominal;®
     176};
     177
     178int is_nominal;  // int now satisfies the nominal trait
     179{
     180    char is_nominal; // char satisfies the nominal trait
     181}
     182// char no longer satisfies the nominal trait here 
     183\end{lstlisting}
     184
     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:
     187\begin{lstlisting}
     188trait pointer_like(®otype Ptr, otype El®) {
     189    lvalue El *?(Ptr); // Ptr can be dereferenced into a modifiable value of type El
     190}
     191
     192struct list {
     193    int value;
     194    list *next;  // may omit "struct" on type names in \CFA
     195};
     196
     197typedef list* list_iterator;
     198
     199lvalue int *?( list_iterator it ) {
     200    return it->value;
     201}
     202\end{lstlisting}
     203
     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.
     206
     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.
    173210
    174211\subsection{Name Overloading}
Note: See TracChangeset for help on using the changeset viewer.