Changes in doc/rob_thesis/tuples.tex [12d3187:0111dc7]

File:

• doc/rob_thesis/tuples.tex (modified) (11 diffs)

doc/rob_thesis/tuples.tex

@@ -161 +161 @@
 \end{cfacode}
 
-\begin{sloppypar}
 In addition to variables of tuple type, it is also possible to have pointers to tuples, and arrays of tuples.
-Tuple types can be composed of any types, except for array types, since array assignment is disallowed, which makes tuple assignment difficult when a tuple contains an array.
+Tuple types can be composed of any types, except for array types, since arrays do not carry their size around, which makes tuple assignment difficult when a tuple contains an array.
 \begin{cfacode}
 [double, int] di;
@@ -170 +169 @@
 \end{cfacode}
 This examples declares a variable of type @[double, int]@, a variable of type pointer to @[double, int]@, and an array of ten @[double, int]@.
-\end{sloppypar}
 
 \subsection{Tuple Indexing}
@@ -214 +212 @@
 The flexible structure of tuples permits a simple and expressive function-call syntax to work seamlessly with both single- and multiple-return-value functions, and with any number of arguments of arbitrarily complex structure.
 
-In \KWC \cite{Buhr94a,Till89}, there were 4 tuple coercions: opening, closing, flattening, and structuring.
+In \KWC \cite{Buhr94a,Till89}, a precursor to \CFA, there were 4 tuple coercions: opening, closing, flattening, and structuring.
 Opening coerces a tuple value into a tuple of values, while closing converts a tuple of values into a single tuple value.
 Flattening coerces a nested tuple into a flat tuple, \ie it takes a tuple with tuple components and expands it into a tuple with only non-tuple components.
@@ -220 +218 @@
 
 In \CFA, the design has been simplified to require only the two conversions previously described, which trigger only in function call and return situations.
-This simplification is a primary contribution of this thesis to the design of tuples in \CFA.
 Specifically, the expression resolution algorithm examines all of the possible alternatives for an expression to determine the best match.
 In resolving a function call expression, each combination of function value and list of argument alternatives is examined.
@@ -257 +254 @@
 Let $L_i$ for $i$ in $[0, n)$ represent each component of the flattened left side, $R_i$ represent each component of the flattened right side of a multiple assignment, and $R$ represent the right side of a mass assignment.
 
-For a multiple assignment to be valid, both tuples must have the same number of elements when flattened.
-For example, the following is invalid because the number of components on the left does not match the number of components on the right.
-\begin{cfacode}
-[int, int] x, y, z;
-[x, y] = z;   // multiple assignment, invalid 4 != 2
-\end{cfacode}
-Multiple assignment assigns $R_i$ to $L_i$ for each $i$.
+For a multiple assignment to be valid, both tuples must have the same number of elements when flattened. Multiple assignment assigns $R_i$ to $L_i$ for each $i$.
 That is, @?=?(&$L_i$, $R_i$)@ must be a well-typed expression.
 In the previous example, @[x, y] = z@, @z@ is flattened into @z.0, z.1@, and the assignments @x = z.0@ and @y = z.1@ happen.
@@ -274 +265 @@
 
 Both kinds of tuple assignment have parallel semantics, such that each value on the left side and right side is evaluated \emph{before} any assignments occur.
-As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function.
+As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function,
 \begin{cfacode}
 int x = 10, y = 20;
@@ -305 +296 @@
 \subsection{Tuple Construction}
 Tuple construction and destruction follow the same rules and semantics as tuple assignment, except that in the case where there is no right side, the default constructor or destructor is called on each component of the tuple.
-As constructors and destructors did not exist in previous versions of \CFA or in \KWC, this is a primary contribution of this thesis to the design of tuples.
 \begin{cfacode}
 struct S;
@@ -443 +433 @@
 \section{Casting}
 In C, the cast operator is used to explicitly convert between types.
-In \CFA, the cast operator has a secondary use, which is type ascription, since it forces the expression resolution algorithm to choose the lowest cost conversion to the target type.
+In \CFA, the cast operator has a secondary use, which is type ascription, since it force the expression resolution algorithm to choose the lowest cost conversion to the target type.
 That is, a cast can be used to select the type of an expression when it is ambiguous, as in the call to an overloaded function.
 \begin{cfacode}
@@ -497 +487 @@
 \section{Polymorphism}
 Due to the implicit flattening and structuring conversions involved in argument passing, @otype@ and @dtype@ parameters are restricted to matching only with non-tuple types.
-The integration of polymorphism, type assertions, and monomorphic specialization of tuple-assertions are a primary contribution of this thesis to the design of tuples.
 \begin{cfacode}
 forall(otype T, dtype U)
@@ -535 +524 @@
 It is also important to note that these calls could be disambiguated if the function return types were different, as they likely would be for a reasonable implementation of @?+?@, since the return type is used in overload resolution.
 Still, these semantics are a deficiency of the current argument matching algorithm, and depending on the function, differing return values may not always be appropriate.
-These issues could be rectified by applying an appropriate conversion cost to the structuring and flattening conversions, which are currently 0-cost conversions in the expression resolver.
+These issues could be rectified by applying an appropriate cost to the structuring and flattening conversions, which are currently 0-cost conversions.
 Care would be needed in this case to ensure that exact matches do not incur such a cost.
 \begin{cfacode}
@@ -570 +559 @@
 \section{Implementation}
 Tuples are implemented in the \CFA translator via a transformation into generic types.
-Generic types are an independent contribution developed at the same time.
-The transformation into generic types and the generation of tuple-specific code are primary contributions of this thesis to tuples.
-
 The first time an $N$-tuple is seen for each $N$ in a scope, a generic type with $N$ type parameters is generated.
 For example,