Context Navigation

-              r98c77b2
+              r8fe7a85
 Here, manipulating the pointer address is the primary operation, while dereferencing the pointer to its value is the secondary operation.
 For example, \emph{within} a data structure, \eg stack or queue, all operations involve pointer addresses and the pointer may never be dereferenced because the referenced object is opaque.
 Alternatively, use a reference when its primary purpose is to alias a value, \eg a function parameter that does not copy the argument (performance reason).
+Alternatively, use a reference when its primary purpose is to alias a value, \eg a function parameter that does not copy the argument, for performance reasons.
 Here, manipulating the value is the primary operation, while changing the pointer address is the secondary operation.
 Succinctly, if the address changes often, use a pointer;
 …
 The call applies an implicit dereference once to @x@ so the call is typed @f( int & )@ with @T = int@, rather than with @T = int &@.
 As for a pointer type, a reference type may have qualifiers, where @const@ is most common.
+As with a pointer type, a reference type may have qualifiers, where @const@ is most common.
 \begin{cfa}
 int x = 3; $\C{// mutable}$
 …
 @[x, y, z]@ = foo( 3, 4 );  // return 3 values into a tuple
 \end{cfa}
 Along with making returning multiple values a first-class feature, tuples were extended to simplify a number of other common contexts that normally require multiple statements and/or additional declarations, all of which reduces coding time and errors.
+Along with making returning multiple values a first-class feature, tuples were extended to simplify a number of other common contexts that normally require multiple statements and/or additional declarations.
 \begin{cfa}
 [x, y, z] = 3; $\C[2in]{// x = 3; y = 3; z = 3, where types may be different}$
 …
 Only when returning a tuple from a function is there the notion of a tuple value.
 Overloading in the \CFA type-system must support complex composition of tuples and C type conversions using a costing scheme giving lower cost to widening conversions that do not truncate a value.
+Overloading in the \CFA type-system must support complex composition of tuples and C type conversions using a conversion cost scheme giving lower cost to widening conversions that do not truncate a value.
 \begin{cfa}
 [ int, int ] foo$\(_1\)$( int );                        $\C{// overloaded foo functions}$
 …
 bar( foo( 3 ) ) // only one tuple returning call
 \end{lstlisting}
 Hence, programers cannot take advantage of the full power of tuples but type match is straightforward.
+Hence, programmers cannot take advantage of the full power of tuples but type match is straightforward.
 K-W C also supported tuple variables, but with a strong distinction between tuples and tuple values/variables.
 …
 \end{figure}
 Interestingly, in the third implementation of \CFA tuples by Robert Schluntz~\cite[\S~3]{Schluntz17}, the MVR functions revert back to structure based, where it remains in the current version of \CFA.
+Interestingly, in the third implementation of \CFA tuples by Robert Schluntz~\cite[\S~3]{Schluntz17}, the MVR functions revert back to structure based, and this remains in the current version of \CFA.
 The reason for the reversion is a uniform approach for tuple values/variables making tuples first-class types in \CFA, \ie allow tuples with corresponding tuple variables.
 This reversion was possible, because in parallel with Schluntz's work, generic types were added independently by Moss~\cite{Moss19}, and the tuple variables leveraged the same implementation techniques as for generic variables~\cite[\S~3.7]{Schluntz17}.
 …
 looping is used to traverse the argument pack from left to right.
 The @va_list@ interface is walking up the stack (by address) looking at the arguments pushed by the caller.
 (Magic knowledge is needed for arguments pushed using registers.)
+(Compiler-specific ABI knowledge is needed for arguments pushed using registers.)
 \begin{figure}
 …
 Nested \emph{named} aggregates are allowed in C but there is no qualification operator, like the \CC type operator `@::@', to access an inner type.
+\emph{To compensate for the missing type operator, all named nested aggregates are hoisted to global scope, regardless of the nesting depth, and type usages within the nested type are replaced with global type name.}
+To compensate for the missing type operator, all named nested aggregates are hoisted to global scope, regardless of the nesting depth, and type usages within the nested type are replaced with global type name.
 Hoisting nested types can result in name collisions among types at the global level, which defeats the purpose of nesting the type.
 \VRef[Figure]{f:NestedNamedAggregate} shows the nested type @T@ is hoisted to the global scope and the declaration rewrites within structure @S@.
 …
 \end{figure}
 For good reasons, \CC chose to change this semantics:
+\CC chose to change this semantics:
 \begin{cquote}
 \begin{description}[leftmargin=*,topsep=0pt,itemsep=0pt,parsep=0pt]
 …
 Like an anonymous nested type, a named Plan-9 nested type has its field names hoisted into @struct S@, so there is direct access, \eg @s.x@ and @s.i@.
 Hence, the field names must be unique, unlike \CC nested types, but the type names are at a nested scope level, unlike type nesting in C.
 In addition, a pointer to a structure is automatically converted to a pointer to an anonymous field for assignments and function calls, providing containment inheritance with implicit subtyping, \ie @U@ $\subset$ @S@ and @W@ $\subset$ @S@, \eg:
+In addition, a pointer to a structure is automatically converted to a pointer to an anonymous field for assignments and function calls, providing containment inheritance with implicit subtyping, \ie @U@ $<:$ @S@ and @W@ $<:$ @S@, \eg:
 \begin{cfa}
 void f( union U * u );
 …
 Note, there is no value assignment, such as, @w = s@, to copy the @W@ field from @S@.
 Unfortunately, the Plan-9 designers did not lookahead to other useful features, specifically nested types.
+Unfortunately, the Plan-9 designers did not look ahead to other useful features, specifically nested types.
 This nested type compiles in \CC and \CFA.
 \begin{cfa}
 …
 In addition, a semi-non-compatible change is made so that Plan-9 syntax means a forward declaration in a nested type.
 Since the Plan-9 extension is not part of C and rarely used, this change has minimal impact.
 Hence, all Plan-9 semantics are denoted by the @inline@ qualifier, which is good ``eye-candy'' when reading a structure definition to spot Plan-9 definitions.
+Hence, all Plan-9 semantics are denoted by the @inline@ qualifier, which clearly indicates the usage of Plan-9 definitions.
 Finally, the following code shows the value and pointer polymorphism.
 \begin{cfa}
 …
 \end{c++}
 and again the expression @d.x@ is ambiguous.
 While \CC has no direct syntax to disambiguate @x@, \ie @d.B.x@ or @d.C.x@, it is possible with casts, @((B)d).x@ or @((C)d).x@.
+While \CC has no direct syntax to disambiguate @x@, \eg @d.B.x@ or @d.C.x@, it is possible with casts, @((B)d).x@ or @((C)d).x@.
 Like \CC, \CFA compiles the Plan-9 version and provides direct qualification and casts to disambiguate @x@.
 While ambiguous definitions are allowed, duplicate field names are poor practice and should be avoided if possible.

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

Context Navigation

Changeset 8fe7a85 for doc/theses/fangren_yu_MMath/features.tex

Legend:

doc/theses/fangren_yu_MMath/features.tex

Download in other formats: