Index: doc/theses/jiada_liang_MMath/CFAenum.tex =================================================================== --- doc/theses/jiada_liang_MMath/CFAenum.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/CFAenum.tex (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -1,12 +1,12 @@ \chapter{\texorpdfstring{\CFA}{Cforall} Enumeration} -\CFA extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages. -Any enumeration extensions must be intuitive to C programmers both in syntax and semantics. -The following sections detail all of my new contributions to enumerations in \CFA. +\CFA extends C-Style enumeration by adding a number of new features that bring enumerations in line with other modern programming languages. +Any enumeration extensions must be intuitive to C programmers in syntax and semantics. +The following sections detail my new contributions to enumerations in \CFA. \section{Syntax} -\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. +\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. \begin{cfa}[identifierstyle=\linespread{0.9}\it] $\it enum$-specifier: @@ -43,5 +43,5 @@ A A @0@ 3 \end{cfa} -Finally, there is an additional enumeration pseudo-function @countof@ (like @sizeof@, @typeof@) that returns the number of enumerators in an enumeration. +Finally, \CFA introduces an additional enumeration pseudo-function @countof@ (like @sizeof@, @typeof@) that returns the number of enumerators in an enumeration. \begin{cfa} enum(int) E { A, B, C, D } e; @@ -49,5 +49,5 @@ countof( e ); // 4, variable argument \end{cfa} -This buildin function replaces the C idiom for automatically computing the number of enumerators \see{\VRef{s:Usage}}. +This built-in function replaces the C idiom for automatically computing the number of enumerators \see{\VRef{s:Usage}}. \begin{cfa} enum E { A, B, C, D, @N@ }; // N == 4 @@ -56,7 +56,7 @@ The underlying representation of \CFA enumeration object is its position, saved as an integral type. Therefore, the size of a \CFA enumeration is consistent with a C enumeration. -Attribute function @posn@ performs type substitution on an expression from \CFA type to integral type. -The label and value of an enumerator is stored in a global data structure for each enumeration, where attribute functions @label@/@value@ map an \CFA enumeration object to the corresponding data. -These operations do not apply to C Enums because backwards compatibility means the necessary backing data structures cannot be supplied. +Attribute function @posn@ performs type substitution on an expression from \CFA type to an integral type. +The label and value of an enumerator are stored in a global data structure for each enumeration, where attribute functions @label@/@value@ map an \CFA enumeration object to the corresponding data. +These operations do not apply to C Enums because backward compatibility means the necessary backing data structures cannot be supplied. @@ -64,20 +64,20 @@ \label{s:OpaqueEnum} -When an enumeration type is empty is it an \newterm{opaque} enumeration. +When an enumeration type is empty. it is an \newterm{opaque} enumeration. \begin{cfa} enum@()@ Mode { O_RDONLY, O_WRONLY, O_CREAT, O_TRUNC, O_APPEND }; \end{cfa} -Here, the internal representation is chosen by the compiler and hidden, so the enumerators cannot be initialized. -Compared to the C enum, opaque enums are more restrictive in terms of typing and cannot be implicitly converted to integers. +Here, the compiler chooses the internal representation, which is hidden, so the enumerators cannot be initialized. +Compared to the C enum, opaque enums are more restrictive regarding typing and cannot be implicitly converted to integers. \begin{cfa} Mode mode = O_RDONLY; int www @=@ mode; $\C{// disallowed}$ \end{cfa} -Opaque enumerations have only two attribute properties @label@ and @posn@. +Opaque enumerations have only two attribute properties, @label@ and @posn@. \begin{cfa} char * s = label( O_TRUNC ); $\C{// "O\_TRUNC"}$ int open = posn( O_WRONLY ); $\C{// 1}$ \end{cfa} -The equality and relational operations are available. +Equality and relational operations are available. \begin{cfa} if ( mode @==@ O_CREAT ) ... @@ -89,7 +89,7 @@ \label{s:EnumeratorTyping} -When an enumeration type is specified, all enumerators have that type and can be initialized with constants of that type or compile-time convertable to that type. -Figure~\ref{f:EumeratorTyping} shows a series of examples illustrating that all \CFA types can be use with an enumeration and each type's values used to set the enumerator constants. -Note, the use of the synonyms @Liz@ and @Beth@ in the last declaration. +When an enumeration type is specified, all enumerators have that type and can be initialized with constants of that type or compile-time convertible to that type. +Figure~\ref{f:EumeratorTyping} shows a series of examples illustrating that all \CFA types can be used with an enumeration, and each type's values are used to set the enumerator constants. +Note the use of the synonyms @Liz@ and @Beth@ in the last declaration. Because enumerators are constants, the enumeration type is implicitly @const@, so all the enumerator types in Figure~\ref{f:EumeratorTyping} are logically rewritten with @const@. @@ -132,5 +132,5 @@ }; \end{cfa} -Note, the enumeration type can be a structure (see @Person@ in Figure~\ref{f:EumeratorTyping}), so it is possible to have the equivalent of multiple arrays of companion data using an array of structures. +Note that the enumeration type can be a structure (see @Person@ in Figure~\ref{f:EumeratorTyping}), so it is possible to have the equivalent of multiple arrays of companion data using an array of structures. While the enumeration type can be any C aggregate, the aggregate's \CFA constructors are \emph{not} used to evaluate an enumerator's value. @@ -164,5 +164,6 @@ bar( x ); $\C{// costs (1, 0, 0, 0, 0, 0, 0, 0) or (0, 1, 0, 0, 0, 0, 0, 0)}$ \end{cfa} -Here, candidate (1) has a value conversion cost to convert to the base type, while candidate (2) has an unsafe conversion from @double@ to @int@. +Here, the candidate (1) has a @value@ conversion cost to convert to the base type, while the candidate (2) has an @unsafe@ conversion from @double@ to @int@, +which is a more expensive conversion. Hence, @bar( x )@ resolves @x@ as type @Math@. @@ -177,21 +178,26 @@ -% \section{Auto Initialization} -% +\section{Auto Initialization} +\CFA implements auto-initialization for both C enumerations and \CFA enumerations. For the first category, the semantics is consistent with C: % A partially implemented feature is auto-initialization, which works for the C integral type with constant expressions. -% \begin{cfa} -% enum Week { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun }; // 0-2, 10-13 -% \end{cfa} +\begin{cfa} +enum Week { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun }; // 0-2, 10-13 +\end{cfa} % The complexity of the constant expression depends on the level of computation the compiler implements, \eg \CC \lstinline[language={[GNU]C++}]{constexpr} provides complex compile-time computation across multiple types, which blurs the compilation/runtime boundary. -% + % If \CFA had powerful compilation expression evaluation, auto initialization would be implemented as follows. -% \begin{cfa} -% enum E(T) { A, B, C }; -% \end{cfa} -% \begin{enumerate} -% \item the first enumerator, @A@, is initialized with @T@'s @zero_t@. -% \item otherwise, the next enumerator is initialized with the previous enumerator's value using operator @?++@, where @?++( T )@ can be overloaded for any type @T@. -% \end{enumerate} -% + +\begin{cfa} +struct S { int i; }; +S ?+?( S & s, one_t ) { return s.i++; } +void ?{}( S & s, zero_t ) { s.i = 0; } +enum(S) E { A, B, C, D }; +\end{cfa} +For \CFA enumeration, the semantics is the following: +\begin{enumerate} +\item the first enumerator, @A@, is initialized with @T@'s @zero_t@. +\item otherwise, the next enumerator is initialized with the previous enumerator's value using the operator @?+?(T, one_t)@, which can be overloaded for any type @T@. +\end{enumerate} + % Unfortunately, constant expressions in C are not powerful and \CFA is only a transpiler, relying on generated C code to perform the detail work. % It is currently beyond the scope of the \CFA project to implement a complex runtime interpreter in the transpiler to evaluate complex expressions across multiple builtin and user-defined type. @@ -219,5 +225,5 @@ bar( A ); $\C{// {\color{red}disallowed}}$ \end{cfa} -Hence, @Letter@ enumerators are not type compatible with the @Greek@ enumeration but the reverse is true. +Hence, @Letter@ enumerators are not type-compatible with the @Greek@ enumeration, but the reverse is true. @@ -241,10 +247,10 @@ 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 -from multiple enumeration that has overlapping enumerator label. As a consequence, a new type cannot inherits from both an enumeration and its supertype, or two enumerations with a -common supertype (the diamond problem), since such would unavoidably introduce duplicate enumerator labels. +However, the uniqueness of the enumeration name applies to enumerators, including those from supertypes, meaning an enumeration cannot name an enumerator with the same label as its subtype's members or inherits +from multiple enumeration that has overlapping enumerator labels. Consequently, a new type cannot inherit from an enumeration and its supertype or two enumerations with a +common supertype (the diamond problem) since such would unavoidably introduce duplicate enumerator labels. The base type must be consistent between subtype and supertype. -When an enumeration inherits enumerators from another enumeration, it copies the enumerators' @value@ and @label@, even if the @value@ is auto initialized. +When an enumeration inherits enumerators from another enumeration, it copies the enumerators' @value@ and @label@, even if the @value@ is auto-initialized. However, the position of the underlying representation is the order of the enumerator in the new enumeration. \begin{cfa} @@ -334,5 +340,5 @@ The algorithm takes two @CFAEnums@ parameters, @src@ and @dst@, with @src@ being the type of expression the conversion applies to, and @dst@ being the type the expression is cast to. The algorithm iterates over the members in @dst@ to find @src@. -If a member is an enumerator of @dst@, the positions of all subsequent members is increment by one. +If a member is an enumerator of @dst@, the positions of all subsequent members are incremented by one. If the current member is @dst@, the function returns true indicating \emph{found} and the accumulated offset. Otherwise, the algorithm recurses into the current @CFAEnum@ @m@ to check if its @src@ is convertible to @m@. @@ -467,5 +473,5 @@ \VRef[Figure]{f:EnumerationI/O} show \CFA enumeration input based on the enumerator labels. When the enumerator labels are packed together in the input stream, the input algorithm scans for the longest matching string. -For basic types in \CFA, the rule is that the same constants used to initialize a variable in a program are available to initialize a variable using input, where strings constants can be quoted or unquoted. +For basic types in \CFA, the rule is that the same constants used to initialize a variable in a program are available to initialize a variable using input, where string constants can be quoted or unquoted. \begin{figure} Index: doc/theses/jiada_liang_MMath/background.tex =================================================================== --- doc/theses/jiada_liang_MMath/background.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/background.tex (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -1,5 +1,5 @@ \chapter{Background} -This chapter covers background material for C enumerations and \CFA features used in later discussion. +This chapter covers background material for C enumerations and \CFA features used in later discussions. @@ -14,9 +14,9 @@ \begin{enumerate}[leftmargin=*] \item -For @#define@, the programmer has to explicitly manage the constant name and value. -Furthermore, these C preprocessor macro names are outside of the C type-system and can incorrectly change random text in a program. +For @#define@, the programmer must explicitly manage the constant name and value. +Furthermore, these C preprocessor macro names are outside the C type system and can incorrectly change random text in a program. \item The same explicit management is true for the @const@ declaration, and the @const@ variable cannot appear in constant-expression locations, like @case@ labels, array dimensions,\footnote{ -C allows variable-length array-declarations (VLA), so this case does work, but it fails in \CC, which does not support VLAs, unless it is \lstinline{g++}.} immediate oper\-ands of assembler instructions, and occupies storage. +C allows variable-length array declarations (VLA), so this case does work. Still, it fails in \CC, which does not support VLAs, unless it is \lstinline{g++}.} immediate oper\-ands of assembler instructions and occupies storage. \begin{clang} $\$$ nm test.o @@ -87,13 +87,13 @@ enum { Size = 20, Max = 10, MaxPlus10 = Max + 10, @Max10Plus1@, Fred = -7 }; \end{clang} -Here, the aliased constants are: 20, 10, 20, 21, and -7. -Direct initialization is by a compile-time expression generating a constant value. +Here, the aliased constants are 20, 10, 20, 21, and -7. +Direct initialization is achieved by a compile-time expression that generates a constant value. 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. +The enumerators are @rvalues@, so the assignment is disallowed. Finally, enumerators are \newterm{unscoped}, \ie enumerators declared inside of an @enum@ are visible (projected) outside into the enclosing scope of the @enum@ type. -For unnamed enumerations, this semantic is required because there is no type name for scoped qualification. - -As noted, this kind of aliasing declaration is not an enumeration, even though it is declared using an @enum@ in C. +This semantic is required for unnamed enumerations because there is no type name for scoped qualification. + +As noted, this aliasing declaration is not an enumeration, even though it is declared using an @enum@ in C. While the semantics is misleading, this enumeration form matches with aggregate types: \begin{cfa} @@ -121,5 +121,5 @@ }; \end{clang} -Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma.\footnote{ +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 allows enumerator lines to be interchanged without moving a comma. @@ -130,5 +130,5 @@ \label{s:CenumImplementation} -In theory, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerator values. +Theoretically, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerator values. In practice, C defines @int@~\cite[\S~6.4.4.3]{C11} as the underlying type for enumeration variables, restricting initialization to integral constants, which have type @int@ (unless qualified with a size suffix). However, type @int@ is defined as: @@ -137,7 +137,7 @@ \end{quote} 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. -Hence, initialization in the range @INT_MIN@..@INT_MAX@ results in a 4-byte enumerator, and outside this range the enumerator is 8 bytes. +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 on its initialization. +Hence, initialization in the range @INT_MIN@..@INT_MAX@ results in a 4-byte enumerator, and outside this range, the enumerator is 8 bytes. Note that @sizeof( typeof( IMin ) ) != sizeof( E )@, making the size of an enumerator different than is containing enumeration type, which seems inconsistent, \eg @sizeof( typeof( 3 ) ) == sizeof( int )@. @@ -168,5 +168,5 @@ \label{s:Usage} -C proves an implicit \emph{bidirectional} conversion between an enumeration and its integral type, and between two different enumerations. +C proves an implicit \emph{bidirectional} conversion between an enumeration and its integral type and between two different enumerations. \begin{clang} enum Week week = Mon; $\C{// week == 0}$ @@ -178,5 +178,5 @@ @week = Winter;@ $\C{// UNDEFINED! implicit conversion to Week}$ \end{clang} -While converting an enumerator to its underlying type is useful, the implicit conversion from the base or another enumeration type to an enumeration is a common source of error. +While converting an enumerator to its underlying type is sound, the implicit conversion from the base or another enumeration type to an enumeration is a common source of error. Enumerators can appear in @switch@ and looping statements. @@ -194,14 +194,14 @@ \end{cfa} For iterating using arithmetic to make sense, the enumerator values \emph{must} have a consecutive ordering with a fixed step between values. -For example, a previous gap introduced by @Thu = 10@, results in iterating over the values 0--13, where values 3--9 are not @Week@ values. -Note, it is the bidirectional conversion that allows incrementing @day@: @day@ is converted to @int@, integer @1@ is added, and the result is converted back to @Week@ for the assignment to @day@. +For example, a previous gap introduced by @Thu = 10@ results in iterating over the values 0--13, where values 3--9 are not @Week@ values. +Note that the bidirectional conversion allows incrementing @day@: @day@ is converted to @int@, integer @1@ is added, and the result is converted back to @Week@ for the assignment to @day@. For safety, \CC does not support the bidirectional conversion, and hence, an unsafe cast is necessary to increment @day@: @day = (Week)(day + 1)@. -There is a C idiom to automatically compute the number of enumerators in an enumeration. +There is a C idiom that computes the number of enumerators in an enumeration automatically. \begin{cfa} enum E { A, B, C, D, @N@ }; // N == 4 for ( enum E e = A; e < @N@; e += 1 ) ... \end{cfa} -Here, serendipitously the auto-incrementing counts the number of enumerators and puts the total into the last enumerator @N@. +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 associated with the enumeration. \begin{cfa} @@ -226,21 +226,21 @@ \end{cfa} However, the companion idiom results in the \emph{harmonizing} problem because an update to the enumeration @Integral_Type@ often requires a corresponding update to the companion array \snake{Integral_Name}. -The requirement to harmonize is at best indicated by a comment before the enumeration. +The requirement to harmonize is, at best, indicated by a comment before the enumeration. This issue is exacerbated if enumeration and companion array are in different translation units. \bigskip -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. +While C provides a true enumeration, it is restricted, has unsafe semantics, and does not provide helpful/advanced enumeration features in other programming languages. \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. +Other \CFA features are presented in situ with short or no explanation because the feature is obvious to C programmers. \subsection{Overloading} -Overloading allows programmers to use the most meaningful names without fear of name clashes within a program or from external sources, like include files. +Overloading allows programmers to use the most meaningful names without fear of name clashes within a program or from external sources like included files. \begin{quote} There are only two hard things in Computer Science: cache invalidation and naming things. --- Phil Karlton @@ -269,5 +269,5 @@ \subsection{Function Overloading} -Both \CFA and \CC allow function names to be overloaded, as long as their prototypes differ in the number and type of parameters and returns. +Both \CFA and \CC allow function names to be overloaded as long as their prototypes differ in the number and type of parameters and returns. \begin{cfa} void f( void ); $\C[1.75in]{// (1): no parameter}$ @@ -277,8 +277,8 @@ \end{cfa} In this case, the name @f@ is overloaded depending on the number and parameter types. -The type system examines each call size and selects the best match based on the number and types of the arguments. -Here, there is a perfect match for the call, @f( 'A' )@ with the number and parameter type of function (2). - -Ada, Scala, and \CFA type-systems also use the return type in resolving a call, to pinpoint the best overloaded name. +The type system examines each call size and selects the best match based on the number and types of arguments. +Here, the call @f( 'A' )@ is a perfect match for the number and parameter type of function (2). + +Ada, Scala, and \CFA type-systems also use the return type to pinpoint the best-overloaded name in resolving a call. \begin{cfa} int f( void ); $\C[1.75in]{// (4); overloaded on return type}$ @@ -302,5 +302,5 @@ } \end{cfa} -The \CFA type system simply treats overloaded variables as an overloaded function returning a value with no parameters. +The \CFA type system treats overloaded variables as an overloaded function returning a value with no parameters. Hence, no significant effort is required to support this feature. @@ -312,9 +312,9 @@ All objects in \CFA are initialized by @constructors@ \emph{after} allocation and de-initialized \emph{before} deallocation. -\CC cannot have constructors for basic-types because they have no aggregate type \lstinline[language=C++]{struct/class} in which to insert a constructor definition. +\CC cannot have constructors for basic types because they have no aggregate type \lstinline[language=C++]{struct/class} in which to insert a constructor definition. Like \CC, \CFA has multiple auto-generated constructors for every type. The prototype for the constructor/destructor are @void ?{}( T &, ... )@ and @void ^?{}( T &, ... )@, respectively. -The first parameter is logically the \lstinline[language=C++]{this} or \lstinline[language=Python]{self} in other object-oriented languages, and implicitly passed. +The first parameter is logically the \lstinline[language=C++]{this} or \lstinline[language=Python]{self} in other object-oriented languages and implicitly passed. \VRef[Figure]{f:CFAConstructorDestructor} shows an example of creating and using a constructor and destructor. Both constructor and destructor can be explicitly called to reuse a variable. @@ -350,5 +350,5 @@ The C constants @0@ and @1@ have special meaning. -@0@ is the null pointer and used in conditional expressions, where @if ( p )@ is rewritten @if ( p != 0 )@; +@0@ is the null pointer and is used in conditional expressions, where @if ( p )@ is rewritten @if ( p != 0 )@; @1@ is an additive identity in unary operators @++@ and @--@. Aware of their significance, \CFA provides a special type @zero_t@ and @one_t@ for custom types. @@ -385,5 +385,5 @@ bar( s ); \end{cfa} -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. +The assertion on @T@ restricts the range of types that can be manipulated by @bar@ to only those that implement @foo@ with the matching signature, allowing @bar@'s call to @foo@ in its body. 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. @@ -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 languages, like Go and Rust. +A common practice is refactoring the assertions into a named \newterm{trait}, similar to other languages like Go and Rust. \begin{cfa} forall(T) trait @Bird@ { @@ -407,5 +407,5 @@ bird_fly( 23, robin ); \end{cfa} -Grouping type assertions into a named trait effectively creates a reusable interface for parametric-polymorphic types. +Grouping type assertions into a named trait effectively creates a reusable interface for parametric polymorphic types. @@ -417,5 +417,5 @@ 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; +Finding an exact match is not discussed here, because the mechanism is fairly straightforward, even when the search space is ample; 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'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@. +otherwise, the program becomes littered with many explicit casts which do not match the programmer's expectations. +C is an aggressive language, providing conversions among almost all 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 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}. +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}. @@ -438,16 +438,16 @@ @poly@ is the number of polymorphic function parameters, and \item -@safe@ is sum of the degree of safe (widening) conversions. +@safe@ is the sum of the degree of safe (widening) conversions. \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 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. +For example, the distance from @char@ to @int@ is 2, from @int@ to @long@ is 1, and 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. +For example, the @char@ and @signed char@ ranks are the same in C, but the distance from @char@ to @signed char@ is assigned 1. @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 listed along: +Among the three costs in Bilson's model, @unsafe@ is the most significant cost, and @safe@ is the least significant, implying that \CFA always chooses a candidate with the lowest @unsafe@, if possible. + +For example, assume the overloaded function @foo@ is called with two @int@ parameters. +The cost for every overloaded @foo@ has been listed along with the following: \begin{cfa} void foo( char, char ); $\C[2.5in]{// (1) (2, 0, 0)}$ @@ -479,13 +479,13 @@ \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. -For every type assertion in @forall@ clause (no assertions in the above example), \CFA subtracts one from @specialization@. -More type assertions means more constraints on argument types, making the function less generic. +For every type assertion in the @forall@ clause (no assertions in the above example), \CFA subtracts one from @specialization@. +More type assertions mean more constraints on argument types, making the function less generic. \CFA defines two special cost values: @zero@ and @infinite@. -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. +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 the 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 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 a infinite conversion cost and a non-infinite cast cost. +For most cast-expression resolutions, a cast cost equals 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 as having an infinite conversion cost and a non-infinite cast cost. Index: doc/theses/jiada_liang_MMath/conclusion.tex =================================================================== --- doc/theses/jiada_liang_MMath/conclusion.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/conclusion.tex (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -50,7 +50,13 @@ enum( wchar_t * ) { Jack = L"John" }; \end{cfa} -\item -Currently enumeration scoping is all or nothing. -In some cases, it might be useful to increase the scoping granularity to individual enumerators. +There are several new features have been proposed or are developing in parallel with enumerations. +Two closely related features are iterator and namespace. + +Enumerating features, and range loops in particular, are currently implemented as loops unique to \CFA enumeration and do not align with the +general iterator pattern. They can be adapted to the iterator interface when it comes to maturity. + +Currently, \CFA implements a namespace feature for enumerated types only. There is recently a proposal by Andrew to +generalize the concept of namespace to other types. The enumeration scope will be revisited to follow the same semantics +as other types. Also to improve the granularity of scope control, we propose the following extension: \begin{cfa} enum E1 { @!@A, @^@B, C }; Index: doc/theses/jiada_liang_MMath/test.adb =================================================================== --- doc/theses/jiada_liang_MMath/test.adb (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/test.adb (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -2,6 +2,7 @@ -- with Ada.Standard; use Ada.Standard; procedure test is + type GBR is ( Green, Blue, Red ); type RGB is ( Red, Green, Blue ); - for RGB use ( Red => 10, Green => 20, Blue => 30 ); + for RGB use ( Red => 10, Green => 20, Blue => 21 ); Colour : RGB := Red; @@ -95,4 +96,10 @@ if B then null; end if; + + B := False; + Colour := Green; + + Put_Line ( Boolean'Image( B ) & " " ); + Put_Line ( RGB'Image( RGB'Enum_Val( 10 ) ) & " " ); end test; Index: doc/theses/jiada_liang_MMath/test.cc =================================================================== --- doc/theses/jiada_liang_MMath/test.cc (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/test.cc (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -61,5 +61,7 @@ eca[A] = EC::A; - enum Week { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun }; + enum Week { Mon, Tue, Wed, Thu = 10, Fri, Sat = 8, Sun }; + if ( Fri < Sat ) cout << "hmm" << endl; + else cout << "ahh" << std::endl; Week day = Mon; if ( day <= Fri ) cout << "weekday" << endl; Index: doc/theses/jiada_liang_MMath/test.go =================================================================== --- doc/theses/jiada_liang_MMath/test.go (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/test.go (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -20,10 +20,10 @@ -const ( R = 0; G = 3; B ) // implicit: 0 0 0 +const ( R = 0; G = 3; B = 3; TT = 3 ) // implicit: 0 3 3 const ( Fred = "Fred"; Mary = "Mary"; Jane = "Jane" ) // Fred Mary Jane const ( H = 0; Jack = "Jack"; J; K = 0; I ) // type change, implicit: 0 Jack Jack const ( C = iota + G; M = iota; Y ) const ( Mon = iota; Tue; Wed; // 0, 1, 2 - Thu = 10; Fri = iota - Wed + Thu - 1; Sat; Sun = iota ) // 10, 11, 12, 13 + Thu = 10; Fri = iota - Wed + Thu - 1; Sat; Sun = 0 ) // 10, 11, 12, 13 const ( O1 = iota + 1; _; O3; _; O5 ) // 1, 3, 5 const ( V1 = iota; V2; V3 = 7; V4 = iota + 1; V5 ) @@ -34,4 +34,5 @@ func main() { + fmt.Println( "Go:") if 3 == R {}; fmt.Println( R, G, B ) @@ -45,8 +46,10 @@ day := Mon; + day = Sun; + switch day { case Mon, Tue, Wed, Thu, Fri: fmt.Println( "weekday" ); - case Sat, Sun: + case Sat: fmt.Println( "weekend" ); } @@ -54,6 +57,6 @@ fmt.Println( i ) } + fmt.Println(B < TT); +} // main - var ar[Sun] int - ar[Mon] = 3 -} // main +// go build test.go Index: doc/theses/jiada_liang_MMath/test.pas =================================================================== --- doc/theses/jiada_liang_MMath/test.pas (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/test.pas (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -4,5 +4,7 @@ Weekday = Mon..Fri; Weekend = Sat..Sun; -type Count = ( Zero, One, Two, Ten = 10, Eleven ); +type Count = ( Zero, One, Two, Ten = 10, Eleven=10 ); +type RR = ( A, B, C ); + var day : Week; wday : Weekday; @@ -10,4 +12,16 @@ lunch : array[Week] of Integer; cnt : Count; +// procedure P1(v:Week); +// begin +// Writeln('Week'); +// end; +procedure P1(v:Weekday); +begin + Writeln('Weekday'); +end; +procedure P1(v:RR); +begin + Writeln('RR'); +end; begin day := Sat; @@ -40,4 +54,6 @@ Writeln(); for day := Mon to Sat do + lunch[day] := ord(day) * 10; + for day := Mon to Sun do Write( lunch[day], ' ' ); Writeln(); @@ -45,5 +61,12 @@ Write( ord( cnt ), ' ' ); end; + day := Tue; + P1( day ); Writeln(); + + case (day) of + Mon: writeln('Excellent!' ); + Tue: writeln('Well done' ); + end; end. Index: doc/theses/jiada_liang_MMath/test.py =================================================================== --- doc/theses/jiada_liang_MMath/test.py (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/test.py (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -25,5 +25,5 @@ # Mon = 1; Tue = 2; Wed = 3; Thu = 10; Fri = 10; Sat = 16; Sun = 17 class Week(OrderedEnum): - Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 7 + Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 0 def isWeekday(self): return Week(self.value) <= Week.Fri @@ -34,21 +34,21 @@ return cls(date.isoweekday()) -day : Week = Week.Tue; +day : Week = Week.Tue print( "weekday:", day.isWeekday() ) print( "weekend:", day.isWeekend() ) print( "today:", Week.today(date.today())) -print( Week.Thu.value == 4 ); -print( Week.Thu.name == "Thu" ); -print( Week( 4 ) == Week.Thu ); -print( Week["Thu"].value == 4 ); +print( Week.Thu.value == 4 ) +print( Week.Thu.name == "Thu" ) +print( Week( 4 ) == Week.Thu ) +print( Week["Thu"].value == 4 ) if day <= Week.Fri : - print( "weekday" ); + print( "weekday" ) match day: case Week.Mon | Week.Tue | Week.Wed | Week.Thu | Week.Fri: - print( "weekday" ); + print( "weekday" ) case Week.Sat | Week.Sun: - print( "weekend" ); + print( "weekend" ) for day in Week: @@ -80,5 +80,5 @@ print( isinstance(Week.Fri, Week) ) -class WeekE(OrderedEnum): pass; +class WeekE(OrderedEnum): pass class WeekDay(WeekE): Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; class WeekEnd(WeekE): Sat = 6; Sun = 7 @@ -121,5 +121,5 @@ Weekend = Sat | Sun print( f"0x{repr(WeekF.Weekday.value)} 0x{repr(WeekF.Weekend.value)}" ) -day : WeekF = WeekF.Mon | WeekF.Tue; +day : WeekF = WeekF.Mon | WeekF.Tue print( type(day) ) for day in WeekF: @@ -164,9 +164,9 @@ match diffval: case Diff.Int: - print( "diffval", diffval.value ); + print( "diffval", diffval.value ) case Diff.Float: - print( "diffval", diffval.value ); + print( "diffval", diffval.value ) case Diff.Str: - print( "diffval", diffval.value ); + print( "diffval", diffval.value ) for i in Diff: print( f"Diff type {type(i)}, {i}, {i.name}, {i.value} : " ) @@ -197,8 +197,12 @@ return G * self.mass / (self.radius * self.radius) def surfaceWeight(self, otherMass): - return otherMass * self.surfaceGravity(); + return otherMass * self.surfaceGravity() + +class Cats(Enum): + pass + earthWeight : float = 100 -earthMass : float = earthWeight / ( Planet.EARTH.surfaceGravity() ); +earthMass : float = earthWeight / ( Planet.EARTH.surfaceGravity() ) p = by_position( Planet, random.randrange(8) ) # select a random orbiting body Index: doc/theses/jiada_liang_MMath/test.swift =================================================================== --- doc/theses/jiada_liang_MMath/test.swift (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/test.swift (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -59,5 +59,5 @@ enum WeekInt: Int, CaseIterable { - case Mon, Tue, Wed, Thu = 10, Fri, + case Mon, Tue, Wed, Thu = 10, Fri = 14, Sat = 4, Sun // auto-incrementing }; Index: doc/theses/jiada_liang_MMath/test1.java =================================================================== --- doc/theses/jiada_liang_MMath/test1.java (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) +++ doc/theses/jiada_liang_MMath/test1.java (revision 7568e5ca6e5718e97f473656ac2d190bb2a13f6a) @@ -3,5 +3,5 @@ public class test1 { enum Weekday { - Mon(7), Tue(6), Wed(5), Thu(3), Fri(3), Sat(3), Sun(1); // must appear first + Mon(7), Tue(6), Wed(5), Thu(3), Fri(4), Sat(3), Sun(7); // must appear first private long day; private Weekday( long d ) { day = d; } @@ -27,7 +27,11 @@ } for ( Weekday icday : Weekday.values() ) { // position - System.out.print( icday + " " + icday.ordinal() + " " + icday.day + " " + icday.name() + ", " ); // label + System.out.println( icday + " " + icday.ordinal() + " " + icday.day + " " + icday.name() + ", " ); // label } System.out.println(); + + if (Weekday.Fri == Weekday.Sat) { + System.out.println( "Alias "); + } } }