Changeset 1697c40

Timestamp:

Aug 4, 2024, 11:47:20 AM (39 hours ago)

Author:

JiadaL <j82liang@…>

Branches:

master

Children:

065de93

Parents:

b797fe36

Message:

merge local changes

Location:

doc/theses/jiada_liang_MMath

Files:

• CFAenum.tex (modified) (2 diffs)
• background.tex (modified) (4 diffs)
• planet.cfa (modified) (1 diff)

doc/theses/jiada_liang_MMath/CFAenum.tex

@@ -202 +202 @@
 
 \CFA Plan-9 inheritance may be used with \CFA enumerations, where Plan-9 inheritance is containment inheritance with implicit unscoping (like a nested unnamed @struct@/@union@ in C).
+Containment is norminative: an enumeration inherits all enumerators from another enumeration by declaring an @inline statement@ in its enumerator lists.
+\begin{cfa}
+enum( char * ) Names { /* as above */ };
+enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" };
+enum( char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" };
+\end{cfa}
+In the preceding example, @Names2@ is defined with five enumerators, three of which are from @Name@ through containment, and two are self-declared.
+@Names3@ inherits all five members from @Names2@ and declare two additional enumerators.
+
+Enumeration inheritance forms a subset relationship. Specifically, the inheritance relationship for the example above is:
+\begin{cfa}
+Names $\(\subset\)$ Names2 $\(\subset\)$ Names3 $\C{// enum type of Names}$
+\end{cfa}
+
 Inheritance can be nested, and a \CFA enumeration can inline enumerators from more than one \CFA enumeration, forming a tree-like hierarchy.
 However, the uniqueness of enumeration name applies to enumerators, including those from supertypes, meaning an enumeration cannot name enumerator with the same label as its subtype's members, or inherits 
@@ -207 +221 @@
 common supertype (the diamond problem), since such would unavoidably introduce duplicate enumerator labels. 
 
-\begin{cfa}
-enum( char * ) Names { /* as above */ };
-enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" };
-enum( char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" };
-\end{cfa}
 
 % Enumeration @Name2@ inherits all the enumerators and their values from enumeration @Names@ by containment, and a @Names@ enumeration is a @subtype@ of enumeration @Name2@.
 % Note, that enumerators must be unique in inheritance but enumerator values may be repeated.
 
-@Names2@ is defined with five enumerators, three of which are from @Name@ through containment, and two are self-declared.
-@Names3@ inherits all five members from @Names2@ and declare two additional enumerators.
+
 
 % The enumeration type for the inheriting type must be the same as the inherited type;
 % hence the enumeration type may be omitted for the inheriting enumeration and it is inferred from the inherited enumeration, as for @Name3@.
 % When inheriting from integral types, automatic numbering may be used, so the inheritance placement left to right is important.
-Specifically, the inheritance relationship for @Names@ is:
-\begin{cfa}
-Names $\(\subset\)$ Names2 $\(\subset\)$ Names3 $\C{// enum type of Names}$
-\end{cfa}
+
 
 % The enumeration base for the subtype must be the same as the super type. 

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}
@@ -371 +376 @@
 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}
@@ -448 +456 @@
 
 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.
@@ -467 +475 @@
 \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.

doc/theses/jiada_liang_MMath/planet.cfa

@@ -33 +33 @@
         double earthMass = earthWeight / surfaceGravity( EARTH );
 
-        Planet p = fromInt( prng( __count_e__( Planet ) ) ); // select a random orbiting body
+        Planet p = fromInt( prng( countof( Planet ) ) ); // select a random orbiting body
 //      Planet p = fromInt( prng( 9 ) ); // select a random orbiting body
         choose( p ) {
           case MERCURY, VENUS, EARTH, MARS:
-                sout | labelE( p ) | "is a rocky planet";
+                sout | label( p ) | "is a rocky planet";
           case JUPITER, SATURN, URANUS, NEPTUNE:
-                sout | labelE( p ) | "is a gas-giant planet";
+                sout | label( p ) | "is a gas-giant planet";
           default:
-                sout | labelE( p ) | "is not a planet";
+                sout | label( p ) | "is not a planet";
         }
 
 
-        for ( p; enum Planet ) {
+        for ( p; Planet ) {
                 sout | "Your weight on "
-                 | (p == MOON ? "the" : "") | labelE(p)
+                 | (p == MOON ? "the" : "") | label(p)
                          | "is" | wd( 1,1, surfaceWeight( p, earthMass ) ) | "kg";
         }