Changeset 1697c40 for doc/theses/jiada_liang_MMath
- Timestamp:
- Aug 4, 2024, 11:47:20 AM (5 weeks ago)
- Branches:
- master
- Children:
- 065de93
- Parents:
- b797fe36
- Location:
- doc/theses/jiada_liang_MMath
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/jiada_liang_MMath/CFAenum.tex
rb797fe36 r1697c40 202 202 203 203 \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). 204 Containment is norminative: an enumeration inherits all enumerators from another enumeration by declaring an @inline statement@ in its enumerator lists. 205 \begin{cfa} 206 enum( char * ) Names { /* as above */ }; 207 enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" }; 208 enum( char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" }; 209 \end{cfa} 210 In the preceding example, @Names2@ is defined with five enumerators, three of which are from @Name@ through containment, and two are self-declared. 211 @Names3@ inherits all five members from @Names2@ and declare two additional enumerators. 212 213 Enumeration inheritance forms a subset relationship. Specifically, the inheritance relationship for the example above is: 214 \begin{cfa} 215 Names $\(\subset\)$ Names2 $\(\subset\)$ Names3 $\C{// enum type of Names}$ 216 \end{cfa} 217 204 218 Inheritance can be nested, and a \CFA enumeration can inline enumerators from more than one \CFA enumeration, forming a tree-like hierarchy. 205 219 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. 208 222 209 \begin{cfa}210 enum( char * ) Names { /* as above */ };211 enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" };212 enum( char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" };213 \end{cfa}214 223 215 224 % Enumeration @Name2@ inherits all the enumerators and their values from enumeration @Names@ by containment, and a @Names@ enumeration is a @subtype@ of enumeration @Name2@. 216 225 % Note, that enumerators must be unique in inheritance but enumerator values may be repeated. 217 226 218 @Names2@ is defined with five enumerators, three of which are from @Name@ through containment, and two are self-declared. 219 @Names3@ inherits all five members from @Names2@ and declare two additional enumerators. 227 220 228 221 229 % The enumeration type for the inheriting type must be the same as the inherited type; 222 230 % hence the enumeration type may be omitted for the inheriting enumeration and it is inferred from the inherited enumeration, as for @Name3@. 223 231 % When inheriting from integral types, automatic numbering may be used, so the inheritance placement left to right is important. 224 Specifically, the inheritance relationship for @Names@ is: 225 \begin{cfa} 226 Names $\(\subset\)$ Names2 $\(\subset\)$ Names3 $\C{// enum type of Names}$ 227 \end{cfa} 232 228 233 229 234 % The enumeration base for the subtype must be the same as the super type. -
doc/theses/jiada_liang_MMath/background.tex
rb797fe36 r1697c40 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. 233 233 234 \section{\CFA Polymorphism} 235 236 \subsection{Function Overloading} 237 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 238 with different entities as long as they are different in terms of the number and type of parameters. 234 239 235 240 \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. 372 377 378 \subsection{Trait} 379 A @forall@ clause can asserts on multiple types and with multiple asserting functions. A common practice in \CFA is to group 380 the asserting functions in to a named \newterm{trait}. 373 381 374 382 \subsection{Trait} … … 448 456 449 457 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: 450 \begin{ enumerate}451 \item @unsafe@ from Bilson452 \item @poly@453 \item @safe@454 \item @sign@ is the number of sign/unsigned variable conversions455 \item @vars@ is the number of polymorphic type variables456 \item @specialization@ is a negative value of the number of type assertions457 \item @reference@ is the number of reference-to-rvalue conversions458 \end{ enumerate}458 \begin{itemize} 459 \item \textit{Unsafe} 460 \item \textit{Poly} 461 \item \textit{Safe} 462 \item \textit{Sign} is the number of sign/unsign variable conversion. 463 \item \textit{Vars} is the number of polymorphics type variable. 464 \item \textit{Specialization} is negative value of the number of type assertion. 465 \item \textit{Reference} is number of reference-to-rvalue conversion. 466 \end{itemize} 459 467 The extended conversion-cost model looks for candidates that are more specific and less generic. 460 468 @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@. 468 476 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. 469 For example, the conversion cost from @int@ to a @struct S@ is @infinite@. 477 For example, the conversion cost from @int@ to a @struct S@ is @infinite@. 478 479 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. 480 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 481 infinite conversion cost and non-infinite cast cost. -
doc/theses/jiada_liang_MMath/planet.cfa
rb797fe36 r1697c40 33 33 double earthMass = earthWeight / surfaceGravity( EARTH ); 34 34 35 Planet p = fromInt( prng( __count_e__( Planet ) ) ); // select a random orbiting body35 Planet p = fromInt( prng( countof( Planet ) ) ); // select a random orbiting body 36 36 // Planet p = fromInt( prng( 9 ) ); // select a random orbiting body 37 37 choose( p ) { 38 38 case MERCURY, VENUS, EARTH, MARS: 39 sout | label E( p ) | "is a rocky planet";39 sout | label( p ) | "is a rocky planet"; 40 40 case JUPITER, SATURN, URANUS, NEPTUNE: 41 sout | label E( p ) | "is a gas-giant planet";41 sout | label( p ) | "is a gas-giant planet"; 42 42 default: 43 sout | label E( p ) | "is not a planet";43 sout | label( p ) | "is not a planet"; 44 44 } 45 45 46 46 47 for ( p; enumPlanet ) {47 for ( p; Planet ) { 48 48 sout | "Your weight on " 49 | (p == MOON ? "the" : "") | label E(p)49 | (p == MOON ? "the" : "") | label(p) 50 50 | "is" | wd( 1,1, surfaceWeight( p, earthMass ) ) | "kg"; 51 51 }
Note: See TracChangeset
for help on using the changeset viewer.