Changeset acab1bd

Timestamp:

Aug 8, 2024, 11:19:51 PM (4 weeks ago)

Author:

JiadaL <j82liang@…>

Branches:

master

Children:

26d40a1, f125e96

Parents:

7568e5c

Message:

rephrase enum initialization

Location:

doc/theses/jiada_liang_MMath

Files:

• CFAenum.tex (modified) (2 diffs)
• conclusion.tex (modified) (2 diffs)

doc/theses/jiada_liang_MMath/CFAenum.tex

@@ -179 +179 @@
 
 \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}
-% 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.
+\CFA extends C's auto-initialization scheme to \CFA enumeration. For an enumeration type with base type T, the initialization scheme is the following:
+\begin{enumerate}
+\item the first enumerator is initialized with @T@'s @zero_t@.
+\item Every other enumerator is initialized with its previous enumerator's value "+1", where "+1" is defined in terms of overloaded operator @?+?(T, one_t)@.
+\end{enumerate}
 
 \begin{cfa}
@@ -194 +191 @@
 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. 
-% Nevertheless, the necessary language concepts exist to support this feature.
-
 
 \section{Subset}

doc/theses/jiada_liang_MMath/conclusion.tex

@@ -31 +31 @@
 It should be possible to have this file included implicitly by updating the \CFA prelude.
 \item
-There are multiple \CFA features being developed i parallel with enumerations.
+There are multiple \CFA features being developed in parallel with enumerations.
 Two closely related features are iterator and namespace.
 Enumerations may have to be modified to dovetail with these features.
@@ -50 +50 @@
 enum( wchar_t * ) { Jack = L"John" };
 \end{cfa}
-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:
+\item
+Currently enumeration scoping is all or nothing. In some cases, it might be useful to
+increase the scoping granularity to individual enumerators.
 \begin{cfa}
 enum E1 { @!@A, @^@B, C };