Index: doc/papers/general/Paper.tex =================================================================== --- doc/papers/general/Paper.tex (revision b4f0dde228ac3ad3f63e253486b121aee251b3d8) +++ doc/papers/general/Paper.tex (revision 9b15e05aeaebeccf18406fb219713f33a144d58d) @@ -653,5 +653,5 @@ } \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}. @@ -815,5 +815,5 @@ \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} @@ -1020,10 +1020,10 @@ \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; @@ -1033,5 +1033,5 @@ \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]); @@ -1047,9 +1047,9 @@ _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. @@ -1083,5 +1083,5 @@ 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. @@ -1493,5 +1493,5 @@ 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}%??? @@ -1530,10 +1530,10 @@ 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}$ @@ -1549,5 +1549,5 @@ 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. @@ -1555,5 +1555,5 @@ \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} @@ -1659,5 +1659,5 @@ \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. @@ -1715,5 +1715,5 @@ // pointer to array of 5 doubles -// common bit field syntax +// common bit-field syntax @@ -1911,8 +1911,8 @@ \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 @@ -2013,5 +2013,5 @@ \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}. @@ -2036,5 +2036,5 @@ \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} @@ -2059,7 +2059,7 @@ 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++}. @@ -2793,5 +2793,5 @@ 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.