source: doc/rob_thesis/tuples.tex @ 9a9a5c4

Last change on this file since 9a9a5c4 was 0111dc7, checked in by Rob Schluntz <rschlunt@…>, 7 years ago

penultimate thesis draft

  • Property mode set to 100644
File size: 45.4 KB
5\section{Multiple-Return-Value Functions}
7In standard C, functions can return at most one value.
8This restriction results in code which emulates functions with multiple return values by \emph{aggregation} or by \emph{aliasing}.
9In the former situation, the function designer creates a record type that combines all of the return values into a single type.
10For example, consider a function returning the most frequently occurring letter in a string, and its frequency.
11This example is complex enough to illustrate that an array is insufficient, since arrays are homogeneous, and demonstrates a potential pitfall that exists with aliasing.
13struct mf_ret {
14  int freq;
15  char ch;
18struct mf_ret most_frequent(const char * str) {
19  char freqs [26] = { 0 };
20  struct mf_ret ret = { 0, 'a' };
21  for (int i = 0; str[i] != '\0'; ++i) {
22    if (isalpha(str[i])) {        // only count letters
23      int ch = tolower(str[i]);   // convert to lower case
24      int idx = ch-'a';
25      if (++freqs[idx] > ret.freq) {  // update on new max
26        ret.freq = freqs[idx];
27 = ch;
28      }
29    }
30  }
31  return ret;
34const char * str = "hello world";
35struct mf_ret ret = most_frequent(str);
36printf("%s -- %d %c\n", str, ret.freq,;
38Of note, the designer must come up with a name for the return type and for each of its fields.
39Unnecessary naming is a common programming language issue, introducing verbosity and a complication of the user's mental model.
40That is, adding another named type creates another association in the programmer's mind that needs to be kept track of when reading and writing code.
41As such, this technique is effective when used sparingly, but can quickly get out of hand if many functions need to return different combinations of types.
43In the latter approach, the designer simulates multiple return values by passing the additional return values as pointer parameters.
44The pointer parameters are assigned inside of the routine body to emulate a return.
45Using the same example,
47int most_frequent(const char * str, char * ret_ch) {
48  char freqs [26] = { 0 };
49  int ret_freq = 0;
50  for (int i = 0; str[i] != '\0'; ++i) {
51    if (isalpha(str[i])) {        // only count letters
52      int ch = tolower(str[i]);   // convert to lower case
53      int idx = ch-'a';
54      if (++freqs[idx] > ret_freq) {  // update on new max
55        ret_freq = freqs[idx];
56        *ret_ch = ch;   // assign to out parameter
57      }
58    }
59  }
60  return ret_freq;  // only one value returned directly
63const char * str = "hello world";
64char ch;                            // pre-allocate return value
65int freq = most_frequent(str, &ch); // pass return value as out parameter
66printf("%s -- %d %c\n", str, freq, ch);
68Notably, using this approach, the caller is directly responsible for allocating storage for the additional temporary return values, which complicates the call site with a sequence of variable declarations leading up to the call.
69Also, while a disciplined use of @const@ can give clues about whether a pointer parameter is going to be used as an out parameter, it is not immediately obvious from only the routine signature whether the callee expects such a parameter to be initialized before the call.
70Furthermore, while many C routines that accept pointers are designed so that it is safe to pass @NULL@ as a parameter, there are many C routines that are not null-safe.
71On a related note, C does not provide a standard mechanism to state that a parameter is going to be used as an additional return value, which makes the job of ensuring that a value is returned more difficult for the compiler.
72Interestingly, there is a subtle bug in the previous example, in that @ret_ch@ is never assigned for a string that does not contain any letters, which can lead to undefined behaviour.
73In this particular case, it turns out that the frequency return value also doubles as an error code, where a frequency of 0 means the character return value should be ignored.
74Still, not every routine with multiple return values should be required to return an error code, and error codes are easily ignored, so this is not a satisfying solution.
75As with the previous approach, this technique can simulate multiple return values, but in practice it is verbose and error prone.
77In \CFA, functions can be declared to return multiple values with an extension to the function declaration syntax.
78Multiple return values are declared as a comma-separated list of types in square brackets in the same location that the return type appears in standard C function declarations.
79The ability to return multiple values from a function requires a new syntax for the return statement.
80For consistency, the return statement in \CFA accepts a comma-separated list of expressions in square brackets.
81The 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.
82A multiple-returning function with return type @T@ can return any expression that is implicitly convertible to @T@.
83Using the running example, the @most_frequent@ function can be written using multiple return values as such,
85[int, char] most_frequent(const char * str) {
86  char freqs [26] = { 0 };
87  int ret_freq = 0;
88  char ret_ch = 'a';  // arbitrary default value for consistent results
89  for (int i = 0; str[i] != '\0'; ++i) {
90    if (isalpha(str[i])) {        // only count letters
91      int ch = tolower(str[i]);   // convert to lower case
92      int idx = ch-'a';
93      if (++freqs[idx] > ret_freq) {  // update on new max
94        ret_freq = freqs[idx];
95        ret_ch = ch;
96      }
97    }
98  }
99  return [ret_freq, ret_ch];
102This approach provides the benefits of compile-time checking for appropriate return statements as in aggregation, but without the required verbosity of declaring a new named type, which precludes the bug seen with out-parameters.
104The addition of multiple-return-value functions necessitates a syntax for accepting multiple values at the call-site.
105The simplest mechanism for retaining a return value in C is variable assignment.
106By assigning the return value into a variable, its value can be retrieved later at any point in the program.
107As such, \CFA allows assigning multiple values from a function into multiple variables, using a square-bracketed list of lvalue expressions on the left side.
109const char * str = "hello world";
110int freq;
111char ch;
112[freq, ch] = most_frequent(str);  // assign into multiple variables
113printf("%s -- %d %c\n", str, freq, ch);
115It is also common to use a function's output as the input to another function.
116\CFA also allows this case, without any new syntax.
117When a function call is passed as an argument to another call, the expression resolver attempts to find the best match of actual arguments to formal parameters given all of the possible expression interpretations in the current scope \cite{Bilson03}.
118For example,
120void process(int);       // (1)
121void process(char);      // (2)
122void process(int, char); // (3)
123void process(char, int); // (4)
125process(most_frequent("hello world"));  // selects (3)
127In this case, there is only one option for a function named @most_frequent@ that takes a string as input.
128This function returns two values, one @int@ and one @char@.
129There are four options for a function named @process@, but only two that accept two arguments, and of those the best match is (3), which is also an exact match.
130This expression first calls @most_frequent("hello world")@, which produces the values @3@ and @'l'@, which are fed directly to the first and second parameters of (3), respectively.
132\section{Tuple Expressions}
133Multiple-return-value functions provide \CFA with a new syntax for expressing a combination of expressions in the return statement and a combination of types in a function signature.
134These notions can be generalized to provide \CFA with \emph{tuple expressions} and \emph{tuple types}.
135A tuple expression is an expression producing a fixed-size, ordered list of values of heterogeneous types.
136The type of a tuple expression is the tuple of the subexpression types, or a \emph{tuple type}.
137In \CFA, a tuple expression is denoted by a comma-separated list of expressions enclosed in square brackets.
138For example, the expression @[5, 'x', 10.5]@ has type @[int, char, double]@.
139The previous expression has 3 \emph{components}.
140Each component in a tuple expression can be any \CFA expression, including another tuple expression.
141The order of evaluation of the components in a tuple expression is unspecified, to allow a compiler the greatest flexibility for program optimization.
142It is, however, guaranteed that each component of a tuple expression is evaluated for side-effects, even if the result is not used.
143Multiple-return-value functions can equivalently be called \emph{tuple-returning functions}.
145\subsection{Tuple Variables}
146The call-site of the @most_frequent@ routine has a notable blemish, in that it required the preallocation of return variables in a manner similar to the aliasing example, since it is impossible to declare multiple variables of different types in the same declaration in standard C.
147In \CFA, it is possible to overcome this restriction by declaring a \emph{tuple variable}.
148\begin{cfacode}[emph=ret, emphstyle=\color{red}]
149const char * str = "hello world";
150[int, char] ret = most_frequent(str);  // initialize tuple variable
151printf("%s -- %d %c\n", str, ret);
153It is now possible to accept multiple values into a single piece of storage, in much the same way that it was previously possible to pass multiple values from one function call to another.
154These variables can be used in any of the contexts where a tuple expression is allowed, such as in the @printf@ function call.
155As in the @process@ example, the components of the tuple value are passed as separate parameters to @printf@, allowing very simple printing of tuple expressions.
156One way to access the individual components is with a simple assignment, as in previous examples.
158int freq;
159char ch;
160[freq, ch] = ret;
163In addition to variables of tuple type, it is also possible to have pointers to tuples, and arrays of tuples.
164Tuple 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.
166[double, int] di;
167[double, int] * pdi
168[double, int] adi[10];
170This examples declares a variable of type @[double, int]@, a variable of type pointer to @[double, int]@, and an array of ten @[double, int]@.
172\subsection{Tuple Indexing}
173At times, it is desirable to access a single component of a tuple-valued expression without creating unnecessary temporary variables to assign to.
174Given a tuple-valued expression @e@ and a compile-time constant integer $i$ where $0 \leq i < n$, where $n$ is the number of components in @e@, @e.i@ accesses the $i$\textsuperscript{th} component of @e@.
175For example,
177[int, double] x;
178[char *, int] f();
179void g(double, int);
180[int, double] * p;
182int y = x.0;              // access int component of x
183y = f().1;                // access int component of f
184p->0 = 5;                 // access int component of tuple pointed-to by p
185g(x.1, x.0);              // rearrange x to pass to g
186double z = [x, f()].0.1;  // access second component of first component
187                          // of tuple expression
189As seen above, tuple-index expressions can occur on any tuple-typed expression, including tuple-returning functions, square-bracketed tuple expressions, and other tuple-index expressions, provided the retrieved component is also a tuple.
190This feature was proposed for \KWC but never implemented \cite[p.~45]{Till89}.
192\subsection{Flattening and Structuring}
193As evident in previous examples, tuples in \CFA do not have a rigid structure.
194In function call contexts, tuples support implicit flattening and restructuring conversions.
195Tuple flattening recursively expands a tuple into the list of its basic components.
196Tuple structuring packages a list of expressions into a value of tuple type.
198int f(int, int);
199int g([int, int]);
200int h(int, [int, int]);
201[int, int] x;
202int y;
204f(x);      // flatten
205g(y, 10);  // structure
206h(x, y);   // flatten & structure
208In \CFA, each of these calls is valid.
209In the call to @f@, @x@ is implicitly flattened so that the components of @x@ are passed as the two arguments to @f@.
210For the call to @g@, the values @y@ and @10@ are structured into a single argument of type @[int, int]@ to match the type of the parameter of @g@.
211Finally, in the call to @h@, @x@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component of @x@ and @y@ are structured into the second argument of type @[int, int]@.
212The 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.
214In \KWC \cite{Buhr94a,Till89}, a precursor to \CFA, there were 4 tuple coercions: opening, closing, flattening, and structuring.
215Opening coerces a tuple value into a tuple of values, while closing converts a tuple of values into a single tuple value.
216Flattening 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.
217Structuring moves in the opposite direction, \ie it takes a flat tuple value and provides structure by introducing nested tuple components.
219In \CFA, the design has been simplified to require only the two conversions previously described, which trigger only in function call and return situations.
220Specifically, the expression resolution algorithm examines all of the possible alternatives for an expression to determine the best match.
221In resolving a function call expression, each combination of function value and list of argument alternatives is examined.
222Given a particular argument list and function value, the list of argument alternatives is flattened to produce a list of non-tuple valued expressions.
223Then the flattened list of expressions is compared with each value in the function's parameter list.
224If the parameter's type is not a tuple type, then the current argument value is unified with the parameter type, and on success the next argument and parameter are examined.
225If the parameter's type is a tuple type, then the structuring conversion takes effect, recursively applying the parameter matching algorithm using the tuple's component types as the parameter list types.
226Assuming a successful unification, eventually the algorithm gets to the end of the tuple type, which causes all of the matching expressions to be consumed and structured into a tuple expression.
227For example, in
229int f(int, [double, int]);
230f([5, 10.2], 4);
232There is only a single definition of @f@, and 3 arguments with only single interpretations.
233First, the argument alternative list @[5, 10.2], 4@ is flattened to produce the argument list @5, 10.2, 4@.
234Next, the parameter matching algorithm begins, with $P = $@int@ and $A = $@int@, which unifies exactly.
235Moving to the next parameter and argument, $P = $@[double, int]@ and $A = $@double@.
236This time, the parameter is a tuple type, so the algorithm applies recursively with $P' = $@double@ and $A = $@double@, which unifies exactly.
237Then $P' = $@int@ and $A = $@double@, which again unifies exactly.
238At this point, the end of $P'$ has been reached, so the arguments @10.2, 4@ are structured into the tuple expression @[10.2, 4]@.
239Finally, the end of the parameter list $P$ has also been reached, so the final expression is @f(5, [10.2, 4])@.
241\section{Tuple Assignment}
243An assignment where the left side of the assignment operator has a tuple type is called tuple assignment.
244There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \emph{Multiple} and \emph{Mass} Assignment, respectively.
246int x;
247double y;
248[int, double] z;
249[y, x] = 3.14;  // mass assignment
250[x, y] = z;     // multiple assignment
251z = 10;         // mass assignment
252z = [x, y];     // multiple assignment
254Let $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.
256For 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$.
257That is, @?=?(&$L_i$, $R_i$)@ must be a well-typed expression.
258In 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.
260A mass assignment assigns the value $R$ to each $L_i$.
261For a mass assignment to be valid, @?=?(&$L_i$, $R$)@ must be a well-typed expression.
262These semantics differ from C cascading assignment (\eg @a=b=c@) in that conversions are applied to $R$ in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment.
263For example, @[y, x] = 3.14@ performs the assignments @y = 3.14@ and @x = 3.14@, which results in the value @3.14@ in @y@ and the value @3@ in @x@.
264On the other hand, the C cascading assignment @y = x = 3.14@ performs the assignments @x = 3.14@ and @y = x@, which results in the value @3@ in @x@, and as a result the value @3@ in @y@ as well.
266Both 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.
267As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function,
269int x = 10, y = 20;
270[x, y] = [y, x];
272After executing this code, @x@ has the value @20@ and @y@ has the value @10@.
274In \CFA, tuple assignment is an expression where the result type is the type of the left side of the assignment, as in normal assignment.
275That is, a tuple assignment produces the value of the left-hand side after assignment.
276These semantics allow cascading tuple assignment to work out naturally in any context where a tuple is permitted.
277These 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.
278Restricting tuple assignment to statements was an attempt to to fix what was seen as a problem with side-effects, wherein assignment can be used in many different locations, such as in function-call argument position.
279While 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.
280Furthermore, 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.
281In another language, tuple assignment as a statement could be reasonable, but it would be inconsistent for tuple assignment to be the only kind of assignment that is not an expression.
282In addition, \KWC permits the compiler to optimize tuple assignment as a block copy, since it does not support user-defined assignment operators.
283This optimization could be implemented in \CFA, but it requires the compiler to verify that the selected assignment operator is trivial.
285The following example shows multiple, mass, and cascading assignment used in one expression
287  int a, b;
288  double c, d;
289  [void] f([int, int]);
290  f([c, a] = [b, d] = 1.5);  // assignments in parameter list
292The tuple expression begins with a mass assignment of @1.5@ into @[b, d]@, which assigns @1.5@ into @b@, which is truncated to @1@, and @1.5@ into @d@, producing the tuple @[1, 1.5]@ as a result.
293That tuple is used as the right side of the multiple assignment (\ie, @[c, a] = [1, 1.5]@) that assigns @1@ into @c@ and @1.5@ into @a@, which is truncated to @1@, producing the result @[1, 1]@.
294Finally, the tuple @[1, 1]@ is used as an expression in the call to @f@.
296\subsection{Tuple Construction}
297Tuple 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.
299struct S;
300void ?{}(S *);         // (1)
301void ?{}(S *, int);    // (2)
302void ?{}(S * double);  // (3)
303void ?{}(S *, S);      // (4)
305[S, S] x = [3, 6.28];  // uses (2), (3), specialized constructors
306[S, S] y;              // uses (1), (1), default constructor
307[S, S] z = x.0;        // uses (4), (4), copy constructor
309In 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)@.
310@z@ is initialized by mass copy constructor calls @?{}(&z.0, x.0)@ and @?{}(&z.1, x.0)@.
311Finally, @x@, @y@, and @z@ are destructed, \ie the calls @^?{}(&x.0)@, @^?{}(&x.1)@, @^?{}(&y.0)@, @^?{}(&y.1)@, @^?{}(&z.0)@, and @^?{}(&z.1)@.
313It is possible to define constructors and assignment functions for tuple types that provide new semantics, if the existing semantics do not fit the needs of an application.
314For example, the function @void ?{}([T, U] *, S);@ can be defined to allow a tuple variable to be constructed from a value of type @S@.
316struct S { int x; double y; };
317void ?{}([int, double] * this, S s) {
318  this->0 = s.x;
319  this->1 = s.y;
322Due to the structure of generated constructors, it is possible to pass a tuple to a generated constructor for a type with a member prefix that matches the type of the tuple.
323For example,
325struct S { int x; double y; int z };
326[int, double] t;
327S s = t;
329The initialization of @s@ with @t@ works by default because @t@ is flattened into its components, which satisfies the generated field constructor @?{}(S *, int, double)@ to initialize the first two values.
331\section{Member-Access Tuple Expression}
333It is possible to access multiple fields from a single expression using a \emph{Member-Access Tuple Expression}.
334The result is a single tuple-valued expression whose type is the tuple of the types of the members.
335For example,
337struct S { int x; double y; char * z; } s;
338s.[x, y, z];
340Here, the type of @s.[x, y, z]@ is @[int, double, char *]@.
341A member tuple expression has the form @a.[x, y, z];@ where @a@ is an expression with type @T@, where @T@ supports member access expressions, and @x, y, z@ are all members of @T@ with types @T$_x$@, @T$_y$@, and @T$_z$@ respectively.
342Then the type of @a.[x, y, z]@ is @[T_x, T_y, T_z]@.
344Since tuple index expressions are a form of member-access expression, it is possible to use tuple-index expressions in conjunction with member tuple expressions to manually restructure a tuple (\eg, rearrange components, drop components, duplicate components, etc.).
346[int, int, long, double] x;
347void f(double, long);
349f(x.[0, 3]);          // f(x.0, x.3)
350x.[0, 1] = x.[1, 0];  // [x.0, x.1] = [x.1, x.0]
351[long, int, long] y = x.[2, 0, 2];
354It is possible for a member tuple expression to contain other member access expressions.
355For example,
357struct A { double i; int j; };
358struct B { int * k; short l; };
359struct C { int x; A y; B z; } v;
360v.[x, y.[i, j], z.k];
362This expression is equivalent to @[v.x, [v.y.i, v.y.j], v.z.k]@.
363That is, the aggregate expression is effectively distributed across the tuple, which allows simple and easy access to multiple components in an aggregate, without repetition.
364It is guaranteed that the aggregate expression to the left of the @.@ in a member tuple expression is evaluated exactly once.
365As such, it is safe to use member tuple expressions on the result of a side-effecting function.
367[int, float, double] f();
368[double, float] x = f().[2, 1];
371In \KWC, member tuple expressions are known as \emph{record field tuples} \cite{Till89}.
372Since \CFA permits these tuple-access expressions using structures, unions, and tuples, \emph{member tuple expression} or \emph{field tuple expression} is more appropriate.
374It is possible to extend member-access expressions further.
375Currently, a member-access expression whose member is a name requires that the aggregate is a structure or union, while a constant integer member requires the aggregate to be a tuple.
376In the interest of orthogonal design, \CFA could apply some meaning to the remaining combinations as well.
377For example,
379struct S { int x, y; } s;
380[S, S] z;
382s.x;  // access member
383z.0;  // access component
385s.1;  // ???
386z.y;  // ???
388One possibility is for @s.1@ to select the second member of @s@.
389Under this interpretation, it becomes possible to not only access members of a struct by name, but also by position.
390Likewise, it seems natural to open this mechanism to enumerations as well, wherein the left side would be a type, rather than an expression.
391One benefit of this interpretation is familiarity, since it is extremely reminiscent of tuple-index expressions.
392On 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.
393This 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.
395As for @z.y@, one interpretation is to extend the meaning of member tuple expressions.
396That is, currently the tuple must occur as the member, \ie to the right of the dot.
397Allowing 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.
398In this example, @z.y@ expands to @[z.0.y, z.1.y]@, allowing what is effectively a very limited compile-time field-sections map operation, where the argument must be a tuple containing only aggregates having a member named @y@.
399It is questionable how useful this would actually be in practice, since structures often do not have names in common with other structures, and further this could cause maintainability issues in that it encourages programmers to adopt very simple naming conventions to maximize the amount of overlap between different types.
400Perhaps more useful would be to allow arrays on the left side of the dot, which would likewise allow mapping a field access across the entire array, producing an array of the contained fields.
401The immediate problem with this idea is that C arrays do not carry around their size, which would make it impossible to use this extension for anything other than a simple stack allocated array.
403Supposing this feature works as described, it would be necessary to specify an ordering for the expansion of member-access expressions versus member-tuple expressions.
405struct { int x, y; };
406[S, S] z;
407z.[x, y];  // ???
408// => [z.0, z.1].[x, y]
409// => [z.0.x, z.0.y, z.1.x, z.1.y]
410// or
411// => [z.x, z.y]
412// => [[z.0, z.1].x, [z.0, z.1].y]
413// => [z.0.x, z.1.x, z.0.y, z.1.y]
415Depending on exactly how the two tuples are combined, different results can be achieved.
416As such, a specific ordering would need to be imposed to make this feature useful.
417Furthermore, this addition moves a member-tuple expression's meaning from being clear statically to needing resolver support, since the member name needs to be distributed appropriately over each member of the tuple, which could itself be a tuple.
419A second possibility is for \CFA to have named tuples, as they exist in Swift and D.
421typedef [int x, int y] Point2D;
422Point2D p1, p2;
423p1.x + p1.y + p2.x + p2.y;
424p1.0 + p1.1 + p2.0 + p2.1;  // equivalent
426In this simpler interpretation, a tuple type carries with it a list of possibly empty identifiers.
427This approach fits naturally with the named return-value feature, and would likely go a long way towards implementing it.
429Ultimately, the first two extensions introduce complexity into the model, with relatively little perceived benefit, and so were dropped from consideration.
430Named tuples are a potentially useful addition to the language, provided they can be parsed with a reasonable syntax.
434In C, the cast operator is used to explicitly convert between types.
435In \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.
436That 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.
438int f();     // (1)
439double f();  // (2)
441f();       // ambiguous - (1),(2) both equally viable
442(int)f();  // choose (2)
444Since casting is a fundamental operation in \CFA, casts need to be given a meaningful interpretation in the context of tuples.
445Taking a look at standard C provides some guidance with respect to the way casts should work with tuples.
447int f();
448void g();
450(void)f();  // valid, ignore results
451(int)g();   // invalid, void cannot be converted to int
453struct A { int x; };
454(struct A)f();  // invalid, int cannot be converted to A
456In C, line 4 is a valid cast, which calls @f@ and discards its result.
457On the other hand, line 5 is invalid, because @g@ does not produce a result, so requesting an @int@ to materialize from nothing is nonsensical.
458Finally, line 8 is also invalid, because in C casts only provide conversion between scalar types \cite[p.~91]{C11}.
459For consistency, this implies that any case wherein the number of components increases as a result of the cast is invalid, while casts that have the same or fewer number of components may be valid.
461Formally, a cast to tuple type is valid when $T_n \leq S_m$, where $T_n$ is the number of components in the target type and $S_m$ is the number of components in the source type, and for each $i$ in $[0, n)$, $S_i$ can be cast to $T_i$.
462Excess elements ($S_j$ for all $j$ in $[n, m)$) are evaluated, but their values are discarded so that they are not included in the result expression.
463This discarding naturally follows the way that a cast to void works in C.
465For example,
467  [int, int, int] f();
468  [int, [int, int], int] g();
470  ([int, double])f();           // (1) valid
471  ([int, int, int])g();         // (2) valid
472  ([void, [int, int]])g();      // (3) valid
473  ([int, int, int, int])g();    // (4) invalid
474  ([int, [int, int, int]])g();  // (5) invalid
477(1) discards the last element of the return value and converts the second element to type double.
478Since @int@ is effectively a 1-element tuple, (2) discards the second component of the second element of the return value of @g@.
479If @g@ is free of side effects, this is equivalent to @[(int)(g().0), (int)(g().1.0), (int)(g().2)]@.
480Since @void@ is effectively a 0-element tuple, (3) discards the first and third return values, which is effectively equivalent to @[(int)(g().1.0), (int)(g().1.1)]@).
481% will this always hold true? probably, as constructors should give all of the conversion power we need. if casts become function calls, what would they look like? would need a way to specify the target type, which seems awkward. Also, C++ basically only has this because classes are closed to extension, while we don't have that problem (can have floating constructors for any type).
482Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions.
483As such, (4) is invalid because the cast target type contains 4 components, while the source type contains only 3.
484Similarly, (5) is invalid because the cast @([int, int, int])(g().1)@ is invalid.
485That is, it is invalid to cast @[int, int]@ to @[int, int, int]@.
488Due to the implicit flattening and structuring conversions involved in argument passing, @otype@ and @dtype@ parameters are restricted to matching only with non-tuple types.
490forall(otype T, dtype U)
491void f(T x, U * y);
493f([5, "hello"]);
495In this example, @[5, "hello"]@ is flattened, so that the argument list appears as @5, "hello"@.
496The argument matching algorithm binds @T@ to @int@ and @U@ to @const char@, and calls the function as normal.
498Tuples can contain otype and dtype components.
499For example, a plus operator can be written to add two triples of a type together.
501forall(otype T | { T ?+?(T, T); })
502[T, T, T] ?+?([T, T, T] x, [T, T, T] y) {
503  return [x.0+y.0, x.1+y.1, x.2+y.2];
505[int, int, int] x;
506int i1, i2, i3;
507[i1, i2, i3] = x + ([10, 20, 30]);
509Note that due to the implicit tuple conversions, this function is not restricted to the addition of two triples.
510A 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@.
511For example, these expressions also succeed and produce the same value.
513([x.0, x.1]) + ([x.2, 10, 20, 30]);  // x + ([10, 20, 30])
514x.0 + ([x.1, x.2, 10, 20, 30]);      // x + ([10, 20, 30])
516This presents a potential problem if structure is important, as these three expressions look like they should have different meanings.
517Furthermore, these calls can be made ambiguous by introducing seemingly different functions.
519forall(otype T | { T ?+?(T, T); })
520[T, T, T] ?+?([T, T] x, [T, T, T, T]);
521forall(otype T | { T ?+?(T, T); })
522[T, T, T] ?+?(T x, [T, T, T, T, T]);
524It 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.
525Still, these semantics are a deficiency of the current argument matching algorithm, and depending on the function, differing return values may not always be appropriate.
526These issues could be rectified by applying an appropriate cost to the structuring and flattening conversions, which are currently 0-cost conversions.
527Care would be needed in this case to ensure that exact matches do not incur such a cost.
529void f([int, int], int, int);
531f([0, 0], 0, 0);    // no cost
532f(0, 0, 0, 0);      // cost for structuring
533f([0, 0,], [0, 0]); // cost for flattening
534f([0, 0, 0], 0);    // cost for flattening and structuring
537Until this point, it has been assumed that assertion arguments must match the parameter type exactly, modulo polymorphic specialization (\ie, no implicit conversions are applied to assertion arguments).
538This decision presents a conflict with the flexibility of tuples.
539\subsection{Assertion Inference}
541int f([int, double], double);
542forall(otype T, otype U | { T f(T, U, U); })
543void g(T, U);
544g(5, 10.21);
546If assertion arguments must match exactly, then the call to @g@ cannot be resolved, since the expected type of @f@ is flat, while the only @f@ in scope requires a tuple type.
547Since tuples are fluid, this requirement reduces the usability of tuples in polymorphic code.
548To ease this pain point, function parameter and return lists are flattened for the purposes of type unification, which allows the previous example to pass expression resolution.
550This relaxation is made possible by extending the existing thunk generation scheme, as described by Bilson \cite{Bilson03}.
551Now, whenever a candidate's parameter structure does not exactly match the formal parameter's structure, a thunk is generated to specialize calls to the actual function.
553int _thunk(int _p0, double _p1, double _p2) {
554  return f([_p0, _p1], _p2);
557Essentially, this provides flattening and structuring conversions to inferred functions, improving the compatibility of tuples and polymorphism.
560Tuples are implemented in the \CFA translator via a transformation into generic types.
561The first time an $N$-tuple is seen for each $N$ in a scope, a generic type with $N$ type parameters is generated.
562For example,
564[int, int] f() {
565  [double, double] x;
566  [int, double, int] y;
569is transformed into
571forall(dtype T0, dtype T1 | sized(T0) | sized(T1))
572struct _tuple2_ {  // generated before the first 2-tuple
573  T0 field_0;
574  T1 field_1;
576_tuple2_(int, int) f() {
577  _tuple2_(double, double) x;
578  forall(dtype T0, dtype T1, dtype T2 | sized(T0) | sized(T1) | sized(T2))
579  struct _tuple3_ {  // generated before the first 3-tuple
580    T0 field_0;
581    T1 field_1;
582    T2 field_2;
583  };
584  _tuple3_(int, double, int) y;
588Tuple expressions are then simply converted directly into compound literals
590[5, 'x', 1.24];
594(_tuple3_(int, char, double)){ 5, 'x', 1.24 };
597Since tuples are essentially structures, tuple indexing expressions are just field accesses.
599void f(int, [double, char]);
600[int, double] x;
603printf("%d %g\n", x);
604f(x, 'z');
606is transformed into
608void f(int, _tuple2_(double, char));
609_tuple2_(int, double) x;
612printf("%d %g\n", x.field_0, x.field_1);
613f(x.field_0, (_tuple2){ x.field_1, 'z' });
615Note that due to flattening, @x@ used in the argument position is converted into the list of its fields.
616In the call to @f@, the second and third argument components are structured into a tuple argument.
618Expressions that may contain side effects are made into \emph{unique expressions} before being expanded by the flattening conversion.
619Each unique expression is assigned an identifier and is guaranteed to be executed exactly once.
621void g(int, double);
622[int, double] h();
625Internally, this is converted to pseudo-\CFA
627void g(int, double);
628[int, double] h();
629lazy [int, double] unq0 = h(); // deferred execution
630g(unq0.0, unq0.1);             // execute h() once
632That is, the function @h@ is evaluated lazily and its result is stored for subsequent accesses.
633Ultimately, unique expressions are converted into two variables and an expression.
635void g(int, double);
636[int, double] h();
638_Bool _unq0_finished_ = 0;
639[int, double] _unq0;
641  (_unq0_finished_ ? _unq0 : (_unq0 = h(), _unq0_finished_ = 1, _unq0)).0,
642  (_unq0_finished_ ? _unq0 : (_unq0 = h(), _unq0_finished_ = 1, _unq0)).1,
645Since argument evaluation order is not specified by the C programming language, this scheme is built to work regardless of evaluation order.
646The first time a unique expression is executed, the actual expression is evaluated and the accompanying boolean is set to true.
647Every subsequent evaluation of the unique expression then results in an access to the stored result of the actual expression.
649Currently, the \CFA translator has a very broad, imprecise definition of impurity (side-effects), where every function call is assumed to be impure.
650This 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.
651It is possible that lazy evaluation could be exposed to the user through a lazy keyword with little additional effort.
653Tuple-member expressions are recursively expanded into a list of member-access expressions.
655[int, [double, int, double], int]] x;
656x.[0, 1.[0, 2]];
660[x.0, [x.1.0, x.1.2]];
662Tuple-member expressions also take advantage of unique expressions in the case of possible impurity.
664Finally, the various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions.
665For example, a mass assignment
667int x, z;
668double y;
669[double, double] f();
671[x, y, z] = 1.5;            // mass assignment
673generates the following
675// [x, y, z] = 1.5;
676_tuple3_(int, double, int) _tmp_stmtexpr_ret0;
677({ // GNU C statement expression
678  // assign LHS address temporaries
679  int *__massassign_L0 = &x;    // ?{}
680  double *__massassign_L1 = &y; // ?{}
681  int *__massassign_L2 = &z;    // ?{}
683  // assign RHS value temporary
684  double __massassign_R0 = 1.5; // ?{}
686  ({ // tuple construction - construct statement expr return variable
687    // assign LHS address temporaries
688    int *__multassign_L0 = (int *)&_tmp_stmtexpr_ret0.0;       // ?{}
689    double *__multassign_L1 = (double *)&_tmp_stmtexpr_ret0.1; // ?{}
690    int *__multassign_L2 = (int *)&_tmp_stmtexpr_ret0.2;       // ?{}
692    // assign RHS value temporaries and mass-assign to L0, L1, L2
693    int __multassign_R0 = (*__massassign_L0=(int)__massassign_R0); // ?{}
694    double __multassign_R1 = (*__massassign_L1=__massassign_R0);   // ?{}
695    int __multassign_R2 = (*__massassign_L2=(int)__massassign_R0); // ?{}
697    // perform construction of statement expr return variable using
698    // RHS value temporary
699    ((*__multassign_L0 = __multassign_R0 /* ?{} */),
700     (*__multassign_L1 = __multassign_R1 /* ?{} */),
701     (*__multassign_L2 = __multassign_R2 /* ?{} */));
702  });
703  _tmp_stmtexpr_ret0;
705({ // tuple destruction - destruct assign expr value
706  int *__massassign_L3 = (int *)&_tmp_stmtexpr_ret0.0;       // ?{}
707  double *__massassign_L4 = (double *)&_tmp_stmtexpr_ret0.1; // ?{}
708  int *__massassign_L5 = (int *)&_tmp_stmtexpr_ret0.2;       // ?{}
709  ((*__massassign_L3 /* ^?{} */),
710   (*__massassign_L4 /* ^?{} */),
711   (*__massassign_L5 /* ^?{} */));
714A variable is generated to store the value produced by a statement expression, since its fields may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg, in a unique expression.
715$N$ LHS variables are generated and constructed using the address of the tuple components, and a single RHS variable is generated to store the value of the RHS without any loss of precision.
716A nested statement expression is generated that performs the individual assignments and constructs the return value using the results of the individual assignments.
717Finally, the statement expression temporary is destroyed at the end of the expression.
719Similarly, a multiple assignment
721[x, y, z] = [f(), 3];       // multiple assignment
723generates the following
725// [x, y, z] = [f(), 3];
726_tuple3_(int, double, int) _tmp_stmtexpr_ret0;
728  // assign LHS address temporaries
729  int *__multassign_L0 = &x;    // ?{}
730  double *__multassign_L1 = &y; // ?{}
731  int *__multassign_L2 = &z;    // ?{}
733  // assign RHS value temporaries
734  _tuple2_(double, double) _tmp_cp_ret0;
735  _Bool _unq0_finished_ = 0;
736  double __multassign_R0 =
737    (_unq0_finished_ ?
738      _tmp_cp_ret0 :
739      (_tmp_cp_ret0=f(), _unq0_finished_=1, _tmp_cp_ret0)).0; // ?{}
740  double __multassign_R1 =
741    (_unq0_finished_ ?
742      _tmp_cp_ret0 :
743      (_tmp_cp_ret0=f(), _unq0_finished_=1, _tmp_cp_ret0)).1; // ?{}
744  ({ // tuple destruction - destruct f() return temporary
745    // assign LHS address temporaries
746    double *__massassign_L3 = (double *)&_tmp_cp_ret0.0;  // ?{}
747    double *__massassign_L4 = (double *)&_tmp_cp_ret0.1;  // ?{}
748    // perform destructions - intrinsic, so NOP
749    ((*__massassign_L3 /* ^?{} */),
750     (*__massassign_L4 /* ^?{} */));
751  });
752  int __multassign_R2 = 3; // ?{}
754  ({ // tuple construction - construct statement expr return variable
755    // assign LHS address temporaries
756    int *__multassign_L3 = (int *)&_tmp_stmtexpr_ret0.0;       // ?{}
757    double *__multassign_L4 = (double *)&_tmp_stmtexpr_ret0.1; // ?{}
758    int *__multassign_L5 = (int *)&_tmp_stmtexpr_ret0.2;       // ?{}
760    // assign RHS value temporaries and multiple-assign to L0, L1, L2
761    int __multassign_R3 = (*__multassign_L0=(int)__multassign_R0);  // ?{}
762    double __multassign_R4 = (*__multassign_L1=__multassign_R1);    // ?{}
763    int __multassign_R5 = (*__multassign_L2=__multassign_R2);       // ?{}
765    // perform construction of statement expr return variable using
766    // RHS value temporaries
767    ((*__multassign_L3=__multassign_R3 /* ?{} */),
768     (*__multassign_L4=__multassign_R4 /* ?{} */),
769     (*__multassign_L5=__multassign_R5 /* ?{} */));
770  });
771  _tmp_stmtexpr_ret0;
773({  // tuple destruction - destruct assign expr value
774  // assign LHS address temporaries
775  int *__massassign_L5 = (int *)&_tmp_stmtexpr_ret0.0;       // ?{}
776  double *__massassign_L6 = (double *)&_tmp_stmtexpr_ret0.1; // ?{}
777  int *__massassign_L7 = (int *)&_tmp_stmtexpr_ret0.2;       // ?{}
778  // perform destructions - intrinsic, so NOP
779  ((*__massassign_L5 /* ^?{} */),
780   (*__massassign_L6 /* ^?{} */),
781   (*__massassign_L7 /* ^?{} */));
784The difference here is that $N$ RHS values are stored into separate temporary variables.
786The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language.
787There are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this is not a new restriction.
Note: See TracBrowser for help on using the repository browser.