Changeset 748877f for doc/theses/jiada_liang_MMath/background.tex

Timestamp:

Aug 4, 2024, 12:23:00 PM (2 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

7ab24fef

Parents:

a57ad8a (diff), 065de93 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:

• doc/theses/jiada_liang_MMath/background.tex (modified) (4 diffs)

doc/theses/jiada_liang_MMath/background.tex

@@ -232 +232 @@
 While C provides a true enumeration, it is restricted, has unsafe semantics, and does not provide useful/advanced enumeration features found in other programming languages.
 
+\section{\CFA Polymorphism}
+
+\subsection{Function Overloading}
+Function overloading is programming languages feature wherein functions may share the same name, but with different function signatures. In both C++ and \CFA, function names can be overloaded 
+with different entities as long as they are different in terms of the number and type of parameters.
 
 \section{\CFA}
@@ -387 +392 @@
 The assertion on @T@ restricts the range of types that can be manipulated by @bar@ to only those that have an implementation of @foo@ with the matching signature, allowing @bar@'s call to @foo@ in its body.
 
+\subsection{Trait}
+A @forall@ clause can asserts on multiple types and with multiple asserting functions. A common practice in \CFA is to group
+the asserting functions in to a named \newterm{trait}. 
 
 \subsection{Trait}
@@ -464 +472 @@
 
 In the next iteration of \CFA, Schluntz and Aaron~\cite{Moss18} expanded conversion cost to a 7-tuple with 4 additional categories, @(unsafe, poly, safe, sign, vars, specialization, reference)@, with the following interpretations:
-\begin{enumerate}
-\item @unsafe@ from Bilson
-\item @poly@
-\item @safe@
-\item @sign@ is the number of sign/unsigned variable conversions
-\item @vars@ is the number of polymorphic type variables
-\item @specialization@ is a negative value of the number of type assertions
-\item @reference@ is the number of reference-to-rvalue conversions
-\end{enumerate}
+\begin{itemize}
+\item \textit{Unsafe}
+\item \textit{Poly}
+\item \textit{Safe}
+\item \textit{Sign} is the number of sign/unsign variable conversion.
+\item \textit{Vars} is the number of polymorphics type variable.
+\item \textit{Specialization} is negative value of the number of type assertion.
+\item \textit{Reference} is number of reference-to-rvalue conversion.
+\end{itemize}
 The extended conversion-cost model looks for candidates that are more specific and less generic.
 @vars@ disambiguates @forall( T, V ) foo( T, V )@ and @forall( T ) void foo( T, T )@, where the extra type parameter @V@ makes is more generic.
@@ -483 +491 @@
 \CFA defines two special cost values: @zero@ and @infinite@.
 A conversion cost is @zero@ when argument and parameter has an exact match, and a conversion cost is @infinite@ when there is no defined conversion between two types.
-For example, the conversion cost from @int@ to a @struct S@ is @infinite@. 
+For example, the conversion cost from @int@ to a @struct S@ is @infinite@.
+
+In \CFA, the meaning of a C style cast is determined by its @Cast Cost@. For most cast expression resolution, a cast cost is equal to a conversion cost.
+Cast cost exists as an independent matrix for conversion that cannot happen implcitly, while being possible with an explicit cast. These conversions are often defined to have 
+infinite conversion cost and non-infinite cast cost.