Changeset 2572add
- Timestamp:
- Apr 8, 2025, 11:08:17 PM (6 months ago)
- Branches:
- master
- Children:
- 51b72bf5, 52eb7b7
- Parents:
- 597ddfeb
- Location:
- doc/theses/fangren_yu_MMath
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/fangren_yu_MMath/intro.tex
r597ddfeb r2572add 903 903 & O\footnote{except assignment}/F & O/F/M & V/O/F & M\footnote{not universal} & O/M & O/F/M & no & no \\ 904 904 general constraints\footnote{T $\Rightarrow$ parameter type, \# $\Rightarrow$ parameter number, N $\Rightarrow$ parameter name; R $\Rightarrow$ return type} 905 & T/\#/N/R & T/\# & T/\#/R & T/\# & T/\#/N/R & T/\#/N/R & T/\#/N & T/R \\ 905 & T/\#//R\footnote{parameter names can be used to disambiguate among overloads but not create overloads} 906 & T/\# & T/\#/R & T/\# & T/\#/N/R & T/\#/N/R & T/\#/N & T/R \\ 906 907 univ. type constraints\footnote{A $\Rightarrow$ concept, T $\Rightarrow$ interface/trait/type-class, B $\Rightarrow$ type bounds} 907 908 & no\footnote{generic cannot be overloaded} & C & T & B & B & T & T & T \\ -
doc/theses/fangren_yu_MMath/resolution.tex
r597ddfeb r2572add 159 159 In \CFA, trying to use such a system is problematic because of the presence of return-type overloading of functions and variable. 160 160 Specifically, \CFA expression resolution considers multiple interpretations of argument subexpressions with different types, \eg: 161 \begin{cfa}162 @generate a CFA example here@163 164 read more165 \end{cfa}166 161 so it is possible that both the selected function and the set of arguments are different, and cannot be compared with a partial-ordering system. 167 This situation arises often in \CFA, even in the simple expression @f(x)@, where both the function name @f@ and variable name @x@ are overloaded .162 This situation arises often in \CFA, even in the simple expression @f(x)@, where both the function name @f@ and variable name @x@ are overloaded (examples to follow). 168 163 169 164 Ada is another programming language that has overloading based on return type. 170 Although Ada also allows implicit type conversions of function arguments, it is fairly conservative on resolving ambiguities~\cite[\S~8.6]{Ada22}. 171 \begin{cfa} 172 @generate an Ada example here@ 173 174 section 8.6 the context of overload resolution 175 page 468, item number 28 - 30 176 \end{cfa} 177 There are only two preference rules in Ada overload resolution, one for primitive arithmetic operators and one for universal access types (pointer type); 178 \begin{ada} 179 Function "-"( L, R : Float ) return Integer is begin 180 return Integer(L) + (-Integer(R)); -- prevent infinite recursion 181 end; 182 Integer i; 183 i := 7 - 3; -- prefer 184 i := 7.2 - 3.5 185 \end{ada} 186 any other cases where an expression has multiple legal interpretations are considered ambiguous. 187 The current overload resolution system for \CFA is on the other end of the spectrum, as it tries to order every legal interpretations of an expression and chooses the best one according to cost, occasionally giving unexpected results rather than an ambiguity. 165 Ada has no type conversions but has subtyping so subtypes are convertible to supertypes. 166 There are only two preference rules in Ada overload resolution: 167 \begin{quote} 168 There is a preference for the primitive operators (and ranges) of the root numeric types @root_integer@ and @root_real@. 169 In particular, if two acceptable interpretations of a constituent of a complete context differ only in that one is for a primitive operator (or range) of the type @root_integer@ or @root_real@, and the other is not, 170 \end{quote} 171 However, I was unable to generate any Ada example program that demonstrates this preference. 172 In contrast, the \CFA overload resolution-system is at the other end of the spectrum, as it tries to order every legal interpretations of an expression and chooses the best one according to cost, occasionally giving unexpected results rather than an ambiguity. 188 173 189 174 Interestingly, the \CFA cost-based model can sometimes make expression resolution too permissive because it always attempts to select the lowest cost option, and only when there are multiple options tied at the lowest cost does it report the expression is ambiguous. … … 378 363 This is demonstrated in the following example, adapted from the C standard library: 379 364 \begin{cfa} 380 381 365 unsigned long long x; 366 (unsigned)( x >> 32 ); 382 367 \end{cfa} 383 368 \vspace{5pt} 384 369 In C semantics, this example is unambiguously upcasting 32 to @unsigned long long@, performing the shift, then downcasting the result to @unsigned@, at cost (1, 0, 3, 1, 0, 0, 0). 385 370 If ascription were allowed to be a first-class interpretation of a cast expression, it would be cheaper to select the @unsigned@ interpretation of @?>>?@ by downcasting @x@ to @unsigned@ and upcasting 32 to @unsigned@, at a total cost of (1, 0, 1, 1, 0, 0, 0). 386 \PAB{ This example feels incorrect. Assume a word size of 4 bits (long long). Given the value 1001, shift it >> 2, gives 10, which fits in a half word (int). Now truncate 1001 to a halfword 01 and shift it >> 2, gives 00. So the lower-cost alternative does generate the correct result. Basically truncation is an unsafe operation and hence has a huge negative cost.}387 However, this break from C semantics is not backwards compatible, so to maintain C compatibility, the \CFA resolver selects the lowest-cost interpretation of the cast argument for which a conversion or coercion to the target type exists (upcasting to @unsigned long long@ in the example above, due to the lack of unsafe downcasts), using the cost of the conversion itself only as a tie-breaker. \cite[pp.~46-47]{Moss19}371 \PAB{[Note, this alternate interpretation is semantically incorrect, because the downcasting \lstinline{x} to from \lstinline{long long} to \lstinline{unsigned} is unsafe (truncation).]} 372 However, this break from C semantics is not backwards compatible, so to maintain C compatibility, the \CFA resolver selects the lowest-cost interpretation of the cast argument for which a conversion or coercion to the target type exists (upcasting to @unsigned long long@ in the example above, due to the lack of unsafe downcasts), using the cost of the conversion itself only as a tie-breaker.~\cite[pp.~46-47]{Moss19} 388 373 \end{cquote} 389 374 However, a cast expression is unnecessary to have such inconsistency to C semantics. 390 375 An implicit argument-parameter type conversion in a function calls can replicate this issue without an explicit cast. 391 376 \begin{cfa} 392 unsigned long long x;393 void f( unsigned );377 unsigned long long x; 378 void f( unsigned ); 394 379 f( x >> 32 ); 395 380 \end{cfa} … … 619 604 \end{enumerate} 620 605 621 \CFA does attempt to incorporate upstream type information propagated from variable declaration with initializer, since the type of the variable being initialized is definitelyknown.606 \CFA does attempt to incorporate upstream type information propagated from variable a declaration with initializer, since the type of the variable being initialized is known. 622 607 However, the current type-environment representation is flawed in handling such type inferencing, when the return type in the initializer is polymorphic. 623 Currently, an inefficient workaround is performed to efficiencythe necessary effect.608 Currently, an inefficient workaround is performed to create the necessary effect. 624 609 The following is an annotated example of the workaround. 625 610 \begin{cfa} … … 629 614 const char * x = "hello world"; 630 615 int ch = x[0]; 631 // Fails with simple return type binding (xxx -- check this!) as follows:632 616 // * T is bound to int 633 617 // * (x: const char *) is unified with int *, which fails
Note:
See TracChangeset
for help on using the changeset viewer.