Changeset 7ab24fef for doc


Ignore:
Timestamp:
Aug 4, 2024, 2:35:13 PM (3 months ago)
Author:
JiadaL <j82liang@…>
Branches:
master
Children:
2514d3d7, 5f210c0
Parents:
b59c21a (diff), 748877f (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

Location:
doc/theses/jiada_liang_MMath
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/jiada_liang_MMath/CEnum.tex

    rb59c21a r7ab24fef  
    1 \chapter{C Enumeration in CFA}
     1\chapter{C Enumeration in \CFA}
    22
    33\CFA supports legacy C enumeration using the same syntax for backwards compatibility.
    4 C-style Enumeration in \CFA language are called \newterm{C Enumeration} or \newterm{C Enum}.
    5 The semantics of C Enumeration is mostly consistent with C with more restrictive typing.
    6 \CFA also extends C Enumeration by adding a number of new features that bring enumerations aligns with other modern programming languages.
    7 Any enumeration extensions must be intuitive to C programmers both in syntax and semantics.
    8 The following sections detail all of my new contributions to enumerations in \CFA.
     4A C-style enumeration in \CFA is called a \newterm{C Enum}.
     5The semantics of the C Enum is mostly consistent with C with some restrictions.
     6The following sections detail all of my new contributions to C Enums.
     7
    98
    109\section{Enumerator Visibility}
     
    1211
    1312In C, unscoped enumerators present a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
     13\begin{cfa}
     14enum E1 { First, Second, Third, Fourth };
     15enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
     16\end{cfa}
    1417There 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.
    1518
    1619The \CFA type-system allows extensive overloading, including enumerators.
    17 Furthermore, \CFA uses the environment, such as the left-hand of assignment and function arguments, to pinpoint the best overloaded name.
    18 \VRef[Figure]{f:EnumeratorVisibility} shows enumeration overloading and how qualification and casting are used to disambiguate ambiguous situations.
    19 \CFA overloading allows programmers to use the most meaningful names without fear of name clashes within a program or from external sources, like include files.
    20 Experience from \CFA developers is that the type system implicitly and correctly disambiguates the majority of overloaded names.
    21 That is, it is rare to get an incorrect selection or ambiguity, even among hundreds of overloaded variables and functions, that requires disambiguation using qualification or casting.
     20Hence, most ambiguities among C enumerators are implicitly resolved by the \CFA type system, possibly without any programmer knowledge of the conflict.
     21In addition, C Enum qualification is added, exactly like aggregate field-qualification, to disambiguate.
     22\VRef[Figure]{f:EnumeratorVisibility} shows how resolution, qualification, and casting are used to disambiguate situations for enumerations @E1@ and @E2@.
    2223
    2324\begin{figure}
    2425\begin{cfa}
    25 enum E1 { First, Second, Third, Fourth };
    26 enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
    2726E1 f() { return Third; }                                $\C{// overload functions with different return types}$
    2827E2 f() { return Fourth; }
     
    4241\end{figure}
    4342
    44 \CFA overloading allows programmers to use the most meaningful names without fear of name clashes within a program or from external sources, like include files.
    45 Experience from \CFA developers is that the type system implicitly and correctly disambiguates the majority of overloaded names, \ie it is rare to get an incorrect selection or ambiguity, even among hundreds of overloaded variables and functions.
    46 Any ambiguity can be resolved using qualification or casting.
    47 
    4843
    4944\section{Enumerator Scoping}
    5045
    51 An enumeration can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope.
     46A C Enum can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope.
    5247\begin{cfa}
    5348enum Week @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun };
     
    6156rgb = @RGB.@Blue;
    6257\end{cfa}
    63 {\color{red}@***@}It is possible to toggle back to unscoped using the \CFA @with@ clause/statement (see also \CC \lstinline[language=c++]{using enum} in Section~\ref{s:C++RelatedWork}).
     58% feature unimplemented
     59It is possible to toggle back to unscoped using the \CFA @with@ auto-qualification clause/statement (see also \CC \lstinline[language=c++]{using enum} in Section~\ref{s:C++RelatedWork}).
    6460\begin{cfa}
    6561with ( @Week@, @RGB@ ) {                                $\C{// type names}$
     
    7066As in Section~\ref{s:EnumeratorVisibility}, 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.
    7167
     68
    7269\section{Type Safety}
    7370
    7471As in Section~\ref{s:Usage}, C's implicit bidirectional conversion between enumeration and integral type raises a safety concern.
    75 In \CFA, the conversion is unidirectional:
    76 % disallows an implicit conversion from integral type to enumeration, and conversion between different C enumeration type.
    77 % It loses some degree of its backward compatibility to C, in exchange for type safety.
    78 an enumeration can be implicitly converted into an integral type, with an associated @safe@ conversion cost.
    79 But an integral type cannot be implicitly converted into a C enumeration. (Conversion Cost is Infinity.)
     72In \CFA, the conversion is changed to unidirectional: an enumeration can be implicitly converted into an integral type, with an associated @safe@ conversion cost.
     73But an integral type cannot be implicitly converted into a C enumeration because the conversion cost is set to @infinity@.
    8074\begin{cfa}
    81 enum Bird { Pengin, Robin, Eagle };
     75enum Bird { Penguin, Robin, Eagle };
    8276enum Fish { Shark, Salmon, Whale };
    8377
    84 int i = Robin; $\C{// Allow, implicitly converts to 1}$
    85 @enum Bird bird = Shark;@ $\C{// Disallow }$
    86 @enum Bird bird = 1;@  $\C{// Disallow }$
     78int i = Robin;                                                  $\C{// allow, implicitly converts to 1}$
     79enum Bird @bird = 1;@                                   $\C{// disallow }$
     80enum Bird @bird = Shark;@                               $\C{// disallow }$
    8781\end{cfa}
    88 As a workaround, \CFA allows an explicit cast to an enumeration, turning an integral type to an enumeration that can be used in assignment or function argument,
    89 in which case \CFA treats C enuemration as its underlying integral type. In such cases, it is up to user to ensure program correctness.
     82It is now up to the programmer to insert an explicit cast to force the assignment.
    9083\begin{cfa}
    91 @enum Bird bird = (Bird) Shark@
    92 @enum Bird bird = (Bird) 1;@
     84enum Bird bird = @(Bird)@1;
     85enum Bird bird = @(Bird)@Shark
    9386\end{cfa}
     87
     88Note, \CC has the same safe restriction~\cite[C.1.5.7.2]{C++} and provides the same workaround cast.
     89\begin{description}[parsep=0pt]
     90\item[Change:] \CC objects of enumeration type can only be assigned values of the same enumeration type.
     91In C, objects of enumeration type can be assigned values of any integral type.
     92Example:
     93\begin{cfa}
     94enum color { red, blue, green };
     95color c = 1;                            $\C{// valid C, invalid \CC}$
     96\end{cfa}
     97\item[Rationale:] The type-safe nature of \CC.
     98\item[Effect on original feature:] Deletion of semantically well-defined feature.
     99\item[Difficulty of converting:] Syntactic transformation. (The type error produced by the assignment can be
     100automatically corrected by applying an explicit cast.)
     101\item[How widely used:] Common.
     102\end{description}
     103
     104\begin{comment}
     105\begin{description}[parsep=0pt]
     106\item[Change:] In \CC, the type of an enumerator is its enumeration.
     107In C, the type of an enumerator is @int@.
     108Example:
     109\begin{cfa}
     110enum e { A };
     111sizeof(A) == sizeof(int)        $\C{// in C}$
     112sizeof(A) == sizeof(e)          $\C{// in \CC}$
     113/* and sizeof(int) is not necessary equal to sizeof(e) */
     114\end{cfa}
     115\item[Rationale:] In \CC, an enumeration is a distinct type.
     116\item[Effect on original feature:] Change to semantics of well-defined feature.
     117\item[Difficulty of converting:] Semantic transformation.
     118\item[How widely used:] Seldom. The only time this affects existing C code is when the size of an enumerator is
     119taken. Taking the size of an enumerator is not a common C coding practice.
     120\end{description}
     121\end{comment}
  • doc/theses/jiada_liang_MMath/background.tex

    rb59c21a r7ab24fef  
    240240\section{\CFA}
    241241
    242 \CFA in \emph{not} an object-oriented programming-language, \ie functions cannot be nested in aggregate types, and hence, there is no receive notation for calling functions, \eg @obj.method(...)@, where the first argument proceeds the call.
    243 The following section provide short descriptions of \CFA features mentioned further in the thesis.
     242\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.
     243The following sections provide short descriptions of \CFA features needed further in the thesis.
     244Other \CFA features are presented in-situ with short explanations, or no explanation because the feature is obvious to C programmers.
     245
     246
     247\subsection{Overloading}
     248
     249Overloading allows programmers to use the most meaningful names without fear of name clashes within a program or from external sources, like include files.
     250\begin{quote}
     251There are only two hard things in Computer Science: cache invalidation and naming things. --- Phil Karlton
     252\end{quote}
     253Experience from \CC and \CFA developers is that the type system implicitly and correctly disambiguates the majority of overloaded names, \ie it is rare to get an incorrect selection or ambiguity, even among hundreds of overloaded (variables and) functions.
     254In many cases, a programmer has no idea there are name clashes, as they are silently resolved, simplifying the development process.
     255Depending on the language, ambiguous cases are resolved using some form of qualification or casting.
    244256
    245257
     
    273285Here, there is a perfect match for the call, @f( 'A' )@ with the number and parameter type of function (2).
    274286
    275 Ada, Scala, and \CFA type-systems also use the return type in resolving a call.
     287Ada, Scala, and \CFA type-systems also use the return type in resolving a call, to pinpoint the best overloaded name.
    276288\begin{cfa}
    277289int f( void );                  $\C[1.75in]{// (4); overloaded on return type}$
     
    296308\end{cfa}
    297309The \CFA type system simply treats overloaded variables as an overloaded function returning a value with no parameters.
     310Hence, no significant effort is required to support this feature.
    298311
    299312
     
    308321
    309322The prototype for the constructor/destructor are @void ?{}( T &, ... )@ and @void ^?{}( T &, ... )@, respectively.
    310 The first parameter is logically, the \lstinline[language=C++]{this} or \lstinline[language=java]{self} in other object-oriented languages, and implicitly passed.
     323The first parameter is logically, the \lstinline[language=C++]{this} or \lstinline[language=Python]{self} in other object-oriented languages, and implicitly passed.
     324\VRef[Figure]{f:CFAConstructorDestructor} shows an example of creating and using a constructor and destructor.
     325Both constructor and destructor can be explicitly called to reuse a variable.
     326
     327\begin{figure}
    311328\begin{cfa}
    312329struct Employee {
     
    314331        double salary;
    315332};
    316 void @?{}@( Employee & this, char * name, double salary ) {
    317         this.name = aalloc( sizeof(name) );
    318         strcpy( this.name, name );
    319         this.salary = salary;
    320 }
    321 void @^?{}@( Employee & this ) {
    322         free( this.name );
     333void @?{}@( Employee & emp, char * nname, double nsalary ) with( emp ) { // auto qualification
     334        name = aalloc( sizeof(nname) );
     335        strcpy( name, nname );
     336        salary = nsalary;
     337}
     338void @^?{}@( Employee & emp ) {
     339        free( emp.name );
    323340}
    324341{
    325         Employee name = { "Sara Schmidt", 20.5 };
    326 } // implicit destructor call
    327 \end{cfa}
    328 Both constructor and destructor can be explicitly called.
    329 \begin{cfa}
    330         Employee name = { "Sara Schmidt", 20.5 };
    331         ... // use name
    332         ^?{}( name ); // de-initialize
    333         ?{}( name, "Jack Smith", 10.5 }; // re-initialize
    334         ... // use name
    335 \end{cfa}
     342        Employee emp = { "Sara Schmidt", 20.5 }; $\C{// initialize with implicit constructor call}$
     343        ... // use emp
     344        ^?{}( emp ); $\C{// explicit de-initialize}$
     345        ?{}( emp, "Jack Smith", 10.5 ); $\C{// explicit re-initialize}$
     346        ... // use emp
     347} $\C{// de-initialize with implicit destructor call}$
     348\end{cfa}
     349\caption{\CFA Constructor and Destructor}
     350\label{f:CFAConstructorDestructor}
     351\end{figure}
    336352
    337353
Note: See TracChangeset for help on using the changeset viewer.