Changeset c4aca65 for doc/theses

Timestamp:

Aug 8, 2024, 5:25:41 PM (4 months ago)

Author:

JiadaL <j82liang@…>

Branches:

master

Children:

11cced6

Parents:

ab11ab1

Message:

Move partial scope to future work

Location:

doc/theses/jiada_liang_MMath

Files:

• Cenum.tex (modified) (4 diffs)
• conclusion.tex (modified) (3 diffs)

doc/theses/jiada_liang_MMath/Cenum.tex

@@ -1 +1 @@
 \chapter{C Enumeration in \texorpdfstring{\CFA}{Cforall}}
 
-\CFA supports legacy C enumeration using the same syntax for backwards compatibility.
+\CFA supports legacy C enumeration using the same syntax for backward compatibility.
 A C-style enumeration in \CFA is called a \newterm{C Enum}.
 The semantics of the C Enum is mostly consistent with C with some restrictions.
@@ -15 +15 @@
 enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
 \end{cfa}
-There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible if the conflict comes from system include files.
+There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible if the conflict comes from system-include files.
 
 The \CFA type-system allows extensive overloading, including enumerators.
 Hence, most ambiguities among C enumerators are implicitly resolved by the \CFA type system, possibly without any programmer knowledge of the conflict.
-In addition, C Enum qualification is added, exactly like aggregate field-qualification, to disambiguate.
+In addition, C Enum qualification is added, exactly like aggregate field qualification, to disambiguate.
 \VRef[Figure]{f:EnumeratorVisibility} shows how resolution, qualification, and casting are used to disambiguate situations for enumerations @E1@ and @E2@.
 
@@ -66 +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.
 
-A partially implemented extension to enumerator scoping is providing a combination of scoped and unscoped enumerators, using individual denotations, where @'^'@ means unscoped.
-\begin{cfa}
-enum E1 { @!@A, @^@B, C };
-enum E2 @!@ { @!@A, @^@B, C };
-\end{cfa}
-For @E1@, @A@ is scoped; @B@ and @C@ are unscoped.
-For @E2@, @A@ and @C@ are scoped; @B@ is unscoped.
-Finding a use case is important to justify completing this extension.
-
 
 \section{Type Safety}
@@ -80 +71 @@
 As in Section~\ref{s:Usage}, C's implicit bidirectional conversion between enumeration and integral type raises a safety concern.
 In \CFA, the conversion is changed to unidirectional: an enumeration can be implicitly converted into an integral type, with an associated @safe@ conversion cost.
-But an integral type cannot be implicitly converted into a C enumeration because the conversion cost is set to @infinity@.
+However, an integral type cannot be implicitly converted into a C enumeration because the conversion cost is set to @infinity@.
 \begin{cfa}
 enum Bird { Penguin, Robin, Eagle };

doc/theses/jiada_liang_MMath/conclusion.tex

@@ -2 +2 @@
 \label{c:conclusion}
 
-The goal of this work is to extend 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 goal of this work is to extend 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 backward compatibility with C.
 Within this goal, the new \CFA enumeration should align with the analogous enumeration features in other languages to match modern programming expectations.
 Hence, the \CFA enumeration features are borrowed from a number of programming languages, but engineered to work and play with \CFA's type system and feature set.
 
-Additional safety is provided by strong type-checking of enumeration initialization and assignment, ensuring an enumeration only contains its enumerators.
+Strong type-checking of enumeration initialization and assignment provides additional safety, ensuring an enumeration only contains its enumerators.
 Overloading and scoping of enumerators significantly reduces the naming problem, providing a better software-engineering environment, with fewer name clashes and the ability to disambiguate those that cannot be implicitly resolved.
 Typed enumerations solve the data-harmonization problem increasing safety through better software engineering.
-As well, integrating enumerations with existing control structures provides a consistent upgrade for programmers, and a succinct and secure mechanism to enumerate with the new loop-range feature.
+Moreover, integrating enumerations with existing control structures provides a consistent upgrade for programmers and a succinct and secure mechanism to enumerate with the new loop-range feature.
 Generalization and reuse are supported by incorporating the new enumeration type using the \CFA trait system.
 Enumeration traits define the meaning of an enumeration, allowing functions to be written that work on any enumeration, such as the reading and printing an enumeration.
 Using advanced duck typing, existing C enumerations can be extended so they work with all of the enumeration features, providing for legacy C code to be moved forward into the modern \CFA programming domain.
-Finally, I expanded the \CFA project's test-suite with multiple enumeration features tests, with respect to implicit conversions, control structures, inheritance, interaction with the polymorphic types, and the features built on top of enumeration traits.
-These tests ensure future \CFA work does not accidently break the new enumeration system.
+Finally, I expanded the \CFA project's test suite with multiple enumeration features tests with respect to implicit conversions, control structures, inheritance, interaction with the polymorphic types, and the features built on top of enumeration traits.
+These tests ensure future \CFA work does not accidentally break the new enumeration system.
 
-The conclusion is that the new \CFA enumeration mechanisms achieves the initial goals, providing C programmers with an intuitive enumeration mechanism for handling modern programming requirements.
+The conclusion is that the new \CFA enumeration mechanisms achieve the initial goals, providing C programmers with an intuitive enumeration mechanism for handling modern programming requirements.
 
 
@@ -22 +22 @@
 
 There are still corner cases being found in the current \CFA enumeration implementation.
-Fixing some of these corner cases, requires changes to the \CFA resolver or extensions to \CFA, like compile-time constant-expression evaluation.
+Fixing some of these corner cases requires changes to the \CFA resolver or extensions to \CFA, like compile-time constant-expression evaluation.
 When these changes are made, it should be straightforward to update the \CFA enumeration implementation to work with them.
 
-Currently, some aspects of the enumeration trait system require explicitly including file @enum.hfa@, which easily leads to problems.
+Currently, some aspects of the enumeration trait system require explicitly including the file @enum.hfa@, which can lead to problems.
 It should be possible to have this file included implicitly by updating the \CFA prelude.
 
@@ -42 +42 @@
 enum( wchar_t * ) { Jack = L"John" };
 \end{cfa}
-The enumerating feature was developed in parallel with the \CFA iterator. In the forseeable future when iterator come to matuity, \CFA enumeration can adapt iterator-related traits and 
-be rewritten with iterator. 
+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 semantics 
+with other types. Also to improve the granularity of scope control, we propose the following extension:
+\begin{cfa}
+enum E1 { @!@A, @^@B, C };
+enum E2 @!@ { @!@A, @^@B, C };
+\end{cfa}
+which provides a combination of scoped and unscoped enumerators.
+For @E1@, @A@ is scoped; @B@ and @C@ are unscoped.
+For @E2@, @A@, and @C@ are scoped; @B@ is unscoped.
+Finding a use case is important to justify completing this extension.