Changeset 0c51c8b4
- Timestamp:
- Aug 6, 2024, 9:49:56 AM (4 months ago)
- Branches:
- master
- Children:
- efd055c
- Parents:
- c03af31
- Location:
- doc/theses/jiada_liang_MMath
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/jiada_liang_MMath/CEnum.tex
rc03af31 r0c51c8b4 7 7 8 8 9 \section{ EnumeratorVisibility}10 \label{s: EnumeratorVisibility}9 \section{Visibility} 10 \label{s:CVisibility} 11 11 12 12 In C, unscoped enumerators present a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names. … … 42 42 43 43 44 \section{ EnumeratorScoping}44 \section{Scoping} 45 45 46 46 A C Enum can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope. … … 64 64 } 65 65 \end{cfa} 66 As in Section~\ref{s: EnumeratorVisibility}, opening multiple scoped enumerations in a @with@ can result in duplicate enumeration names, but \CFA implicit type resolution and explicit qualification/casting handle this localized scenario.66 As in Section~\ref{s:CVisibility}, opening multiple scoped enumerations in a @with@ can result in duplicate enumeration names, but \CFA implicit type resolution and explicit qualification/casting handle this localized scenario. 67 67 68 68 A partially implemented extension to enumerator scoping is providing a combination of scoped and unscoped enumerators, using individual denotations, where @'^'@ means unscoped. -
doc/theses/jiada_liang_MMath/CFAenum.tex
rc03af31 r0c51c8b4 6 6 7 7 8 \section{ EnumerationSyntax}9 10 \CFA extends the C enumeration declaration \see{\VRef{s:CEnumeration}} by parameterizing with a type (like a generic type), and adding Plan-9 inheritance \see{\VRef{s: EnumerationInheritance}} using an @inline@ to another enumeration type.8 \section{Syntax} 9 10 \CFA extends the C enumeration declaration \see{\VRef{s:CEnumeration}} by parameterizing with a type (like a generic type), and adding Plan-9 inheritance \see{\VRef{s:CFAInheritance}} using an @inline@ to another enumeration type. 11 11 \begin{cfa}[identifierstyle=\linespread{0.9}\it] 12 12 $\it enum$-specifier: … … 24 24 25 25 26 \section{ EnumerationOperations}26 \section{Operations} 27 27 28 28 \CFA enumerations have access to the three enumerations properties \see{\VRef{s:Terminology}}: label, order (position), and value via three overloaded functions @label@, @posn@, and @value@ \see{\VRef{c:trait} for details}. … … 43 43 A A @0@ 3 44 44 \end{cfa} 45 Finally, there is an additional enumeration routine @countof@ (like @sizeof@, @typeof@) that returns the number of enumerators in an enumeration. 46 \begin{cfa} 47 enum(int) E { A, B, C, D }; 48 countof( E ); // 4 49 \end{cfa} 50 This auto-generated function replaces the C idiom for automatically computing the number of enumerators \see{\VRef{s:Usage}}. 45 Finally, there is an additional enumeration pseudo-function @countof@ (like @sizeof@, @typeof@) that returns the number of enumerators in an enumeration. 46 \begin{cfa} 47 enum(int) E { A, B, C, D } e; 48 countof( E ); // 4, type argument 49 countof( e ); // 4, variable argument 50 \end{cfa} 51 This buildin function replaces the C idiom for automatically computing the number of enumerators \see{\VRef{s:Usage}}. 51 52 \begin{cfa} 52 53 enum E { A, B, C, D, @N@ }; // N == 4 … … 197 198 198 199 199 \section{Enumeration Inheritance} 200 \label{s:EnumerationInheritance} 200 \section{Subset} 201 202 An enumeration's type can be another enumeration. 203 \begin{cfa} 204 enum( char ) Letter { A = 'A', ... }; 205 enum( @Letter@ ) Greek { Alph = A, Beta = B, ... }; // alphabet intersection 206 \end{cfa} 207 Enumeration @Greek@ may have more or less enums than @Letter@, but the enum values \emph{must} be from @Letter@. 208 Therefore, @Greek@ enums are a subset of type @Letter@ and are type compatible with enumeration @Letter@, but @Letter@ enums are not type compatible with enumeration @Greek@. 209 210 211 \section{Inheritance} 212 \label{s:CFAInheritance} 201 213 202 214 \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). 203 215 Containment is nominative: an enumeration inherits all enumerators from another enumeration by declaring an @inline statement@ in its enumerator lists. 204 216 \begin{cfa} 205 enum( char * ) Names { /* $\see{\VRef[Figure]{ s:EnumerationInheritance}}$ */ };217 enum( char * ) Names { /* $\see{\VRef[Figure]{f:EumeratorTyping}}$ */ }; 206 218 enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" }; 207 219 enum( char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" }; … … 302 314 303 315 304 \section{ EnumeratorControl Structures}316 \section{Control Structures} 305 317 306 318 Enumerators can be used in multiple contexts. … … 392 404 393 405 394 \section{ EnumerationDimension}406 \section{Dimension} 395 407 396 408 \VRef{s:EnumeratorTyping} introduces the harmonizing problem between an enumeration and secondary information. … … 420 432 421 433 422 \section{ EnumerationI/O}434 \section{I/O} 423 435 424 436 As seen in multiple examples, enumerations can be printed and the default property printed is the enumerator's label, which is similar in other programming languages. … … 473 485 \label{f:EnumerationI/O} 474 486 \end{figure} 475 476 487 477 488 -
doc/theses/jiada_liang_MMath/background.tex
rc03af31 r0c51c8b4 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 overloaded238 with different entities as long as they are different in terms of the number and type of parameters.239 234 240 235 \section{\CFA} … … 253 248 Experience from \CC and \CFA developers is that the type system implicitly and correctly disambiguates the majority of overloaded names, \ie it is rare to get an incorrect selection or ambiguity, even among hundreds of overloaded (variables and) functions. 254 249 In many cases, a programmer has no idea there are name clashes, as they are silently resolved, simplifying the development process. 255 Depending on the language, ambiguous cases are resolved using some form of qualification or casting.250 Depending on the language, ambiguous cases are resolved using some form of qualification and/or casting. 256 251 257 252 … … 269 264 \end{cfa} 270 265 The type system examines each call size and selects the best matching overloaded function based on the number and types of the arguments. 271 If there are intermixed operands, @2 + 3.5@, the type system attempts (safe) conversions changing the arguments to one or more ofthe parameter type(s).266 If there are mixed-mode operands, @2 + 3.5@, the type system, like in C/\CC, attempts (safe) conversions, converting the argument type(s) to the parameter type(s). 272 267 273 268 … … 282 277 \end{cfa} 283 278 In this case, the name @f@ is overloaded depending on the number and parameter types. 284 The type system examines each call size and selects the best match ingbased on the number and types of the arguments.279 The type system examines each call size and selects the best match based on the number and types of the arguments. 285 280 Here, there is a perfect match for the call, @f( 'A' )@ with the number and parameter type of function (2). 286 281 … … 321 316 322 317 The prototype for the constructor/destructor are @void ?{}( T &, ... )@ and @void ^?{}( T &, ... )@, respectively. 323 The first parameter is logically ,the \lstinline[language=C++]{this} or \lstinline[language=Python]{self} in other object-oriented languages, and implicitly passed.318 The first parameter is logically the \lstinline[language=C++]{this} or \lstinline[language=Python]{self} in other object-oriented languages, and implicitly passed. 324 319 \VRef[Figure]{f:CFAConstructorDestructor} shows an example of creating and using a constructor and destructor. 325 320 Both constructor and destructor can be explicitly called to reuse a variable. … … 391 386 \end{cfa} 392 387 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. 388 Unlike templates in \CC, which are macro expansions at the call site, \CFA polymorphic functions are compiled, passing the call-site assertion functions as hidden parameters. 389 393 390 394 391 \subsection{Trait} 395 A @forall@ clause can asserts on multiple types and with multiple asserting functions. A common practice in \CFA is to group396 the asserting functions in to a named \newterm{trait}.397 398 \subsection{Trait}399 392 400 393 A @forall@ clause can assert many restrictions on multiple types. 401 A common practice is to refactor the assertions into a named \newterm{trait} .394 A common practice is to refactor the assertions into a named \newterm{trait}, similar to other lnaguages, like Go and Rust. 402 395 \begin{cfa} 403 396 forall(T) trait @Bird@ { … … 432 425 433 426 Most programming languages perform some implicit conversions among basic types to facilitate mixed-mode arithmetic; 434 otherwise, the program becomes littered with many explicit casts, which is not match programmer expectation.427 otherwise, the program becomes littered with many explicit casts, which does not match with programmer expectation. 435 428 C is an aggressive language as it provides conversions among almost all of the basic types, even when the conversion is potentially unsafe or not meaningful, \ie @float@ to @bool@. 436 429 C defines the resolution pattern as ``usual arithmetic conversion''~\cite[\S~6.3.1.8]{C11}, in which C looks for a \newterm{common type} between operands, and converts one or both operands to the common type. -
doc/theses/jiada_liang_MMath/intro.tex
rc03af31 r0c51c8b4 299 299 \begin{enumerate} 300 300 \item 301 overloading: provides a pattern to overload functions, literal, and variable for polymorphic enumerations. 302 \item 303 scoping: adds name space for enumerations. 304 \item 305 safety: defines a safe enumeration conversion scheme. 306 \item 307 harmonization: allows enumeration to be mapped with data. 308 \item 309 inheritance: implements containment inheritance for enumerations. 301 safety: Define a safe enumeration conversion scheme, both for C and \CFA, and replace ad-hoc C idioms with safer software-engineering approaches. 302 \item 303 overloading: Provide a pattern to overload functions, literals, and variables for polymorphic enumerations using the \CFA type system. 304 \item 305 scoping: Add a name space for enumerations and qualified access into the namespace to deal with the naming problem. 306 \item 307 generalization: Support all language types for enumerators with associated values providing enumeration constants for any type. 308 \item 309 inheritance: Implement subtyping and containment inheritance for enumerations. 310 \item 311 control flow: Extend control-flow structures making it safer and easier to enumerate over an enumeration. 312 \item 313 I/O: Provide input and output of enumerations based on enumerator names. 310 314 \end{enumerate} 311 315
Note: See TracChangeset
for help on using the changeset viewer.