Index: doc/theses/jiada_liang_MMath/conclusion.tex =================================================================== --- doc/theses/jiada_liang_MMath/conclusion.tex (revision d93b8131b6d6f864fdf457bb174840310cb9dfd1) +++ doc/theses/jiada_liang_MMath/conclusion.tex (revision 08e0d654c1dfab371c0687df49b73356a9f12b70) @@ -106,5 +106,5 @@ CFA_Codec cfa_code = CFA_Codec.VORBIS; \end{cfa} -In the preceding example, the memory location of @c_code@ stores a value 9, the integral value of VORBIS. +The memory location of @c_code@ stores a value 9, the integral value of VORBIS. The memory of @cfa_code@ stores 5, which is the position of @CFA_Codec.VORBIS@ and can be mapped to value 9. @@ -112,4 +112,5 @@ before the relative position of VORBIS, without a re-compilation of @main.c@, variable @cfa_code@ would be mapped to an unintented value. +\begin{cfa} // libvacodec.h: v2 enum(int) C_Codec ! { Index: doc/theses/jiada_liang_MMath/trait.tex =================================================================== --- doc/theses/jiada_liang_MMath/trait.tex (revision d93b8131b6d6f864fdf457bb174840310cb9dfd1) +++ doc/theses/jiada_liang_MMath/trait.tex (revision 08e0d654c1dfab371c0687df49b73356a9f12b70) @@ -3,10 +3,10 @@ \CC introduced the @std::is_enum@ trait in \CC{11} and concept feature in \CC{20}. -With this combination, it is possible to write a polymorphic function over an enumerated type. +This combination makes it possible to write a polymorphic function over an enumerated type. \begin{c++} #include template @concept Enumerable@ = std::is_enum::value; -template<@Enumerable@ E> E f( E e ) { $\C{// constrainted type}$ - E w = e; $\C{// alloction and copy}$ +template<@Enumerable@ E> E f( E e ) { $\C{// constrained type}$ + E w = e; $\C{// allocation and copy}$ cout << e << ' ' << w << endl; $\C{// value}$ return w; $\C{// copy}$ @@ -24,5 +24,5 @@ -\section{Traits \texorpdfstring{\lstinline{CfaEnum}{CfaEnum}} and \texorpdfstring{\lstinline{TypedEnum}}{TypedEnum}} +\section{Traits \texorpdfstring{\lstinline{CfaEnum}}{CfaEnum} and \texorpdfstring{\lstinline{TypedEnum}}{TypedEnum}} Traits @CfaEnum@ and @TypedEnum@ define the enumeration attributes: @label@, @posn@, @value@, and @Countof@. @@ -34,5 +34,5 @@ } \end{cfa} - +\newpage Trait @CfaEnum@ defines attribute functions @label@ and @posn@ for all \CFA enumerations, and internally \CFA enumerations fulfills this assertion. \begin{cfa} @@ -107,5 +107,5 @@ \section{Discussion: Genericity} -At the start of this chapter, the \CC concept is introduced to constraint template types, \eg: +At the start of this chapter, the \CC concept is introduced to constrained template types, \eg: \begin{c++} concept Enumerable = std::is_enum::value; @@ -119,5 +119,5 @@ Alternatively, languages using traits, like \CFA, Scala, Go, and Rust, are defining a restriction based on a set of operations, variables, or structure fields that must exist to match with usages in a function or aggregate type. Hence, the \CFA enumeration traits never connected with the specific @enum@ kind. -Instead, anything that can look like the @enum@ kind is considered an enumeration (duck typing). +Instead, anything that can look like the @enum@ kind is considered an enumeration (static structural typing). However, Scala, Go, and Rust traits are nominative: a type explicitly declares a named traits to be of its type, while in \CFA, any type implementing all requirements declared in a trait implicitly satisfy its restrictions. @@ -125,5 +125,5 @@ For example, \VRef[Figure]{f:GeneralizedEnumerationFormatter} shows that pre-existing C enumerations can be upgraded to work and play with new \CFA enumeration facilities. Another example is adding constructors and destructors to pre-existing C types by simply declaring them for the old C type. -\CC fails at certain levels of legacy extension because many of the new \CC features must appear \emph{within} an aggregate definition due to the object-oriented nature of he type system, where it is impossible to change legacy library types. +\CC fails at certain levels of legacy extension because many of the new \CC features must appear \emph{within} an aggregate definition due to the object-oriented nature of the type system, where it is impossible to change legacy library types. @@ -134,5 +134,5 @@ forall( E ) trait Bounded { E lowerBound(); - E lowerBound(); + E upperBound(); }; \end{cfa} @@ -187,5 +187,5 @@ E upper = upperBound(); E lower = lowerBound(); - return fromInstance( upper ) + fromInstance( lower ) + 1; + return fromInstance( upper ) - fromInstance( lower ) + 1; } \end{cfa} @@ -215,6 +215,6 @@ A for-loop consists of loop control and body. -The loop control is often a 3-tuple: initializers, stopping condition, and advancement. -It is a common practice to declare one or more loop-index variables in initializers, checked these variables for stopping iteration, and updated the variables in advancement. +The loop control is often a 3-tuple: initializers, looping condition, and advancement. +It is a common practice to declare one or more loop-index variables in initializers, determines whether the variables satisfy the loop condition, and update the variables in advancement. Such a variable is called an \newterm{index} and is available for reading and writing within the loop body. (Some languages make the index read-only in the loop body.) @@ -240,5 +240,5 @@ \end{cfa} Both of these loops look correct but fail because these is an additional bound check within the advancement \emph{before} the conditional test to stop the loop, resulting in a failure at the endpoints of the iteration. -These loops must be restructured by moving the loop test to the end of the loop (@do-while@), as in loop (2) above, which is safe because an enumeration always at least one enumerator. +These loops must be restructured by moving the loop test to the end of the loop (@do-while@), as in loop (2) above, which is safe because an enumeration always has at least one enumerator. @@ -288,5 +288,6 @@ \CFA implements a few arithmetic operators for @CfaEnum@. -Unlike advancement functions in @Serial@, these operators perform direct arithmetic, so there is no implicit bound checks. +% Unlike advancement functions in @Serial@, these operators perform direct arithmetic, so there is no implicit bound checks. +Bound checks are added to these operations to ensure the outputs fulfills the @Bounded@ invariant. \begin{cfa} forall( E | CfaEnum( E ) | Serial( E ) ) { $\C{// distribution block}$