Changeset bd72f517 for doc/theses/fangren_yu_MMath/features.tex
- Timestamp:
- May 13, 2025, 1:17:50 PM (10 months ago)
- Branches:
- master, stuck-waitfor-destruct
- Children:
- 0528d79
- Parents:
- 7d02d35 (diff), 2410424 (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. - File:
-
- 1 edited
-
doc/theses/fangren_yu_MMath/features.tex (modified) (24 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/fangren_yu_MMath/features.tex
r7d02d35 rbd72f517 13 13 Here, manipulating the pointer address is the primary operation, while dereferencing the pointer to its value is the secondary operation. 14 14 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. 15 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).15 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. 16 16 Here, manipulating the value is the primary operation, while changing the pointer address is the secondary operation. 17 17 Succinctly, if the address changes often, use a pointer; … … 23 23 \CFA adopts a uniform policy between pointers and references where mutability is a separate property made at the declaration. 24 24 25 The following examples show show pointers and references are treated uniformly in \CFA.25 The following examples show how pointers and references are treated uniformly in \CFA. 26 26 \begin{cfa}[numbers=left,numberblanklines=false] 27 27 int x = 1, y = 2, z = 3;$\label{p:refexamples}$ … … 36 36 @&@r3 = @&@y; @&&@r3 = @&&@r4; $\C{// change r1, r2}$ 37 37 \end{cfa} 38 Like pointers, reference can be cascaded, \ie a reference to a reference, \eg @&& r2@.\footnote{38 Like pointers, references can be cascaded, \ie a reference to a reference, \eg @&& r2@.\footnote{ 39 39 \CC uses \lstinline{&&} for rvalue reference, a feature for move semantics and handling the \lstinline{const} Hell problem.} 40 40 Usage of a reference variable automatically performs the same number of dereferences as the number of references in its declaration, \eg @r2@ becomes @**r2@. … … 64 64 The call applies an implicit dereference once to @x@ so the call is typed @f( int & )@ with @T = int@, rather than with @T = int &@. 65 65 66 As fora pointer type, a reference type may have qualifiers, where @const@ is most common.66 As with a pointer type, a reference type may have qualifiers, where @const@ is most common. 67 67 \begin{cfa} 68 68 int x = 3; $\C{// mutable}$ … … 101 101 Interestingly, C does not give a warning/error if a @const@ pointer is not initialized, while \CC does. 102 102 Hence, type @& const@ is similar to a \CC reference, but \CFA does not preclude initialization with a non-variable address. 103 For example, in system 's programming, there are cases where an immutable address is initialized to a specific memory location.103 For example, in systems programming, there are cases where an immutable address is initialized to a specific memory location. 104 104 \begin{cfa} 105 105 int & const mem_map = *0xe45bbc67@p@; $\C{// hardware mapped registers ('p' for pointer)}$ … … 122 122 \end{cfa} 123 123 the call to @foo@ must pass @x@ by value, implying auto-dereference, while the call to @bar@ must pass @x@ by reference, implying no auto-dereference. 124 Without any restrictions, this ambiguity limits the behaviour of reference types in \CFA polymorphic functions, where a type @T@ can bind to a reference or non-reference type. 124 125 \PAB{My analysis shows} without any restrictions, this ambiguity limits the behaviour of reference types in \CFA polymorphic functions, where a type @T@ can bind to a reference or non-reference type. 125 126 This ambiguity prevents the type system treating reference types the same way as other types, even if type variables could be bound to reference types. 126 127 The reason is that \CFA uses a common \emph{object trait}\label{p:objecttrait} (constructor, destructor and assignment operators) to handle passing dynamic concrete type arguments into polymorphic functions, and the reference types are handled differently in these contexts so they do not satisfy this common interface. … … 157 158 \end{cfa} 158 159 While it is possible to write a reference type as the argument to a generic type, it is disallowed in assertion checking, if the generic type requires the object trait \see{\VPageref{p:objecttrait}} for the type argument, a fairly common use case. 159 Even if the object trait can be made optional, the current type systemoften misbehaves by adding undesirable auto-dereference on the referenced-to value rather than the reference variable itself, as intended.160 Even if the object trait can be made optional, the current compiler implementation often misbehaves by adding undesirable auto-dereference on the referenced-to value rather than the reference variable itself, as intended. 160 161 Some tweaks are necessary to accommodate reference types in polymorphic contexts and it is unclear what can or cannot be achieved. 161 162 Currently, there are contexts where the \CFA programmer is forced to use a pointer type, giving up the benefits of auto-dereference operations and better syntax with reference types. … … 188 189 @[x, y, z]@ = foo( 3, 4 ); // return 3 values into a tuple 189 190 \end{cfa} 190 Along with making returning multiple values a first-class feature, tuples were extended to simplify a number of other common context that normally require multiple statements and/or additional declarations, all of which reduces coding time and errors.191 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. 191 192 \begin{cfa} 192 193 [x, y, z] = 3; $\C[2in]{// x = 3; y = 3; z = 3, where types may be different}$ … … 205 206 Only when returning a tuple from a function is there the notion of a tuple value. 206 207 207 Overloading in the \CFA type-system must support complex composition of tuples and C type conversions using a co stingscheme giving lower cost to widening conversions that do not truncate a value.208 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. 208 209 \begin{cfa} 209 210 [ int, int ] foo$\(_1\)$( int ); $\C{// overloaded foo functions}$ … … 213 214 \end{cfa} 214 215 The type resolver only has the tuple return types to resolve the call to @bar@ as the @foo@ parameters are identical. 215 The resul tion involves unifying the flattened @foo@ return values with @bar@'s parameter list.216 The resulution involves unifying the flattened @foo@ return values with @bar@'s parameter list. 216 217 However, no combination of @foo@s is an exact match with @bar@'s parameters; 217 218 thus, the resolver applies C conversions to obtain a best match. … … 223 224 bar( foo( 3 ) ) // only one tuple returning call 224 225 \end{lstlisting} 225 Hence, program ers cannot take advantage of the full power of tuples but type match is straightforward.226 Hence, programmers cannot take advantage of the full power of tuples but type match is straightforward. 226 227 227 228 K-W C also supported tuple variables, but with a strong distinction between tuples and tuple values/variables. … … 286 287 \end{figure} 287 288 288 The primary issues for tuples in the \CFA type system are polymorphism and conversions.289 \PAB{I identified} the primary issues for tuples in the \CFA type system are polymorphism and conversions. 289 290 Specifically, does it make sense to have a generic (polymorphic) tuple type, as is possible for a structure? 290 291 \begin{cfa} … … 303 304 \section{Tuple Implementation} 304 305 305 As noted, tradition languages manipulate multiple values by in/out parameters and/or structures.306 As noted, traditional languages manipulate multiple values by in/out parameters and/or structures. 306 307 K-W C adopted the structure for tuple values or variables, and as needed, the fields are extracted by field access operations. 307 308 As well, for the tuple-assignment implementation, the left-hand tuple expression is expanded into assignments of each component, creating temporary variables to avoid unexpected side effects. … … 356 357 \end{figure} 357 358 358 Interestingly, in the third implementation of \CFA tuples by Robert Schluntz~\cite[\S~3]{Schluntz17}, the MVR functions revert back to structure based, where itremains in the current version of \CFA.359 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. 359 360 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. 360 361 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}. … … 384 385 Scala, like \CC, provides tuple types through a library using this structural expansion, \eg Scala provides tuple sizes 1 through 22 via hand-coded generic data-structures. 385 386 386 However, after experience gained building the \CFA runtime system, making tuple-types first-class seems to add little benefit.387 However, after experience gained building the \CFA runtime system, \PAB{I convinced them} making tuple-types first-class seems to add little benefit. 387 388 The main reason is that tuples usages are largely unstructured, 388 389 \begin{cfa} … … 512 513 looping is used to traverse the argument pack from left to right. 513 514 The @va_list@ interface is walking up the stack (by address) looking at the arguments pushed by the caller. 514 ( Magicknowledge is needed for arguments pushed using registers.)515 (Compiler-specific ABI knowledge is needed for arguments pushed using registers.) 515 516 516 517 \begin{figure} … … 571 572 572 573 Currently in \CFA, variadic polymorphic functions are the only place tuple types are used. 573 And because \CFA compiles polymorphic functions versus template expansion, many wrapper functions are generated to implement both user-defined generic-types and polymorphism with variadics.574 \PAB{My analysis showed} many wrapper functions are generated to implement both user-defined generic-types and polymorphism with variadics, because \CFA compiles polymorphic functions versus template expansion. 574 575 Fortunately, the only permitted operations on polymorphic function parameters are given by the list of assertion (trait) functions. 575 576 Nevertheless, this small set of functions eventually needs to be called with flattened tuple arguments. 576 577 Unfortunately, packing the variadic arguments into a rigid @struct@ type and generating all the required wrapper functions is significant work and largely wasted because most are never called. 577 578 Interested readers can refer to pages 77-80 of Robert Schluntz's thesis to see how verbose the translator output is to implement a simple variadic call with 3 arguments. 578 As the number of arguments increases, \eg a call with 5 arguments, the translator generates aconcrete @struct@ types for a 4-tuple and a 3-tuple along with all the polymorphic type data for them.579 As the number of arguments increases, \eg a call with 5 arguments, the translator generates concrete @struct@ types for a 4-tuple and a 3-tuple along with all the polymorphic type data for them. 579 580 An alternative approach is to put the variadic arguments into an array, along with an offset array to retrieve each individual argument. 580 581 This method is similar to how the C @va_list@ object is used (and how \CFA accesses polymorphic fields in a generic type), but the \CFA variadics generate the required type information to guarantee type safety (like the @printf@ format string). … … 683 684 684 685 Nested \emph{named} aggregates are allowed in C but there is no qualification operator, like the \CC type operator `@::@', to access an inner type. 685 \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.} 686 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. 686 687 Hoisting nested types can result in name collisions among types at the global level, which defeats the purpose of nesting the type. 687 688 \VRef[Figure]{f:NestedNamedAggregate} shows the nested type @T@ is hoisted to the global scope and the declaration rewrites within structure @S@. … … 729 730 \end{figure} 730 731 731 For good reasons,\CC chose to change this semantics:732 \CC chose to change this semantics: 732 733 \begin{cquote} 733 734 \begin{description}[leftmargin=*,topsep=0pt,itemsep=0pt,parsep=0pt] … … 769 770 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@. 770 771 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. 771 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:772 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: 772 773 \begin{cfa} 773 774 void f( union U * u ); … … 781 782 Note, there is no value assignment, such as, @w = s@, to copy the @W@ field from @S@. 782 783 783 Unfortunately, the Plan-9 designers did not look ahead to other useful features, specifically nested types.784 Unfortunately, the Plan-9 designers did not look ahead to other useful features, specifically nested types. 784 785 This nested type compiles in \CC and \CFA. 785 786 \begin{cfa} … … 808 809 In addition, a semi-non-compatible change is made so that Plan-9 syntax means a forward declaration in a nested type. 809 810 Since the Plan-9 extension is not part of C and rarely used, this change has minimal impact. 810 Hence, all Plan-9 semantics are denoted by the @inline@ qualifier, which is good ``eye-candy'' when reading a structure definition to spotPlan-9 definitions.811 Hence, all Plan-9 semantics are denoted by the @inline@ qualifier, which clearly indicates the usage of Plan-9 definitions. 811 812 Finally, the following code shows the value and pointer polymorphism. 812 813 \begin{cfa} … … 821 822 822 823 In general, non-standard C features (@gcc@) do not need any special treatment, as they are directly passed through to the C compiler. 823 However, the Plan-9 semantics allow implicit conversions from the outer type to the inner type, which means the \CFA type resolver must take this information into account.824 However, \PAB{I found} the Plan-9 semantics allow implicit conversions from the outer type to the inner type, which means the \CFA type resolver must take this information into account. 824 825 Therefore, the \CFA resolver must implement the Plan-9 features and insert necessary type conversions into the translated code output. 825 826 In the current version of \CFA, this is the only kind of implicit type conversion other than the standard C arithmetic conversions. … … 847 848 \end{c++} 848 849 and again the expression @d.x@ is ambiguous. 849 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@.850 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@. 850 851 Like \CC, \CFA compiles the Plan-9 version and provides direct qualification and casts to disambiguate @x@. 851 While ambiguous definitions are allowed, duplicate field names ispoor practice and should be avoided if possible.852 While ambiguous definitions are allowed, duplicate field names are poor practice and should be avoided if possible. 852 853 However, when a programmer does not control all code, this problem can occur and a naming workaround must exist.
Note:
See TracChangeset
for help on using the changeset viewer.