- Timestamp:
- Nov 27, 2017, 9:56:47 PM (7 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 481115f
- Parents:
- c029f4d
- git-author:
- Peter A. Buhr <pabuhr@…> (11/27/17 21:54:35)
- git-committer:
- Peter A. Buhr <pabuhr@…> (11/27/17 21:56:47)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/user/user.tex
rc029f4d rc8771e9 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Sun Aug 6 10:24:21201714 %% Update Count : 3 03613 %% Last Modified On : Mon Nov 27 18:09:59 2017 14 %% Update Count : 3143 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 59 59 \CFAStyle % use default CFA format-style 60 60 \lstnewenvironment{C++}[1][] % use C++ style 61 {\lstset{language=C++,moredelim=**[is][\protect\color{red}]{®}{®} #1}}61 {\lstset{language=C++,moredelim=**[is][\protect\color{red}]{®}{®},#1}} 62 62 {} 63 63 … … 777 777 case 7: 778 778 ... 779 ®break® §\C{// redundant explicit end of switch}§779 ®break® §\C{// explicit end of switch (redundant)}§ 780 780 default: 781 781 j = 3; … … 806 806 ®int k = 0;® §\C{// allowed at different nesting levels}§ 807 807 ... 808 ®case 2:® §\C{// disallow case in nested statements}§ 808 809 } 809 810 ... … … 962 963 \end{cfa} 963 964 965 The components in the "with" clause 966 967 with a, b, c { ... } 968 969 serve 2 purposes: each component provides a type and object. The type must be a 970 structure type. Enumerations are already opened, and I think a union is opened 971 to some extent, too. (Or is that just unnamed unions?) The object is the target 972 that the naked structure-fields apply to. The components are open in "parallel" 973 at the scope of the "with" clause/statement, so opening "a" does not affect 974 opening "b", etc. This semantic is different from Pascal, which nests the 975 openings. 976 977 Having said the above, it seems reasonable to allow a "with" component to be an 978 expression. The type is the static expression-type and the object is the result 979 of the expression. Again, the type must be an aggregate. Expressions require 980 parenthesis around the components. 981 982 with( a, b, c ) { ... } 983 984 Does this now make sense? 985 986 Having written more CFA code, it is becoming clear to me that I *really* want 987 the "with" to be implemented because I hate having to type all those object 988 names for fields. It's a great way to drive people away from the language. 989 964 990 965 991 \section{Exception Handling} … … 977 1003 try { 978 1004 f(...); 979 } catch( E e :§boolean-predicate§ ) { §\C[8cm]{// termination handler}§1005 } catch( E e ; §boolean-predicate§ ) { §\C[8cm]{// termination handler}§ 980 1006 // recover and continue 981 } catchResume( E e :§boolean-predicate§ ) { §\C{// resumption handler}\CRT§1007 } catchResume( E e ; §boolean-predicate§ ) { §\C{// resumption handler}\CRT§ 982 1008 // repair and return 983 1009 } finally { … … 1872 1898 \end{cfa} 1873 1899 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa). 1874 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg: 1875 \begin{quote2} 1876 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1877 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 1878 \begin{cfa} 1879 [ int ] f( int ), g; 1880 \end{cfa} 1881 & 1882 \begin{cfa} 1883 int f( int ), g( int ); 1884 \end{cfa} 1885 \end{tabular} 1886 \end{quote2} 1900 Like C, it is possible to declare multiple routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg: 1901 \begin{cfa} 1902 C : const double bar1(), bar2( int ), bar3( double ); 1903 §\CFA§: [const double] foo(), foo( int ), foo( double ) { return 3.0; } 1904 \end{cfa} 1905 \CFA allows the last routine in the list to define its body. 1906 1887 1907 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg: 1888 1908 \begin{cfa} … … 2235 2255 \label{s:MRV_Functions} 2236 2256 2237 In standard C, functions can return at most one value. 2257 In C and most programming languages, functions return at most one value; 2258 however, many operations have multiple outcomes, some exceptional (see~\VRef{s:ExceptionHandling}). 2238 2259 To emulate functions with multiple return values, \emph{\Index{aggregation}} and/or \emph{\Index{aliasing}} is used. 2239 In the former situation, the function designer creates a record type that combines all of the return values into a single type. 2240 For example, consider a function returning the most frequently occurring letter in a string, and its frequency. 2241 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. 2242 \begin{cfa} 2243 struct mf_ret { 2244 int freq; 2245 char ch; 2246 }; 2247 2248 struct mf_ret most_frequent(const char * str) { 2249 char freqs [26] = { 0 }; 2250 struct mf_ret ret = { 0, 'a' }; 2251 for (int i = 0; str[i] != '\0'; ++i) { 2252 if (isalpha(str[i])) { // only count letters 2253 int ch = tolower(str[i]); // convert to lower case 2254 int idx = ch-'a'; 2255 if (++freqs[idx] > ret.freq) { // update on new max 2256 ret.freq = freqs[idx]; 2257 ret.ch = ch; 2258 } 2259 } 2260 } 2261 return ret; 2262 } 2263 2264 const char * str = "hello world"; 2265 struct mf_ret ret = most_frequent(str); 2266 printf("%s -- %d %c\n", str, ret.freq, ret.ch); 2267 \end{cfa} 2268 Of note, the designer must come up with a name for the return type and for each of its fields. 2269 Unnecessary naming is a common programming language issue, introducing verbosity and a complication of the user's mental model. 2270 That 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. 2271 As 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. 2272 2273 In the latter approach, the designer simulates multiple return values by passing the additional return values as pointer parameters. 2274 The pointer parameters are assigned inside of the routine body to emulate a return. 2275 Using the same example, 2276 \begin{cfa} 2277 int most_frequent(const char * str, char * ret_ch) { 2278 char freqs [26] = { 0 }; 2279 int ret_freq = 0; 2280 for (int i = 0; str[i] != '\0'; ++i) { 2281 if (isalpha(str[i])) { // only count letters 2282 int ch = tolower(str[i]); // convert to lower case 2283 int idx = ch-'a'; 2284 if (++freqs[idx] > ret_freq) { // update on new max 2285 ret_freq = freqs[idx]; 2286 *ret_ch = ch; // assign to out parameter 2287 } 2288 } 2289 } 2290 return ret_freq; // only one value returned directly 2291 } 2292 2293 const char * str = "hello world"; 2294 char ch; // pre-allocate return value 2295 int freq = most_frequent(str, &ch); // pass return value as out parameter 2296 printf("%s -- %d %c\n", str, freq, ch); 2297 \end{cfa} 2298 Notably, 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. 2299 Also, 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. 2300 Furthermore, 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. 2301 On 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. 2302 Interestingly, 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. 2303 In 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. 2260 2261 In the former approach, a record type is created combining all of the return values. 2262 For example, consider C's \Indexc{div} function, which returns the quotient and remainder for a division of an integer value. 2263 \begin{cfa} 2264 typedef struct { int quot, rem; } div_t; §\C[7cm]{// from include stdlib.h}§ 2265 div_t div( int num, int den ); 2266 div_t qr = div( 13, 5 ); §\C{// return quotient/remainder aggregate}§ 2267 printf( "%d %d\n", qr.quot, qr.rem ); §\C{// print quotient/remainder}§ 2268 \end{cfa} 2269 This approach requires a name for the return type and fields, where \Index{naming} is a common programming-language issue. 2270 That is, naming creates an association that must be managed when reading and writing code. 2271 While effective when used sparingly, this approach does not scale when functions need to return multiple combinations of types. 2272 2273 In the latter approach, additional return values are passed as pointer parameters. 2274 A pointer parameter is assigned inside the routine to emulate a return. 2275 For example, consider C's \Indexc{modf} function, which returns the integral and fractional part of a floating-point value. 2276 \begin{cfa} 2277 double modf( double x, double * i ); §\C{// from include math.h}§ 2278 double intp, frac = modf( 13.5, &intp ); §\C{// return integral and fractional components}§ 2279 printf( "%g %g\n", intp, frac ); §\C{// print integral/fractional components}§ 2280 \end{cfa} 2281 This approach requires allocating storage for the return values, which complicates the call site with a sequence of variable declarations leading to the call. 2282 Also, while a disciplined use of ©const© can give clues about whether a pointer parameter is used as an \Index{out parameter}, it is not obvious from the routine signature whether the callee expects such a parameter to be initialized before the call. 2283 Furthermore, while many C routines that accept pointers are safe for a ©NULL© argument, there are many C routines that are not null-safe. 2284 Finally, C does not provide a 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. 2304 2285 Still, 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. 2305 2286 As with the previous approach, this technique can simulate multiple return values, but in practice it is verbose and error prone. 2306 2287 2307 In \CFA, functions can be declared to return multiple values with an extension tothe function declaration syntax.2288 \CFA allows functions to return multiple values by extending the function declaration syntax. 2308 2289 Multiple 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. 2290 \begin{cfa} 2291 [ char, int, double ] f( ... ); 2292 \end{cfa} 2309 2293 The ability to return multiple values from a function requires a new syntax for the return statement. 2310 2294 For consistency, the return statement in \CFA accepts a comma-separated list of expressions in square brackets. 2311 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. 2295 \begin{cfa} 2296 return [ c, i, d ]; 2297 \end{cfa} 2298 The expression resolution ensures the correct form is used depending on the values being returned and the return type of the current function. 2312 2299 A multiple-returning function with return type ©T© can return any expression that is implicitly convertible to ©T©. 2313 Using the running example, the ©most_frequent© function can be written using multiple return values as such, 2314 \begin{cfa} 2315 [int, char] most_frequent(const char * str) { 2316 char freqs [26] = { 0 }; 2317 int ret_freq = 0; 2318 char ret_ch = 'a'; // arbitrary default value for consistent results 2319 for (int i = 0; str[i] != '\0'; ++i) { 2320 if (isalpha(str[i])) { // only count letters 2321 int ch = tolower(str[i]); // convert to lower case 2322 int idx = ch-'a'; 2323 if (++freqs[idx] > ret_freq) { // update on new max 2324 ret_freq = freqs[idx]; 2325 ret_ch = ch; 2326 } 2327 } 2328 } 2329 return [ret_freq, ret_ch]; 2330 } 2331 \end{cfa} 2332 This 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. 2333 2334 The addition of multiple-return-value functions necessitates a syntax for accepting multiple values at the call-site. 2300 2301 A common use of a function's output is input to another function. 2302 \CFA allows this case, without any new syntax; 2303 a multiple-returning function can be used in any of the contexts where an expression is allowed. 2304 When a function call is passed as an argument to another call, the best match of actual arguments to formal parameters is evaluated given all possible expression interpretations in the current scope. 2305 \begin{cfa} 2306 void g( int, int ); §\C{// 1}§ 2307 void g( double, double ); §\C{// 2}§ 2308 g( div( 13, 5 ) ); §\C{// select 1}§ 2309 g( modf( 13.5 ) ); §\C{// select 2}§ 2310 \end{cfa} 2311 In this case, there are two overloaded ©g© routines. 2312 Both calls to ©g© expect two arguments that are matched by the two return values from ©div© and ©modf©. respectively, which are fed directly to the first and second parameters of ©g©. 2313 As well, both calls to ©g© have exact type matches for the two different versions of ©g©, so these exact matches are chosen. 2314 When type matches are not exact, conversions are used to find a best match. 2315 2316 The previous examples can be rewritten passing the multiple returned-values directly to the ©printf© function call. 2317 \begin{cfa} 2318 [ int, int ] div( int x, int y ); §\C{// from include stdlib}§ 2319 printf( "%d %d\n", div( 13, 5 ) ); §\C{// print quotient/remainder}§ 2320 2321 [ double, double ] modf( double x ); §\C{// from include math}§ 2322 printf( "%g %g\n", modf( 13.5 ) ); §\C{// print integral/fractional components}§ 2323 \end{cfa} 2324 This 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. 2325 2326 Finally, the addition of multiple-return-value functions necessitates a syntax for retaining the multiple values at the call-site versus their temporary existence during a call. 2335 2327 The simplest mechanism for retaining a return value in C is variable assignment. 2336 By assigning the return value into a variable, its value can be retrieved later at any point in the program.2328 By assigning the multiple return-values into multiple variables, the values can be retrieved later. 2337 2329 As such, \CFA allows assigning multiple values from a function into multiple variables, using a square-bracketed list of lvalue expressions on the left side. 2338 2330 \begin{cfa} 2339 const char * str = "hello world"; 2340 int freq; 2341 char ch; 2342 [freq, ch] = most_frequent(str); // assign into multiple variables 2343 printf("%s -- %d %c\n", str, freq, ch); 2344 \end{cfa} 2345 It is also common to use a function's output as the input to another function. 2346 \CFA also allows this case, without any new syntax. 2347 When 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}. 2348 For example, 2349 \begin{cfa} 2350 void process(int); // (1) 2351 void process(char); // (2) 2352 void process(int, char); // (3) 2353 void process(char, int); // (4) 2354 2355 process(most_frequent("hello world")); // selects (3) 2356 \end{cfa} 2357 In this case, there is only one option for a function named ©most_frequent© that takes a string as input. 2358 This function returns two values, one ©int© and one ©char©. 2359 There 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. 2360 This 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. 2361 2362 \section{Tuple Expressions} 2331 int quot, rem; 2332 [ quot, rem ] = div( 13, 5 ); §\C{// assign multiple variables}§ 2333 printf( "%d %d\n", quot, rem ); §\C{// print quotient/remainder}\CRT§ 2334 \end{cfa} 2335 Here, the multiple return-values are matched in much the same way as passing multiple return-values to multiple parameters in a call. 2336 2337 2338 \subsection{Expressions} 2339 2363 2340 Multiple-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. 2364 These notions can be generalized to provide \CFA with \emph{tuple expressions} and \emph{tuple types}.2341 These notions are generalized to provide \CFA with \newterm{tuple expression}s and \newterm{tuple type}s. 2365 2342 A tuple expression is an expression producing a fixed-size, ordered list of values of heterogeneous types. 2366 The type of a tuple expression is the tuple of the subexpression types, or a \emph{tuple type}. 2343 The type of a tuple expression is the tuple of the subexpression types, or a tuple type. 2344 2367 2345 In \CFA, a tuple expression is denoted by a comma-separated list of expressions enclosed in square brackets. 2368 2346 For example, the expression ©[5, 'x', 10.5]© has type ©[int, char, double]©. … … 2371 2349 The order of evaluation of the components in a tuple expression is unspecified, to allow a compiler the greatest flexibility for program optimization. 2372 2350 It is, however, guaranteed that each component of a tuple expression is evaluated for side-effects, even if the result is not used. 2373 Multiple-return-value functions can equivalently be called \emph{tuple-returning functions}. 2374 2375 \subsection{Tuple Variables} 2376 The 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. 2377 In \CFA, it is possible to overcome this restriction by declaring a \emph{tuple variable}. 2378 \begin{cfa}[emph=ret, emphstyle=\color{red}] 2379 const char * str = "hello world"; 2380 [int, char] ret = most_frequent(str); // initialize tuple variable 2381 printf("%s -- %d %c\n", str, ret); 2382 \end{cfa} 2383 It 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. 2384 These variables can be used in any of the contexts where a tuple expression is allowed, such as in the ©printf© function call. 2385 As in the ©process© example, the components of the tuple value are passed as separate parameters to ©printf©, allowing very simple printing of tuple expressions. 2386 One way to access the individual components is with a simple assignment, as in previous examples. 2387 \begin{cfa} 2388 int freq; 2389 char ch; 2390 [freq, ch] = ret; 2391 \end{cfa} 2392 2393 \begin{sloppypar} 2351 Multiple-return-value functions can equivalently be called \newterm{tuple-returning functions}. 2352 2353 2354 \subsection{Variables} 2355 2356 The previous call of ©div© still requires the preallocation of multiple return-variables in a manner similar to the aliasing example. 2357 In \CFA, it is possible to overcome this restriction by declaring a \newterm{tuple variable}. 2358 \begin{cfa} 2359 [int, int] ®qr® = div( 13, 5 ); §\C{// initialize tuple variable}§ 2360 printf( "%d %d\n", ®qr® ); §\C{// print quotient/remainder}§ 2361 \end{cfa} 2362 It is now possible to match the multiple return-values to a single variable, in much the same way as \Index{aggregation}. 2363 As well, the components of the tuple value are passed as separate parameters to ©printf©, allowing direct printing of tuple variables. 2364 One way to access the individual components of a tuple variable is with assignment. 2365 \begin{cfa} 2366 [ quot, rem ] = qr; §\C{// assign multiple variables}§ 2367 \end{cfa} 2368 2394 2369 In addition to variables of tuple type, it is also possible to have pointers to tuples, and arrays of tuples. 2395 2370 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. 2396 2371 \begin{cfa} 2397 [ double, int] di;2398 [ double, int] * pdi2399 [ double, int] adi[10];2372 [ double, int ] di; 2373 [ double, int ] * pdi 2374 [ double, int ] adi[10]; 2400 2375 \end{cfa} 2401 2376 This examples declares a variable of type ©[double, int]©, a variable of type pointer to ©[double, int]©, and an array of ten ©[double, int]©. 2402 \end{sloppypar} 2403 2404 \subsection{Tuple Indexing} 2405 2406 At times, it is desirable to access a single component of a tuple-valued expression without creating unnecessary temporary variables to assign to. 2407 Given 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©. 2408 For example, 2377 2378 2379 \subsection{Indexing} 2380 2381 It is also possible to access a single component of a tuple-valued expression without creating temporary variables. 2382 Given a tuple-valued expression $e$np 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^{\:th}$ component of $e$, \eg: 2409 2383 \begin{cfa} 2410 2384 [int, double] x; … … 2417 2391 p->0 = 5; §\C{// access int component of tuple pointed-to by p}§ 2418 2392 g( x.1, x.0 ); §\C{// rearrange x to pass to g}§ 2419 double z = [ x, f()].0.1; §\C{// access second component of first component of tuple expression}§2420 \end{cfa} 2421 As 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.2393 double z = [ x, f() ].0.1; §\C{// access second component of first component of tuple expression}§ 2394 \end{cfa} 2395 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. 2422 2396 This feature was proposed for \KWC but never implemented \cite[p.~45]{Till89}. 2423 2397 2398 2424 2399 \subsection{Flattening and Structuring} 2400 2425 2401 As evident in previous examples, tuples in \CFA do not have a rigid structure. 2426 2402 In function call contexts, tuples support implicit flattening and restructuring conversions. … … 2465 2441 There is only a single definition of ©f©, and 3 arguments with only single interpretations. 2466 2442 First, the argument alternative list ©[5, 10.2], 4© is flattened to produce the argument list ©5, 10.2, 4©. 2467 Next, the parameter matching algorithm begins, with $P = $©int© and $A = $©int©, which unifies exactly.2468 Moving to the next parameter and argument, $P = $©[double, int]© and $A = $©double©.2469 This time, the parameter is a tuple type, so the algorithm applies recursively with $P' = $©double© and $A = $©double©, which unifies exactly.2470 Then $P' = $©int© and $A = $©double©, which again unifies exactly.2443 Next, the parameter matching algorithm begins, with $P =$© int© and $A =$© int©, which unifies exactly. 2444 Moving to the next parameter and argument, $P =$© [double, int]© and $A =$© double©. 2445 This time, the parameter is a tuple type, so the algorithm applies recursively with $P' =$© double© and $A =$© double©, which unifies exactly. 2446 Then $P' =$© int© and $A =$© double©, which again unifies exactly. 2471 2447 At this point, the end of $P'$ has been reached, so the arguments ©10.2, 4© are structured into the tuple expression ©[10.2, 4]©. 2472 2448 Finally, the end of the parameter list $P$ has also been reached, so the final expression is ©f(5, [10.2, 4])©. 2473 2449 2474 \section{Tuple Assignment} 2450 2451 \subsection{Assignment} 2475 2452 \label{s:TupleAssignment} 2476 An assignment where the left side of the assignment operator has a tuple type is called tuple assignment. 2477 There 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. 2453 2454 An assignment where the left side of the assignment operator has a tuple type is called \newterm{tuple assignment}. 2455 There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a non-tuple or tuple type, called \newterm[mass assignment]{mass} and \newterm[multiple assignment]{multiple} assignment, respectively. 2478 2456 \begin{cfa} 2479 2457 int x; 2480 2458 double y; 2481 2459 [int, double] z; 2482 [y, x] = 3.14; // mass assignment2483 [x, y] = z; // multiple assignment2484 z = 10; // mass assignment2485 z = [x, y]; // multiple assignment2460 [y, x] = 3.14; §\C{// mass assignment}§ 2461 [x, y] = z; §\C{// multiple assignment}§ 2462 z = 10; §\C{// mass assignment}§ 2463 z = [x, y]; §\C{// multiple assignment}§ 2486 2464 \end{cfa} 2487 2465 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. … … 2490 2468 For example, the following is invalid because the number of components on the left does not match the number of components on the right. 2491 2469 \begin{cfa} 2492 [ int, int] x, y, z;2493 [ x, y] = z; // multiple assignment, invalid 4 != 22470 [ int, int ] x, y, z; 2471 [ x, y ] = z; §\C{// multiple assignment, invalid 4 != 2}§ 2494 2472 \end{cfa} 2495 2473 Multiple assignment assigns $R_i$ to $L_i$ for each $i$. … … 2507 2485 \begin{cfa} 2508 2486 int x = 10, y = 20; 2509 [ x, y] = [y, x];2487 [ x, y ] = [ y, x ]; 2510 2488 \end{cfa} 2511 2489 After executing this code, ©x© has the value ©20© and ©y© has the value ©10©. … … 2526 2504 int a, b; 2527 2505 double c, d; 2528 [ void] f([int, int]);2529 f( [c, a] = [b, d] = 1.5); // assignments in parameter list2506 [ void ] f( [ int, int ] ); 2507 f( [ c, a ] = [ b, d ] = 1.5 ); // assignments in parameter list 2530 2508 \end{cfa} 2531 2509 The 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. … … 2533 2511 Finally, the tuple ©[1, 1]© is used as an expression in the call to ©f©. 2534 2512 2535 \subsection{Tuple Construction} 2513 2514 \subsection{Construction} 2515 2536 2516 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. 2537 2517 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. … … 2569 2549 The 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. 2570 2550 2571 \section{Member-Access Tuple Expression} 2551 2552 \subsection{Member-Access Expression} 2572 2553 \label{s:MemberAccessTuple} 2573 It is possible to access multiple fields from a single expression using a \emph{Member-Access Tuple Expression}. 2554 2555 Tuples may be used to select multiple fields of a record by field name. 2574 2556 The result is a single tuple-valued expression whose type is the tuple of the types of the members. 2575 2557 For example, 2576 2558 \begin{cfa} 2577 struct S { int x; double y; char *z; } s;2559 struct S { char x; int y; double z; } s; 2578 2560 s.[x, y, z]; 2579 2561 \end{cfa} 2580 Here, the type of ©s.[x, y, z]© is ©[int, double, char *]©. 2581 A 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. 2582 Then the type of ©a.[x, y, z]© is ©[T_x, T_y, T_z]©. 2583 2584 Since 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.). 2585 \begin{cfa} 2586 [int, int, long, double] x; 2587 void f(double, long); 2588 2589 f(x.[0, 3]); // f(x.0, x.3) 2590 x.[0, 1] = x.[1, 0]; // [x.0, x.1] = [x.1, x.0] 2591 [long, int, long] y = x.[2, 0, 2]; 2592 \end{cfa} 2593 2594 It is possible for a member tuple expression to contain other member access expressions. 2595 For example, 2562 Here, the type of ©s.[ x, y, z ]© is ©[ char, int, double ]©. 2563 A member tuple expression has the form \emph{e}©.[x, y, z];© where \emph{e} 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. 2564 Then the type of \emph{e}©.[x, y, z]© is ©[T$_x$, T$_y$, T$_z$]©. 2565 2566 A member-access tuple may be used anywhere a tuple can be used, \eg: 2567 \begin{cfa} 2568 s.[ y, z, x ] = [ 3, 3.2, 'x' ]; §\C{// equivalent to s.x = 'x', s.y = 3, s.z = 3.2}§ 2569 f( s.[ y, z ] ); §\C{// equivalent to f( s.y, s.z )}§ 2570 \end{cfa} 2571 Note, the fields appearing in a record-field tuple may be specified in any order; 2572 also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple. 2573 2574 Since tuple-index expressions are a form of member-access expression, it is possible to use tuple-index expressions in conjunction with member-access expressions to restructure a tuple (\eg, rearrange components, drop components, duplicate components, etc.). 2575 \begin{cfa} 2576 [ int, int, long, double ] x; 2577 void f( double, long ); 2578 2579 f( x.[ 0, 3 ] ); §\C{// f( x.0, x.3 )}§ 2580 x.[ 0, 1 ] = x.[ 1, 0 ]; §\C{// [ x.0, x.1 ] = [ x.1, x.0 ]}§ 2581 [ long, int, long ] y = x.[ 2, 0, 2 ]; 2582 \end{cfa} 2583 2584 It is possible for a member tuple expression to contain other member access expressions, \eg: 2596 2585 \begin{cfa} 2597 2586 struct A { double i; int j; }; 2598 2587 struct B { int * k; short l; }; 2599 2588 struct C { int x; A y; B z; } v; 2600 v.[ x, y.[i, j], z.k];2601 \end{cfa} 2602 This expression is equivalent to ©[ v.x, [v.y.i, v.y.j], v.z.k]©.2603 That is, the aggregate expression is effectively distributed across the tuple , which allows simple and easy access to multiple components in an aggregate,without repetition.2589 v.[ x, y.[ i, j ], z.k ]; 2590 \end{cfa} 2591 This expression is equivalent to ©[ v.x, [ v.y.i, v.y.j ], v.z.k ]©. 2592 That is, the aggregate expression is effectively distributed across the tuple allowing simple and easy access to multiple components in an aggregate without repetition. 2604 2593 It is guaranteed that the aggregate expression to the left of the ©.© in a member tuple expression is evaluated exactly once. 2605 As such, it is safe to use member tuple expressions on the result of a side-effecting function.2606 \begin{cfa} 2607 [ int, float, double] f();2608 [ double, float] x = f().[2, 1];2594 As such, it is safe to use member tuple expressions on the result of a function with side-effects. 2595 \begin{cfa} 2596 [ int, float, double ] f(); 2597 [ double, float ] x = f().[ 2, 1 ]; §\C{// f() called once}§ 2609 2598 \end{cfa} 2610 2599 … … 2612 2601 Since \CFA permits these tuple-access expressions using structures, unions, and tuples, \emph{member tuple expression} or \emph{field tuple expression} is more appropriate. 2613 2602 2614 It is possible to extend member-access expressions further. 2615 Currently, 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. 2616 In the interest of orthogonal design, \CFA could apply some meaning to the remaining combinations as well. 2617 For example, 2618 \begin{cfa} 2619 struct S { int x, y; } s; 2620 [S, S] z; 2621 2622 s.x; // access member 2623 z.0; // access component 2624 2625 s.1; // ??? 2626 z.y; // ??? 2627 \end{cfa} 2628 One possibility is for ©s.1© to select the second member of ©s©. 2629 Under this interpretation, it becomes possible to not only access members of a struct by name, but also by position. 2630 Likewise, it seems natural to open this mechanism to enumerations as well, wherein the left side would be a type, rather than an expression. 2631 One benefit of this interpretation is familiarity, since it is extremely reminiscent of tuple-index expressions. 2632 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. 2633 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. 2634 2635 As for ©z.y©, one interpretation is to extend the meaning of member tuple expressions. 2636 That is, currently the tuple must occur as the member, \ie to the right of the dot. 2637 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. 2638 In 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©. 2639 It 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. 2640 Perhaps 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. 2641 The 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. 2642 2643 Supposing this feature works as described, it would be necessary to specify an ordering for the expansion of member-access expressions versus member-tuple expressions. 2644 \begin{cfa} 2645 struct { int x, y; }; 2646 [S, S] z; 2647 z.[x, y]; // ??? 2648 // => [z.0, z.1].[x, y] 2649 // => [z.0.x, z.0.y, z.1.x, z.1.y] 2650 // or 2651 // => [z.x, z.y] 2652 // => [[z.0, z.1].x, [z.0, z.1].y] 2653 // => [z.0.x, z.1.x, z.0.y, z.1.y] 2654 \end{cfa} 2655 Depending on exactly how the two tuples are combined, different results can be achieved. 2656 As such, a specific ordering would need to be imposed to make this feature useful. 2657 Furthermore, 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. 2658 2659 A second possibility is for \CFA to have named tuples, as they exist in Swift and D. 2660 \begin{cfa} 2661 typedef [int x, int y] Point2D; 2662 Point2D p1, p2; 2663 p1.x + p1.y + p2.x + p2.y; 2664 p1.0 + p1.1 + p2.0 + p2.1; // equivalent 2665 \end{cfa} 2666 In this simpler interpretation, a tuple type carries with it a list of possibly empty identifiers. 2667 This approach fits naturally with the named return-value feature, and would likely go a long way towards implementing it. 2668 2669 Ultimately, the first two extensions introduce complexity into the model, with relatively little perceived benefit, and so were dropped from consideration. 2670 Named tuples are a potentially useful addition to the language, provided they can be parsed with a reasonable syntax. 2671 2672 2673 \section{Casting} 2603 2604 \subsection{Casting} 2605 2674 2606 In C, the cast operator is used to explicitly convert between types. 2675 2607 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. … … 2725 2657 That is, it is invalid to cast ©[int, int]© to ©[int, int, int]©. 2726 2658 2727 \section{Polymorphism} 2659 2660 \subsection{Polymorphism} 2661 2728 2662 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. 2729 2663 The integration of polymorphism, type assertions, and monomorphic specialization of tuple-assertions are a primary contribution of this thesis to the design of tuples. … … 2778 2712 Until 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). 2779 2713 This decision presents a conflict with the flexibility of tuples. 2780 \subsection{Assertion Inference} 2714 2715 2716 \subsubsection{Assertion Inference} 2717 2781 2718 \begin{cfa} 2782 2719 int f([int, double], double); … … 2902 2839 Unfortunately, C's syntax for subscripts precluded treating them as tuples. 2903 2840 The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©. 2904 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg ©f[ g()]© always means a single subscript value because there is only one set of brackets.2841 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg ©f[ g() ]© always means a single subscript value because there is only one set of brackets. 2905 2842 Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression. 2906 2843 \end{rationale} … … 2951 2888 2952 2889 2953 \s ection{Mass Assignment}2890 \subsection{Mass Assignment} 2954 2891 2955 2892 \CFA permits assignment to several variables at once using mass assignment~\cite{CLU}. … … 2991 2928 2992 2929 2993 \s ection{Multiple Assignment}2930 \subsection{Multiple Assignment} 2994 2931 2995 2932 \CFA also supports the assignment of several values at once, known as multiple assignment~\cite{CLU,Galletly96}. … … 3032 2969 3033 2970 3034 \s ection{Cascade Assignment}2971 \subsection{Cascade Assignment} 3035 2972 3036 2973 As in C, \CFA mass and multiple assignments can be cascaded, producing cascade assignment. … … 3048 2985 \end{cfa} 3049 2986 As in C, the rightmost assignment is performed first, \ie assignment parses right to left. 3050 3051 3052 \section{Field Tuples}3053 3054 Tuples may be used to select multiple fields of a record by field name.3055 Its general form is:3056 \begin{cfa}3057 §\emph{expr}§ . [ §\emph{fieldlist}§ ]3058 §\emph{expr}§ -> [ §\emph{fieldlist}§ ]3059 \end{cfa}3060 \emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©.3061 Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.3062 A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is3063 the following:3064 \begin{cfa}3065 struct s {3066 int f1, f2;3067 char f3;3068 double f4;3069 } v;3070 v.[ f3, f1, f2 ] = ['x', 11, 17 ]; §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§3071 f( v.[ f3, f1, f2 ] ); §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§3072 \end{cfa}3073 Note, the fields appearing in a record-field tuple may be specified in any order;3074 also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple.3075 3076 If a field of a ©struct© is itself another ©struct©, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:3077 \begin{cfa}3078 struct inner {3079 int f2, f3;3080 };3081 struct outer {3082 int f1;3083 struct inner i;3084 double f4;3085 } o;3086 3087 o.[ f1, i.[ f2, f3 ], f4 ] = [ 11, 12, 13, 3.14159 ];3088 \end{cfa}3089 2987 3090 2988
Note: See TracChangeset
for help on using the changeset viewer.