# Changeset 9b15e05

Ignore:
Timestamp:
May 25, 2018, 9:40:18 AM (3 years ago)
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, with_gc
Children:
251454a0
Parents:
b4f0dde
Message:

change "field" to "member" for structures

File:
1 edited

### Legend:

Unmodified
 rb4f0dde } \end{cfa} Since @pair( T *, T * )@ is a concrete type, there are no implicit parameters passed to @lexcmp@, so the generated code is identical to a function written in standard C using @void *@, yet the \CFA version is type-checked to ensure the fields of both pairs and the arguments to the comparison function match in type. Since @pair( T *, T * )@ is a concrete type, there are no implicit parameters passed to @lexcmp@, so the generated code is identical to a function written in standard C using @void *@, yet the \CFA version is type-checked to ensure the members of both pairs and the arguments to the comparison function match in type. Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \newterm{tag-structures}. \subsection{Member Access} It is also possible to access multiple fields from a single expression using a \newterm{member-access}. It is also possible to access multiple members from a single expression using a \newterm{member-access}. The result is a single tuple-valued expression whose type is the tuple of the types of the members, \eg: \begin{cfa} \begin{cfa} forall( dtype T0, dtype T1 | sized(T0) | sized(T1) ) struct _tuple2 { T0 field_0;  T1 field_1;                                        $\C{// generated before the first 2-tuple}$ T0 member_0;  T1 member_1;                                      $\C{// generated before the first 2-tuple}$ }; _tuple2(int, int) f() { _tuple2(double, double) x; forall( dtype T0, dtype T1, dtype T2 | sized(T0) | sized(T1) | sized(T2) ) struct _tuple3 { T0 field_0;  T1 field_1;  T2 field_2;   $\C{// generated before the first 3-tuple}$ T0 member_0;  T1 member_1;  T2 member_2;        $\C{// generated before the first 3-tuple}$ }; _tuple3(int, double, int) y; \begin{comment} Since tuples are essentially structures, tuple indexing expressions are just field accesses: Since tuples are essentially structures, tuple indexing expressions are just member accesses: \begin{cfa} void f(int, [double, char]); _tuple2(int, double) x; x.field_0+x.field_1; printf("%d %g\n", x.field_0, x.field_1); f(x.field_0, (_tuple2){ x.field_1, 'z' }); \end{cfa} Note that due to flattening, @x@ used in the argument position is converted into the list of its fields. x.member_0+x.member_1; printf("%d %g\n", x.member_0, x.member_1); f(x.member_0, (_tuple2){ x.member_1, 'z' }); \end{cfa} Note that due to flattening, @x@ used in the argument position is converted into the list of its members. In the call to @f@, the second and third argument components are structured into a tuple argument. Similarly, tuple member expressions are recursively expanded into a list of member access expressions. The various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions. A variable is generated to store the value produced by a statement expression, since its fields may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg in a unique expression. A variable is generated to store the value produced by a statement expression, since its members may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg in a unique expression. The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language. However, there are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this restriction is not new. Heterogeneous data is often aggregated into a structure/union. To reduce syntactic noise, \CFA provides a @with@ statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate field-qualification by opening a scope containing the field identifiers. To reduce syntactic noise, \CFA provides a @with@ statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate member-qualification by opening a scope containing the member identifiers. \begin{cquote} \vspace*{-\baselineskip}%??? The type must be an aggregate type. (Enumerations are already opened.) The object is the implicit qualifier for the open structure-fields. The object is the implicit qualifier for the open structure-members. All expressions in the expression list are open in parallel within the compound statement, which is different from Pascal, which nests the openings from left to right. The difference between parallel and nesting occurs for fields with the same name and type: \begin{cfa} struct S { int i; int j; double m; } s, w;    $\C{// field i has same type in structure types S and T}$ The difference between parallel and nesting occurs for members with the same name and type: \begin{cfa} struct S { int i; int j; double m; } s, w;    $\C{// member i has same type in structure types S and T}$ struct T { int i; int k; int m; } t, w; with ( s, t ) {                                                         $\C{// open structure variables s and t in parallel}$ For parallel semantics, both @s.i@ and @t.i@ are visible, so @i@ is ambiguous without qualification; for nested semantics, @t.i@ hides @s.i@, so @i@ implies @t.i@. \CFA's ability to overload variables means fields with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates. \CFA's ability to overload variables means members with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates. Qualification or a cast is used to disambiguate. \begin{cfa} void ?{}( S & s, int i ) with ( s ) {           $\C{// constructor}$ s.i = i;  j = 3;  m = 5.5;                    $\C{// initialize fields}$ s.i = i;  j = 3;  m = 5.5;                    $\C{// initialize members}$ } \end{cfa} \lstMakeShortInline@% \end{cquote} The only exception is bit field specification, which always appear to the right of the base type. The only exception is bit-field specification, which always appear to the right of the base type. % Specifically, the character @*@ is used to indicate a pointer, square brackets @[@\,@]@ are used to represent an array or function return value, and parentheses @()@ are used to indicate a function parameter. However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list. // pointer to array of 5 doubles // common bit field syntax // common bit-field syntax \subsection{Type Nesting} Nested types provide a mechanism to organize associated types and refactor a subset of fields into a named aggregate (\eg sub-aggregates @name@, @address@, @department@, within aggregate @employe@). Nested types provide a mechanism to organize associated types and refactor a subset of members into a named aggregate (\eg sub-aggregates @name@, @address@, @department@, within aggregate @employe@). Java nested types are dynamic (apply to objects), \CC are static (apply to the \lstinline[language=C++]@class@), and C hoists (refactors) nested types into the enclosing scope, meaning there is no need for type qualification. Since \CFA in not object-oriented, adopting dynamic scoping does not make sense; instead \CFA adopts \CC static nesting, using the field-selection operator @.@'' for type qualification, as does Java, rather than the \CC type-selection operator @::@'' (see Figure~\ref{f:TypeNestingQualification}). instead \CFA adopts \CC static nesting, using the member-selection operator @.@'' for type qualification, as does Java, rather than the \CC type-selection operator @::@'' (see Figure~\ref{f:TypeNestingQualification}). \begin{figure} \centering \end{cfa} @VLA@ is a \newterm{managed type}\footnote{ A managed type affects the runtime environment versus a self-contained type.}: a type requiring a non-trivial constructor or destructor, or with a field of a managed type. A managed type affects the runtime environment versus a self-contained type.}: a type requiring a non-trivial constructor or destructor, or with a member of a managed type. A managed type is implicitly constructed at allocation and destructed at deallocation to ensure proper interaction with runtime resources, in this case, the @data@ array in the heap. For details of the code-generation placement of implicit constructor and destructor calls among complex executable statements see~\cite[\S~2.2]{Schluntz17}. \CFA constructors may be explicitly called, like Java, and destructors may be explicitly called, like \CC. Explicit calls to constructors double as a \CC-style \emph{placement syntax}, useful for construction of member fields in user-defined constructors and reuse of existing storage allocations. Explicit calls to constructors double as a \CC-style \emph{placement syntax}, useful for construction of members in user-defined constructors and reuse of existing storage allocations. Like the other operators in \CFA, there is a concise syntax for constructor/destructor function calls: \begin{cfa} For compatibility with C, a copy constructor from the first union member type is also defined. For @struct@ types, each of the four functions are implicitly defined to call their corresponding functions on each member of the struct. To better simulate the behaviour of C initializers, a set of \newterm{field constructors} is also generated for structures. To better simulate the behaviour of C initializers, a set of \newterm{member constructors} is also generated for structures. A constructor is generated for each non-empty prefix of a structure's member-list to copy-construct the members passed as parameters and default-construct the remaining members. To allow users to limit the set of constructors available for a type, when a user declares any constructor or destructor, the corresponding generated function and all field constructors for that type are hidden from expression resolution; To allow users to limit the set of constructors available for a type, when a user declares any constructor or destructor, the corresponding generated function and all member constructors for that type are hidden from expression resolution; similarly, the generated default constructor is hidden upon declaration of any constructor. These semantics closely mirror the rule for implicit declaration of constructors in \CC\cite[p.~186]{ANSI98:C++}. C provides variadic functions through @va_list@ objects, but the programmer is responsible for managing the number of arguments and their types, so the mechanism is type unsafe. KW-C~\cite{Buhr94a}, a predecessor of \CFA, introduced tuples to C as an extension of the C syntax, taking much of its inspiration from SETL. The main contributions of that work were adding MRVF, tuple mass and multiple assignment, and record-field access. The main contributions of that work were adding MRVF, tuple mass and multiple assignment, and record-member access. \CCeleven introduced @std::tuple@ as a library variadic template structure. Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values.