Context Navigation

-                      r6a8c773
+                      r41fb996
 \chapter{Introduction}
 All types in a programming language must have a set of constants, and these constants have primary names, \eg integral types have constants @-1@, @17@, @12345@, \etc.
+All types in a programming language must have a set of constants, and these constants have \Newterm{primary names}, \eg integral types have constants @-1@, @17@, @12345@, \etc.
 Constants can be overloaded among types, \eg @0@ is a null pointer for all pointer types, and the value zero for integral and floating-point types.
 Hence, each primary constant has a symbolic name referring to its internal representation, and these names are dictated by language syntax related to types.
 In theory, there are an infinite set of primary names per type.
 Secondary naming is a common practice in mathematics and engineering, \eg $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), MHz (1E6), and in general situations, \eg specific times (noon, New Years), cities (Big Apple), flowers (Lily), \etc.
+\Newterm{Secondary naming} is a common practice in mathematics and engineering, \eg $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), MHz (1E6), and in general situations, \eg specific times (noon, New Years), cities (Big Apple), flowers (Lily), \etc.
 Many programming languages capture this important software-engineering capability through a mechanism called \Newterm{constant} or \Newterm{literal} naming, where a secondary name is aliased to a primary name.
 In some cases, secondary naming is \Newterm{pure}, where the matching internal representation can be chosen arbitrarily, and only equality operations are available, \eg @O_RDONLY@, @O_WRONLY@, @O_CREAT@, @O_TRUNC@, @O_APPEND@.
+(The names the thing.)
 Because a secondary 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.}.
 …
 to specify as in a list or catalogue.~\cite{OED}
 \end{quote}
 Within an enumeration set, the enumeration names must be unique, and instances of an enumerated type are restricted to its secondary names.
+Within an enumeration set, the enumeration names must be unique, and instances of an enumerated type are restricted to hold only the secondary names.
 It is possible to enumerate among set names without having an ordering among the set elements.
 For example, the week, the weekdays, the weekend, and every second day of the week.
 …
 \it\color{red}enumeration       & \multicolumn{8}{c}{\it\color{red}enumerators} \\
 $\downarrow$\hspace*{25pt}      & \multicolumn{8}{c}{$\downarrow$}                              \\
 @enum@ Weekday \{                       & Mon,  & Tue,  & Wed,  & Thu,  & Fri,  & Sat,  & Sun = 42      & \};   \\
+@enum@ Week \{                          & Mon,  & Tue,  & Wed,  & Thu,  & Fri,  & Sat,  & Sun = 42      & \};   \\
 \it\color{red}label                     & Mon   & Tue   & Wed   & Thu   & Fri   & Sat   & Sun           &               \\
 \it\color{red}order                     & 0             & 1             & 2             & 3             & 4             & 5             & 6                     &               \\
 …
 \end{tabular}
 \end{cquote}
 Here, the enumeration @Weekday@ defines the enumerator labels @Mon@, @Tue@, @Wed@, @Thu@, @Fri@, @Sat@ and @Sun@.
+Here, the enumeration @Week@ defines the enumerator labels @Mon@, @Tue@, @Wed@, @Thu@, @Fri@, @Sat@ and @Sun@.
 The implicit ordering implies the successor of @Tue@ is @Mon@ and the predecessor of @Tue@ is @Wed@, independent of any associated enumerator values.
 The value is the constant represented by the secondary name, which can be implicitly or explicitly set.
 …
 Hence, a variant is dynamically typed, as in a dynamic-typed programming-language, but the set of types is statically bound, similar to some aspects of dynamic gradual-typing~\cite{Gradual Typing}.
 Knowing which type is in a variant instance is crucial for correctness.
 Occasionally, it is possible to statically determine, all regions where each variant type is used, so a tag and runtime checking is unnecessary;
+Occasionally, it is possible to statically determine all regions where each variant type is used, so a tag and runtime checking is unnecessary;
 otherwise, a tag is required to denote the particular type in the variant and the tag checked at runtime using some form of type pattern-matching.
 …
 For safety, either all variant types must be listed or a @default@ case must exist with no field accesses.
 To simulate an enumeration with a variant, the tag is re-purposed for either ordering or value and the variant types are omitted.
+To simulate an enumeration with a variant, the tag is \emph{re-purposed} for either ordering or value and the variant types are omitted.
 \begin{cfa}
 variant Weekday {
 …
 };
 \end{cfa}
 The type system ensures tag setting and testing are correct.
+The type system ensures tag setting and testing are correctly done.
 However, the enumeration operations are limited to the available tag operations, \eg pattern matching.
 \begin{cfa}
 Weekday weekday = Mon;
 if ( @dynamic_cast(Mon)@weekday ) ... // test tag == Mon
+Week week = Mon;
+if ( @dynamic_cast(Mon)@week ) ... // test tag == Mon
 \end{cfa}
 While enumerating among tag names is possible:
 …
 However, if a special @enum@ variant allows the tags to be heterogeneously typed, ordering must fall back on case positioning, as many types have incomparable values.
 Iterating using tag ordering and heterogeneous types, also requires pattern matching.
 \begin{cfa}
+\begin{cfa}[morekeywords={match}]
 for ( cursor = Mon; cursor <= Fri; cursor = succ( cursor) ) {
         switch( cursor ) {
+        match( cursor ) {
                 case Mon { /* access special type for Mon */ }
                 ...
                 case Fri { /* access special type for Fri */ }
+                default
+        }
+}
 \end{cfa}
 If the variant type adds/removes types or the loop range changes, the pattern matching must be adjusted.
 As well, if the start/stop values are dynamic, it is impossible to statically determine if all variant types are listed.
+If the variant type is changed by adding/removing types or the loop range changes, the pattern matching must be adjusted.
+As well, if the start/stop values are dynamic, it may be impossible to statically determine if all variant types are listed.
 Forcing the notion of enumerating into variant types is ill formed and confusing.
+Re-purposing the notion of enumerating into variant types is ill formed and confusing.
 Hence, there is only a weak equivalence between an enumeration and variant type, justifying the enumeration type in a programming language.
 …
 The goal of this work is to to extend the simple and unsafe enumeration type in the C programming-language into a sophisticated and safe type in the \CFA programming-language, while maintain backwards compatibility with C.
 On the surface, enumerations seem like a simple type.
 However, when extended with advanced features, enumerations become complex for both the type system and the implementation.
+However, when extended with advanced features, enumerations become complex for both the type system and the runtime implementation.
 \begin{enumerate}

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 41fb996 for doc/theses/jiada_liang_MMath/intro.tex

Legend:

doc/theses/jiada_liang_MMath/intro.tex

Download in other formats: