Changeset 2572add


Ignore:
Timestamp:
Apr 8, 2025, 11:08:17 PM (6 months ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
master
Children:
51b72bf5, 52eb7b7
Parents:
597ddfeb
Message:

more proofreading

Location:
doc/theses/fangren_yu_MMath
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/fangren_yu_MMath/intro.tex

    r597ddfeb r2572add  
    903903                                                & O\footnote{except assignment}/F       & O/F/M & V/O/F & M\footnote{not universal}     & O/M   & O/F/M & no    & no    \\
    904904general 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 \\
    906907univ. type constraints\footnote{A $\Rightarrow$ concept, T $\Rightarrow$ interface/trait/type-class, B $\Rightarrow$ type bounds}
    907908                                                & no\footnote{generic cannot be overloaded}             & C             & T                     & B             & B                     & T                     & T                     & T \\
  • doc/theses/fangren_yu_MMath/resolution.tex

    r597ddfeb r2572add  
    159159In \CFA, trying to use such a system is problematic because of the presence of return-type overloading of functions and variable.
    160160Specifically, \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 more
    165 \end{cfa}
    166161so 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.
     162This 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).
    168163
    169164Ada 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.
     165Ada has no type conversions but has subtyping so subtypes are convertible to supertypes.
     166There are only two preference rules in Ada overload resolution:
     167\begin{quote}
     168There is a preference for the primitive operators (and ranges) of the root numeric types @root_integer@ and @root_real@.
     169In 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}
     171However, I was unable to generate any Ada example program that demonstrates this preference.
     172In 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.
    188173
    189174Interestingly, 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.
     
    378363This is demonstrated in the following example, adapted from the C standard library:
    379364\begin{cfa}
    380         unsigned long long x;
    381         (unsigned)( x >> 32 );
     365unsigned long long x;
     366(unsigned)( x >> 32 );
    382367\end{cfa}
    383368\vspace{5pt}
    384369In 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).
    385370If 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).]}
     372However, 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}
    388373\end{cquote}
    389374However, a cast expression is unnecessary to have such inconsistency to C semantics.
    390375An implicit argument-parameter type conversion in a function calls can replicate this issue without an explicit cast.
    391376\begin{cfa}
    392 unsigned long long x;
    393 void f( unsigned );
     377        unsigned long long x;
     378        void f( unsigned );
    394379f( x >> 32 );
    395380\end{cfa}
     
    619604\end{enumerate}
    620605
    621 \CFA does attempt to incorporate upstream type information propagated from variable declaration with initializer, since the type of the variable being initialized is definitely known.
     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.
    622607However, 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 efficiency the necessary effect.
     608Currently, an inefficient workaround is performed to create the necessary effect.
    624609The following is an annotated example of the workaround.
    625610\begin{cfa}
     
    629614const char * x = "hello world";
    630615int ch = x[0];
    631 // Fails with simple return type binding (xxx -- check this!) as follows:
    632616// * T is bound to int
    633617// * (x: const char *) is unified with int *, which fails
Note: See TracChangeset for help on using the changeset viewer.