Index: doc/theses/jiada_liang_MMath/background.tex =================================================================== --- doc/theses/jiada_liang_MMath/background.tex (revision 5b4c8df9dc208f341ec7d3f9e57a247012317062) +++ doc/theses/jiada_liang_MMath/background.tex (revision ab11ab1beb9d10d00e4dab6b43817c7e9271e435) @@ -89,5 +89,5 @@ Here, the aliased constants are: 20, 10, 20, 21, and -7. Direct initialization is by a compile-time expression generating a constant value. -Indirect initialization (without initializer, @Max10Plus1@) is called \newterm{auto-initialization}, where enumerators are assigned values from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@. +Indirect initialization (without an initializer, @Max10Plus1@) is called \newterm{auto-initialization}, where enumerators are assigned values from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@. Because multiple independent enumerators can be combined, enumerators with the same values can occur. The enumerators are rvalues, so assignment is disallowed. @@ -112,5 +112,5 @@ enum @Week@ { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun }; \end{clang} -and adopts the same semantics with respect to direct and auto intialization. +and adopts the same semantics as direct and auto initialization. For example, @Mon@ to @Wed@ are implicitly assigned with constants @0@--@2@, @Thu@ is explicitly set to constant @10@, and @Fri@ to @Sun@ are implicitly assigned with constants @11@--@13@. As well, initialization may occur in any order. @@ -123,5 +123,5 @@ Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma.\footnote{ A terminating comma appears in other C syntax, \eg the initializer list.} -This feature allow enumerator lines to be interchanged without moving a comma. +This feature allows enumerator lines to be interchanged without moving a comma. Named enumerators are also unscoped. @@ -136,5 +136,5 @@ A ``plain'' @int@ object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range @INT_MIN@ to @INT_MAX@ as defined in the header @@).~\cite[\S~6.2.5(5)]{C11} \end{quote} -However, @int@ means a 4 bytes on both 32/64-bit architectures, which does not seem like the ``natural'' size for a 64-bit architecture. +However, @int@ means 4 bytes on both 32/64-bit architectures, which does not seem like the ``natural'' size for a 64-bit architecture. Whereas, @long int@ means 4 bytes on a 32-bit and 8 bytes on 64-bit architectures, and @long long int@ means 8 bytes on both 32/64-bit architectures, where 64-bit operations are simulated on 32-bit architectures. \VRef[Figure]{f:gccEnumerationStorageSize} shows both @gcc@ and @clang@ partially ignore this specification and type the integral size of an enumerator based its initialization. @@ -204,5 +204,5 @@ \end{cfa} Here, serendipitously the auto-incrementing counts the number of enumerators and puts the total into the last enumerator @N@. -This @N@ is often used as the dimension for an array assocated with the enumeration. +This @N@ is often used as the dimension for an array associated with the enumeration. \begin{cfa} E array[@N@]; @@ -235,5 +235,5 @@ \section{\texorpdfstring{\CFA}{Cforall}} -\CFA in \emph{not} an object-oriented programming-language, \ie functions cannot be nested in aggregate types, and hence, there is no \newterm{receiver} notation for calling functions, \eg @obj.method(...)@, where the first argument proceeds the call and becomes an implicit first (\lstinline[language=C++]{this}) parameter. +\CFA in \emph{not} an object-oriented programming-language, \ie functions cannot be nested in aggregate types, and hence, there is no \newterm{receiver} notation for calling functions, \eg @obj.method(...)@, where the first argument proceeds the call and becomes an implicit first (\lstinline[language=C++]{this}) parameter. The following sections provide short descriptions of \CFA features needed further in the thesis. Other \CFA features are presented in-situ with short explanations, or no explanation because the feature is obvious to C programmers. @@ -263,5 +263,5 @@ s1 = @?+?@( s1, s2 ); $\C{// direct call}\CRT$ \end{cfa} -The type system examines each call size and selects the best matching overloaded function based on the number and types of the arguments. +The type system examines each call size and selects the best matching overloaded function based on the number and types of arguments. 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). @@ -308,6 +308,6 @@ \subsection{Constructor and Destructor} -While \CFA in not object oriented, it adopts many language features commonly used in object-oriented languages; -these features are independent from object-oriented programming. +While \CFA is not object-oriented, it adopts many language features commonly used in object-oriented languages; +these features are independent of object-oriented programming. All objects in \CFA are initialized by @constructors@ \emph{after} allocation and de-initialized \emph{before} deallocation. @@ -378,5 +378,5 @@ At the call size, the type parameter @T@ is bounded to @int@ from the argument @42@. -For polymorphic functions to be useful, the @forall@ clause needs \newterm{type assertion}s that restricts the polymorphic types it accepts. +For polymorphic functions to be useful, the @forall@ clause needs \newterm{type assertion}s that restrict the polymorphic types it accepts. \begin{cfa} forall( T @| { void foo( T ); }@ ) void bar( T t ) { @foo( t );@ } @@ -392,5 +392,5 @@ A @forall@ clause can assert many restrictions on multiple types. -A common practice is to refactor the assertions into a named \newterm{trait}, similar to other lnaguages, like Go and Rust. +A common practice is to refactor the assertions into a named \newterm{trait}, similar to other languages, like Go and Rust. \begin{cfa} forall(T) trait @Bird@ { @@ -416,5 +416,5 @@ When multiple best matches exist, the resolution is ambiguous. -The \CFA resolver attempts to identity a best candidate based on: first, the number of parameters and types, and second, when no exact match exists, the fewest implicit conversions and polymorphic variables. +The \CFA resolver attempts to identify the best candidate based on: first, the number of parameters and types, and second, when no exact match exists, the fewest implicit conversions and polymorphic variables. Finding an exact match is not discussed here, because the mechanism is fairly straightforward, even when the search space is large; only finding a non-exact match is discussed in detail. @@ -425,8 +425,8 @@ Most programming languages perform some implicit conversions among basic types to facilitate mixed-mode arithmetic; -otherwise, the program becomes littered with many explicit casts, which does not match with programmer expectation. +otherwise, the program becomes littered with many explicit casts, which does not match with programmer's expectations. 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@. 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. -Loosely defined, a common type is a the smallest type in terms of size of representation that both operands can be converted into without losing their precision, called a \newterm{widening} or \newterm{safe conversion}. +Loosely defined, a common type is the smallest type in terms of the size of representation that both operands can be converted into without losing their precision, called a \newterm{widening} or \newterm{safe conversion}. \CFA generalizes ``usual arithmetic conversion'' to \newterm{conversion cost}. @@ -441,13 +441,13 @@ \end{enumerate} Sum of degree is a method to quantify C's integer and floating-point rank. -Every pair of widening conversion types is assigned a \newterm{distance}, and distance between the two same type is 0. -For example, the distance from @char@ to @int@ is 2, distance from @int@ to @long@ is 1, and distance from @int@ to @long long int@ is 2. +Every pair of widening conversion types is assigned a \newterm{distance}, and the distance between the two same types is 0. +For example, the distance from @char@ to @int@ is 2, the distance from @int@ to @long@ is 1, and the distance from @int@ to @long long int@ is 2. This distance does not mirror C's rank system. For example, the rank of @char@ and @signed char@ are the same in C, but the distance from @char@ to @signed char@ is assigned 1. -@safe@ cost is summing all pairs of argument to parameter safe conversion distances. +@safe@ cost is summing all pairs of arguments to parameter safe conversion distances. Among the three costs in Bilson's model, @unsafe@ is the most significant cost and @safe@ is the least significant, with an implication that \CFA always choose a candidate with the lowest @unsafe@, if possible. For example, assume the overloaded function @foo@ is called with two @int@ parameter. -The cost for every overloaded @foo@ has been list along: +The cost for every overloaded @foo@ has been listed along: \begin{cfa} void foo( char, char ); $\C[2.5in]{// (1) (2, 0, 0)}$ @@ -462,5 +462,5 @@ foo( i, j ); $\C{// convert j to long and call (8)}\CRT$ \end{cfa} -The overloaded instances are ordered from the highest to the lowest cost, and \CFA select the last candidate (8). +The overloaded instances are ordered from the highest to the lowest cost, and \CFA selects the last candidate (8). 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: @@ -469,12 +469,12 @@ \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{Sign} is the number of sign/unsign variable conversions. +\item \textit{Vars} is the number of polymorphic type variables. +\item \textit{Specialization} is the negative value of the number of type assertions. \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. -A more generic type means less constraints on its parameter types. +A more generic type means fewer constraints on its parameter types. \CFA favours candidates with more restrictions on polymorphism, so @forall( T ) void foo( T, T )@ has lower cost. @specialization@ is an arbitrary count-down value starting at zero. @@ -483,9 +483,9 @@ \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. +A conversion cost is @zero@ when the argument and parameter have 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@. 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. +For most cast-expression resolutions, a cast cost is equal to a conversion cost. Cast cost exists as an independent matrix for conversion that cannot happen implicitly, while being possible with an explicit cast. -These conversions are often defined to have infinite conversion cost and non-infinite cast cost. +These conversions are often defined to have a infinite conversion cost and a non-infinite cast cost. Index: doc/theses/jiada_liang_MMath/intro.tex =================================================================== --- doc/theses/jiada_liang_MMath/intro.tex (revision 5b4c8df9dc208f341ec7d3f9e57a247012317062) +++ doc/theses/jiada_liang_MMath/intro.tex (revision ab11ab1beb9d10d00e4dab6b43817c7e9271e435) @@ -1,5 +1,5 @@ \chapter{Introduction} -All basic types in a programming language have a set of constants (symbols), and these constants represent computable values, \eg integer types have constants @-1@, @17@, @0xff@ representing whole numbers, floating-point types have constants @5.3@, @2.3E-5@, @0xff.ffp0@ representing real numbers, character types have constants @'a'@, @"abc\n"@, \mbox{\lstinline{u8"}\texttt{\guillemotleft{na\"{i}ve}\guillemotright}\lstinline{"}} representing (human readable) text, \etc. +All basic types in a programming language have a set of constants (symbols), and these constants represent computable values, \eg integer types have constants @-1@, @17@, @0xff@ representing whole numbers, floating-point types have constants @5.3@, @2.3E-5@, @0xff.ffp0@ representing real numbers, character types have constants @'a'@, @"abc\n"@, \mbox{\lstinline{u8"}\texttt{\guillemotleft{na\"{i}ve}\guillemotright}\lstinline{"}} representing (human readable) text, \etc. Constants can be overloaded among types, \eg @0@ is a null pointer for all pointer types, and the value zero for integer and floating-point types. (In \CFA, the constants @0@ and @1@ can be overloaded for any type.) @@ -12,5 +12,5 @@ A constant's symbolic name is dictated by language syntax related to types, \eg @5.@ (double), @5.0f@ (float), @5l@ (long double). In general, the representation of a constant's value is \newterm{opaque}, so the internal representation can be chosen arbitrarily, \eg two's complement, IEEE floating-point. -In theory, there are an infinite set of constant names per type representing an infinite set of values. +In theory, there is an infinite set of constant names per type representing an infinite set of values. It is common in mathematics, engineering, and computer science to alias new constants to existing constants so they have the same value, \eg $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), K(k), M, G, T for powers of 2\footnote{Overloaded with SI powers of 10.} often prefixing bits (b) or bytes (B), \eg Gb, MB, and in general situations, \eg specific times (noon, New Years), cities (Big Apple), flowers (Lily), \etc. @@ -23,5 +23,5 @@ Because an aliased name is a constant, it cannot appear in a mutable context, \eg \mbox{$\pi$ \lstinline{= 42}} is meaningless, and a constant has no address, \ie it is an \newterm{rvalue}\footnote{ The term rvalue defines an expression that can only appear on the right-hand side of an assignment expression.}. -In theory, there are an infinite set of possible aliasing, in practice, the number of aliasing per program is finite and small. +In theory, there is an infinite set of possible aliasing; in practice, the number of aliasing per program is finite and small. Aliased constants can form an (ordered) set, \eg days of a week, months of a year, floors of a building (basement, ground, 1st), colours in a rainbow, \etc. @@ -59,5 +59,5 @@ \end{sloppypar} \item -The alias names are constants, which follows transitively from their binding to other constants. +The alias names are constants, which follow transitively from their binding to other constants. \item Defines a type for generating instants (variables). @@ -105,5 +105,5 @@ Hence, the term \emph{enumeration} can be confusing and misunderstood. Furthermore, some languages conjoin the enumeration with other type features, making it difficult to tease apart which feature is being used. -This section discusses some language features that are sometimes called an enumeration but do not provide all enumeration aspects. +This section discusses some language features that are sometimes called enumeration but do not provide all enumeration aspects. @@ -140,5 +140,5 @@ \end{cfa} For these reasons, aliasing is sometimes called an enumeration. -However, there is no type to create a type-checked instance or iterator cursor, so there is no ability for enumerating. +However, there is no type to create a type-checked instance or iterator cursor, so there is no ability to enumerate. Hence, there are multiple enumeration aspects not provided by aliasing, justifying a separate enumeration type in a programming language. @@ -158,5 +158,5 @@ the ADT has three variants (constructors), @A@, @B@, @C@, with associated types @Int@, @Double@, and @S@. The constructors create an initialized value of the specific type that is bound to the immutable variables @foo@, @bar@, and @baz@. -Hence, the ADT @Foo@ is like a union containing values of the associated types, and a constructor name is used to intialize and access the value using dynamic pattern-matching. +Hence, the ADT @Foo@ is like a union containing values of the associated types, and a constructor name is used to initialize and access the value using dynamic pattern-matching. \begin{cquote} \setlength{\tabcolsep}{20pt} @@ -194,9 +194,9 @@ baz = Z 5; \end{haskell} -Here, the constructor name gives different meaning to the values in the common \lstinline[language=Haskell]{Int} type, \eg the value @3@ has different interpretations depending on the constructor name in the pattern matching. +Here, the constructor name gives different meanings to the values in the common \lstinline[language=Haskell]{Int} type, \eg the value @3@ has different interpretations depending on the constructor name in the pattern matching. Note, the term \newterm{variant} is often associated with ADTs. However, there are multiple languages with a @variant@ type that is not an ADT \see{Algol68~\cite{Algol68} or \CC \lstinline{variant}}. -Here, the type (and possibly the position for equivalent types) is used to discriminant the specific \emph{variant} within the variant instance. +Here, the type (and possibly the position for equivalent types) is used to discriminate the specific \emph{variant} within the variant instance. For example, \VRef[Figure]{f:C++variant} shows the \CC equivalent of the two Haskell ADT types using variant types. In these languages, the variant cannot be used to simulate an enumeration. @@ -246,6 +246,6 @@ data Week = Mon | Tue | Wed | Thu | Fri | Sat | Sun deriving(Enum, Eq, Show) \end{haskell} -the default type for each constructor is the unit type, and deriving from @Enum@ enforces no other associated types, @Eq@ allows equality comparison, and @Show@ is for printing. -The nullary constructors for the unit types are numbered left-to-right from $0$ to @maxBound@$- 1$, and provides enumerating operations @succ@, @pred@, @enumFrom@, @enumFromTo@. +the default type for each constructor is the unit type, and deriving from @Enum@ enforces no other associated types. The @Eq@ allows equality comparison, and @Show@ is for printing. +The nullary constructors for the unit types are numbered left-to-right from $0$ to @maxBound@$- 1$, and provide enumerating operations @succ@, @pred@, @enumFrom@, @enumFromTo@. \VRef[Figure]{f:HaskellEnumeration} shows enumeration comparison and iterating (enumerating). @@ -296,5 +296,5 @@ However, when extended with advanced features, enumerations become complex for both the type system and the runtime implementation. -The contribution of this work are: +The contributions of this work are: \begin{enumerate} \item @@ -303,5 +303,5 @@ overloading: Provide a pattern to overload functions, literals, and variables for polymorphic enumerations using the \CFA type system. \item -scoping: Add a name space for enumerations and qualified access into the namespace to deal with the naming problem. +scoping: Add a namespace for enumerations and qualified access into the namespace to deal with the naming problem. \item generalization: Support all language types for enumerators with associated values providing enumeration constants for any type. Index: doc/theses/jiada_liang_MMath/uw-ethesis-frontpgs.tex =================================================================== --- doc/theses/jiada_liang_MMath/uw-ethesis-frontpgs.tex (revision 5b4c8df9dc208f341ec7d3f9e57a247012317062) +++ doc/theses/jiada_liang_MMath/uw-ethesis-frontpgs.tex (revision ab11ab1beb9d10d00e4dab6b43817c7e9271e435) @@ -141,13 +141,13 @@ One of the key properties of an enumeration is the ability to enumerate (iterate) through the constants, and hence, access their values, if present. C restricts an enumeration to the integral type @signed int@, while \CC extends enumerations to all integral types, meaning enumeration names must bind to integer constants. -Other modern programming languages provide bindings to any type and additional features to extend enumeration capabilities for better software-engineering practices. - -The \CFA (C-for-all) programming language is an evolutionary refinement of the C programing language. -One of its distinctive feature is a parametric-polymorphic generic type. -However, legacy data types from C, such as enumerations, do not adapt well into the \CFA generic type-system. +Other modern programming languages provide bindings to any type and additional features to extend enumeration capabilities for better software engineering practices. + +The \CFA (C-for-all) programming language is an evolutionary refinement of the C programming language. +One of its distinctive features is a parametric-polymorphic generic type. +However, legacy data types from C, such as enumerations, do not adapt well to the \CFA generic type system. This thesis extends the simple and unsafe enumeration type in the C programming language into a complex and safe enumeration type in the \CFA programming-language, while maintaining backwards compatibility with C. The major contribution is an adaptation of enumerated types with the \CFA type-system in a way that integrates naturally with the generic types. -This thesis also presents a number of smaller refinement to the \CFA overload resolution rules for enumerated types, each of which improves the intuitive nature of enumeration name resolution by the compiler. +This thesis also presents several smaller refinements to the \CFA overload resolution rules for enumerated types, each of which improves the intuitive nature of enumeration name resolution by the compiler. Finally, this work adds other useful features to enumerations that better support software-engineering practices and simplify program development. @@ -166,8 +166,8 @@ Thanks to Gregor Richards and Yzihou Zhang for reading my thesis. -Special thanks to Andrew James Beach for your insight on the theory development on the thesis. +Special thanks to Andrew James Beach for your insight on the theory development of the thesis. Thanks to Michael Brooks, Fangran Yu, Colby Parsons, Thierry Delisle, Mubeen Zulifiqar, -and the entire \CFA team for development of the \CFA language, making it the best language it can be. +and the entire \CFA team for the development of the \CFA language, making it the best language it can be. Finally, a special thank you to Huawei Canada for funding this work.