Changeset c331406 for doc/aaron_comp_II/comp_II.tex

Timestamp:

Aug 5, 2016, 11:03:04 AM (7 years ago)

Author:

Aaron Moss <a3moss@…>

Branches:

aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

a2f920f

Parents:

5070fe4 (diff), 1b0020a (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge changes from master

File:

• doc/aaron_comp_II/comp_II.tex (modified) (1 diff)

doc/aaron_comp_II/comp_II.tex

@@ -156 +156 @@
 
 forall(otype M | has_magnitude(M))
-int sgn( M m ) {
+M abs( M m ) {
     M zero = 0;  // uses zero_t constructor from trait
-    if ( m < zero ) return -1;
-    if ( zero < m ) return 1;
-    return 0; 
-}
-
-// TODO write another function
-\end{lstlisting} 
+    return m < zero ? -m : m;
+}
+
+forall(otype M | has_magnitude(M))
+M max_magnitude( M a, M b ) {
+    M aa = abs(a), ab = abs(b);
+    return aa < ab ? b : a; 
+}
+\end{lstlisting}
+
+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.
+Unlike 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. 
+% TODO talk about modelling of nominal inheritance with structural inheritance, possibility of investigating some resolver algorithms that require nominal
 
 \subsection{Name Overloading}