Index: doc/theses/jiada_liang_MMath/intro.tex =================================================================== --- doc/theses/jiada_liang_MMath/intro.tex (revision 3eb5f993072b2c8d360d6702d2e3b9b026262628) +++ doc/theses/jiada_liang_MMath/intro.tex (revision 4c8f29ff2e86251e35ad101e72e33e8514c571d4) @@ -8,5 +8,5 @@ In theory, there are 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. +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. An alias can bind to another alias, which transitively binds it to the specified constant. Multiple aliases can represent the same value, \eg eighth note and quaver, giving synonyms. @@ -80,5 +80,5 @@ \end{tabular} \end{cquote} -Here, the enumeration @Week@ defines the enumerator constant @Mon@, @Tue@, @Wed@, @Thu@, @Fri@, @Sat@ and @Sun@. +Here, the enumeration @Week@ defines the enumerator constants @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 implicitly/explicitly assigned constant to support any enumeration operations; @@ -204,8 +204,8 @@ \begin{cfa} void foo( void ); -struct unit {} u; // empty type +struct unit {} u; $\C[1.5in]{// empty type}$ unit bar( unit ); -foo( foo() ); // void argument does not match with void parameter -bar( bar( u ) ); // unit argument does match with unit parameter +foo( foo() ); $\C{// void argument does not match with void parameter}$ +bar( bar( u ) ); $\C{// unit argument does match with unit parameter}\CRT$ \end{cfa} @@ -252,5 +252,5 @@ The key observation is the dichotomy between an ADT and enumeration: the ADT uses the associated type resulting in a union-like data structure, and the enumeration does not use the associated type, and hence, is not a union. -While the enumeration is constructed using the ADT mechanism, it is so restricted it is not an ADT. +While an enumeration is constructed using the ADT mechanism, it is so restricted it is not an ADT. Furthermore, a general ADT cannot be an enumeration because the constructors generate different values making enumerating meaningless. While functional programming languages regularly repurpose the ADT type into an enumeration type, this process seems contrived and confusing. @@ -277,2 +277,74 @@ inheritance \end{enumerate} + + +\begin{comment} +Date: Wed, 1 May 2024 13:41:58 -0400 +Subject: Re: Enumeration +To: "Peter A. Buhr" +From: Gregor Richards + +I think I have only one comment and one philosophical quibble to make: + +Comment: I really can't agree with putting MB in the same category as the +others. MB is both a quantity and a unit, and the suggestion that MB *is* one +million evokes the rather disgusting comparison 1MB = 1000km. Unit types are +not in the scope of this work. + +Philosophical quibble: Pi *is* 3.14159...etc. Monday is not 0; associating +Monday with 0 is just a consequence of the language. The way this is written +suggests that the intentional part is subordinate to the implementation detail, +which seems backwards to me. Calling the number "primary" and the name +"secondary" feels like you're looking out from inside of the compiler, instead +of looking at the language from the outside. And, calling secondary values +without visible primary values "opaque"-which yes, I realize is my own term +;)-suggests that you insist that the primary value is a part of the design, or +at least mental model, of the program. Although as a practical matter there is +some system value associated with the constructor/tag of an ADT, that value is +not part of the mental model, and so calling it "primary" and calling the name +"secondary" and "opaque" seems either (a) very odd or (b) very C-biased. Or +both. + +With valediction, + - Gregor Richards + + +Date: Thu, 30 May 2024 23:15:23 -0400 +Subject: Re: Meaning? +To: "Peter A. Buhr" +CC: , +From: Gregor Richards + +I have to disagree with this being agreeing to disagree, since we agree +here. My core point was that it doesn't matter whether you enumerate over the +names or the values. This is a distinction without a difference in any case +that matters. If any of the various ways of looking at it are actually +different from each other, then that's because the enumeration has failed to be +an enumeration in some other way, not because of the actual process of +enumeration. Your flag enum is a 1-to-1 map of names and values, so whether you +walk through names or walk through values is not an actual distinction. It +could be distinct in the *order* that it walks through, but that doesn't +actually matter, it's just a choice that has to be made. Walking through entire +range of machine values, including ones that aren't part of the enumeration, +would be bizarre in any case. + +Writing these out has crystallized some thoughts, albeit perhaps not in a way +that's any help to y'all. An enumeration is a set of names; ideally an ordered +set of names. The state of enumerations in programming languages muddies things +because they often expose the machine value underlying those names, resulting +in a possibly ordered set of names and a definitely ordered set of values. And, +muddying things further, because those underlying values are exposed, enums are +used in ways that *depend* on the underlying values being exposed, making that +a part of the definition. But, an enumeration is conceptually just *one* set, +not both. So much of the difficulty is that you're trying to find a way to make +a concept that should be a single set agree with an implementation that's two +sets. If those sets have a 1-to-1 mapping, then who cares, they're just +aliases. It's the possibility of the map being surjective (having multiple +names for the same underlying values) that breaks everything. Personally, I +think that an enum with aliases isn't an enumeration anyway, so who cares about +the rest; if you're not wearing the gourd as a shoe, then it's not an +enumeration. + +With valediction, + - Gregor Richards +\end{comment}