Mar 13, 2019, 10:20:24 AM (5 years ago)
Aaron Moss <a3moss@…>
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, pthread-emulation, qualifiedEnum
320e72a2, ab3a69c

Add ascription casts to future work

1 edited


  • doc/theses/aaron_moss_PhD/phd/resolution-heuristics.tex

    r53bb8f1 ra2545593  
    381381The main challenge to implement this approach in \CFACC{} is applying the implicit conversions generated by the resolution process in the code-generation for the thunk functions that \CFACC{} uses to pass type assertions to their requesting functions with the proper signatures.
    383 Though performance of the existing algorithms is promising, some further optimizations do present themselves.
     383One \CFA{} feature that could be added to improve the ergonomics of overload selection is an \emph{ascription cast}; as discussed in Section~\ref{expr-cost-sec}, the semantics of the C cast operator are to choose the cheapest argument interpretation which is convertable to the target type, using the conversion cost as a tie-breaker.
     384An ascription cast would reverse these priorities, choosing the argument interpretation with the cheapest conversion to the target type, only using interpretation cost to break ties\footnote{A possible stricter semantics would be to select the cheapest interpretation with a zero-cost conversion to the target type, reporting a compiler error otherwise.}.
     385This would allow ascription casts to the desired return type to be used for overload selection:
     388int f$\(_1\)$(int);
     389int f$\(_2\)$(double);
     390int g$\(_1\)$(int);
     391double g$\(_2\)$(long);
     393f((double)42);  $\C[4.5in]{// select f\(_2\) by parameter cast}$
     394(as double)g(42); $\C[4.5in]{// select g\(_2\) by return ascription cast}$
     395(double)g(42); $\C[4.5in]{// select g\(_1\) NOT g\(_2\) because of parameter conversion cost}$
     398Though performance of the existing resolution algorithms is promising, some further optimizations do present themselves.
    384399The refined cost model discussed in Section~\ref{conv-cost-sec} is more expressive, but requires more than twice as many fields; it may be fruitful to investigate more tightly-packed in-memory representations of the cost-tuple, as well as comparison operations that require fewer instructions than a full lexicographic comparison.
    385400Integer or vector operations on a more-packed representation may prove effective, though dealing with the negative-valued $specialization$ field may require some effort.
Note: See TracChangeset for help on using the changeset viewer.