Context Navigation

-                      rc51b5a3
+                      rf92aa32
 \chapter{Tuples}
 %======================================================================
-\section{Introduction}
-% TODO: no passing input parameters by assignment, instead will have reference types => this is not a very C-like model and greatly complicates syntax for likely little gain (and would cause confusion with already supported return-by-reference)
-% TODO: benefits (conclusion) by Till: reduced number of variables and statements; no specified order of execution for multiple assignment (more optimzation freedom); can store parameter lists in variable; MRV routines (natural code); more convenient assignment statements; simple and efficient access of record fields; named return values more legible and efficient in use of storage
 \section{Multiple-Return-Value Functions}
 …
 This restriction results in code which emulates functions with multiple return values by \emph{aggregation} or by \emph{aliasing}.
 In the former situation, the function designer creates a record type that combines all of the return values into a single type.
+For example, consider a function returning the most frequently occuring letter in a string, and its frequency.
+% TODO: consider simplifying the example!
+%   Two things I like about this example:
+%   * it uses different types to illustrate why an array is insufficient (this is not necessary, but is nice)
+%   * it's complicated enough to show the uninitialized pitfall that exists in the aliasing example.
+%   Still, it may be a touch too complicated. Is there a simpler example with these two properties?
+For example, consider a function returning the most frequently occurring letter in a string, and its frequency.
+This example is complex enough to illustrate that an array is insufficient, since arrays are homogeneous, and demonstrates a potential pitfall that exists with aliasing.
 \begin{cfacode}
 struct mf_ret {
 …
 The expression resolution phase of the \CFA translator ensures that the correct form is used depending on the values being returned and the return type of the current function.
 A multiple-returning function with return type @T@ can return any expression that is implicitly convertible to @T@.
 Using the running example, the @most_frequent@ function can be written in using multiple return values as such,
+Using the running example, the @most_frequent@ function can be written using multiple return values as such,
 \begin{cfacode}
 [int, char] most_frequent(const char * str) {
 …
 These semantics allow cascading tuple assignment to work out naturally in any context where a tuple is permitted.
 These semantics are a change from the original tuple design in \KWC \cite{Till89}, wherein tuple assignment was a statement that allows cascading assignments as a special case.
+The \KWC semantics fix what was seen as a problem with assignment, wherein it can be used in many different locations, such as in function-call argument position. % TODO: remove??
+Restricting tuple assignment to statements was an attempt to to fix what was seen as a problem with assignment, wherein it can be used in many different locations, such as in function-call argument position.
 While permitting assignment as an expression does introduce the potential for subtle complexities, it is impossible to remove assignment expressions from \CFA without affecting backwards compatibility.
 Furthermore, there are situations where permitting assignment as an expression improves readability by keeping code succinct and reducing repetition, and complicating the definition of tuple assignment puts a greater cognitive burden on the user.
 …
 [S, S] z = x.0;        // uses (4), (4), copy constructor
 \end{cfacode}
 In this example, @x@ is initialized by the multiple constructor calls @?{}(&x.0, 3)@ and @?{}(&x.1, 6.28)@, while @y@ is initilaized by two default constructor calls @?{}(&y.0)@ and @?{}(&y.1)@.
+In this example, @x@ is initialized by the multiple constructor calls @?{}(&x.0, 3)@ and @?{}(&x.1, 6.28)@, while @y@ is initialized by two default constructor calls @?{}(&y.0)@ and @?{}(&y.1)@.
 @z@ is initialized by mass copy constructor calls @?{}(&z.0, x.0)@ and @?{}(&z.1, x.0)@.
 Finally, @x@, @y@, and @z@ are destructed, i.e. the calls @^?{}(&x.0)@, @^?{}(&x.1)@, @^?{}(&y.0)@, @^?{}(&y.1)@, @^?{}(&z.0)@, and @^?{}(&z.1)@.
 …
 z.y;  // ???
 \end{cfacode}
 One possiblity is for @s.1@ to select the second member of @s@.
+One possibility is for @s.1@ to select the second member of @s@.
 Under this interpretation, it becomes possible to not only access members of a struct by name, but also by position.
 Likewise, it seems natural to open this mechanism to enumerations as well, wherein the left side would be a type, rather than an expression.
 One benefit of this interpretation is familiar, since it is extremely reminiscent of tuple-index expressions.
+One benefit of this interpretation is familiarity, since it is extremely reminiscent of tuple-index expressions.
 On the other hand, it could be argued that this interpretation is brittle in that changing the order of members or adding new members to a structure becomes a brittle operation.
 This problem is less of a concern with tuples, since modifying a tuple affects only the code that directly uses the tuple, whereas modifying a structure has far reaching consequences for every instance of the structure.
 As for @z.y@, a one interpretation is to extend the meaning of member tuple expressions.
+As for @z.y@, one interpretation is to extend the meaning of member tuple expressions.
 That is, currently the tuple must occur as the member, i.e. to the right of the dot.
 Allowing tuples to the left of the dot could distribute the member across the elements of the tuple, in much the same way that member tuple expressions distribute the aggregate across the member tuple.
 …
 p1.0 + p1.1 + p2.0 + p2.1;  // equivalent
 \end{cfacode}
 In this simpler interpretation, a named tuple type carries with it a list of possibly empty identifiers.
+In this simpler interpretation, a tuple type carries with it a list of possibly empty identifiers.
 This approach fits naturally with the named return-value feature, and would likely go a long way towards implementing it.
 Ultimately, the first two extensions introduce complexity into the model, with relatively little peceived benefit, and so were dropped from consideration.
+Ultimately, the first two extensions introduce complexity into the model, with relatively little perceived benefit, and so were dropped from consideration.
 Named tuples are a potentially useful addition to the language, provided they can be parsed with a reasonable syntax.
 …
 \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.
+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}
 …
 \end{cfacode}
 Note that due to the implicit tuple conversions, this function is not restricted to the addition of two triples.
+A call to this plus operator type checks as long as a total of 6 non-tuple arguments are passed after flattening, and all of the arguments have a common type that can bind to @T@, with a pairwise @?+?@ over @T@.
 For example, these expressions also succeed and produce the same value.
-A call to this plus operator type checks as long as a total of 6 non-tuple arguments are passed after flattening, and all of the arguments have a common type that can bind to @T@, with a pairwise @?+?@ over @T@.
 \begin{cfacode}
 ([x.0, x.1]) + ([x.2, 10, 20, 30]);  // x + ([10, 20, 30])
 …
 \end{cfacode}
 This presents a potential problem if structure is important, as these three expressions look like they should have different meanings.
 Furthermore, these calls can be made ambiguous by adding seemingly different functions.
+Furthermore, these calls can be made ambiguous by introducing seemingly different functions.
 \begin{cfacode}
 forall(otype T | { T ?+?(T, T); })
 …
 g(h());
 \end{cfacode}
 Interally, this is converted to psuedo-\CFA
+Internally, this is converted to pseudo-\CFA
 \begin{cfacode}
 void g(int, double);
 [int, double] h();
 lazy [int, double] unq<0> = h();
 g(unq<0>.0, unq<0>.1);
+lazy [int, double] unq0 = h(); // deferred execution
+g(unq0.0, unq0.1);             // execute h() once
 \end{cfacode}
 That is, the function @h@ is evaluated lazily and its result is stored for subsequent accesses.
 …
 Every subsequent evaluation of the unique expression then results in an access to the stored result of the actual expression.
 Currently, the \CFA translator has a very broad, imprecise definition of impurity (side-effects), where any function call is assumed to be impure.
 This notion could be made more precise for certain intrinsic, autogenerated, and builtin functions, and could analyze function bodies, when they are available, to recursively detect impurity, to eliminate some unique expressions.
+Currently, the \CFA translator has a very broad, imprecise definition of impurity (side-effects), where every function call is assumed to be impure.
+This notion could be made more precise for certain intrinsic, auto-generated, and built-in functions, and could analyze function bodies, when they are available, to recursively detect impurity, to eliminate some unique expressions.
 It is possible that lazy evaluation could be exposed to the user through a lazy keyword with little additional effort.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset f92aa32 for doc/rob_thesis/tuples.tex

Legend:

doc/rob_thesis/tuples.tex

Download in other formats: