Changeset 69ce455 for doc/papers/general/Paper.tex
- Timestamp:
- Feb 6, 2018, 11:42:52 AM (5 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 7d94d805
- Parents:
- 7ad6b6d (diff), 5f95b5f (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
Legend:
- Unmodified
- Added
- Removed
-
doc/papers/general/Paper.tex
r7ad6b6d r69ce455 61 61 \newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@basicstyle{\LstCommentStyle{#2}}}} 62 62 \newcommand{\CRT}{\global\columnposn=\gcolumnposn} 63 64 % Denote newterms in particular font and index them without particular font and in lowercase, e.g., \newterm{abc}. 65 % The option parameter provides an index term different from the new term, e.g., \newterm[\texttt{abc}]{abc} 66 % The star version does not lowercase the index information, e.g., \newterm*{IBM}. 67 \newcommand{\newtermFontInline}{\emph} 68 \newcommand{\newterm}{\@ifstar\@snewterm\@newterm} 69 \newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi} 70 \newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi} 63 71 64 72 % Latin abbreviation … … 1040 1048 \TODO{choose and fallthrough here as well?} 1041 1049 1050 1042 1051 \subsection{\texorpdfstring{\LstKeywordStyle{with} Clause / Statement}{with Clause / Statement}} 1043 1052 \label{s:WithClauseStatement} 1044 1053 1045 In any programming language, some functions have a naturally close relationship with a particular data type. 1046 Object-oriented programming allows this close relationship to be codified in the language by making such functions \emph{class methods} of their related data type. 1047 Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type. 1048 When writing C functions in an object-oriented style, this un-prefixed access is swiftly missed, as access to fields of a @Foo* f@ requires an extra three characters @f->@ every time, which disrupts coding flow and clutters the produced code. 1049 1050 \TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.} 1051 1052 1053 In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided. 1054 Grouping heterogenous data into \newterm{aggregate}s is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers: 1055 \begin{cfa} 1056 struct S { $\C{// aggregate}$ 1057 char c; $\C{// fields}$ 1058 int i; 1059 double d; 1060 }; 1061 S s, as[10]; 1062 \end{cfa} 1063 However, routines manipulating aggregates have repeition of the aggregate name to access its containing fields: 1064 \begin{cfa} 1065 void f( S s ) { 1066 `s.`c; `s.`i; `s.`d; $\C{// access containing fields}$ 1067 } 1068 \end{cfa} 1069 A similar situation occurs in object-oriented programming, \eg \CC: 1054 1070 \begin{C++} 1055 1071 class C { 1056 int i, j; 1057 int mem() { $\C{\color{red}// implicit "this" parameter}$ 1058 i = 1; $\C{\color{red}// this-{\textgreater}i}$ 1059 j = 2; $\C{\color{red}// this-{\textgreater}j}$ 1072 char c; $\C{// fields}$ 1073 int i; 1074 double d; 1075 int mem() { $\C{// implicit "this" parameter}$ 1076 `this->`c; `this->`i; `this->`d;$\C{// access containing fields}$ 1060 1077 } 1061 1078 } 1062 1079 \end{C++} 1063 Since \CFA is non-object-oriented, the equivalent object-oriented program looks like: 1080 Nesting of member routines in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of nested lexical-scoping. 1081 1082 % In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided. 1083 % In any programming language, some functions have a naturally close relationship with a particular data type. 1084 % Object-oriented programming allows this close relationship to be codified in the language by making such functions \emph{class methods} of their related data type. 1085 % Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type. 1086 % When writing C functions in an object-oriented style, this un-prefixed access is swiftly missed, as access to fields of a @Foo* f@ requires an extra three characters @f->@ every time, which disrupts coding flow and clutters the produced code. 1087 % 1088 % \TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.} 1089 1090 \CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided aggregate qualification to fields by opening a scope containing field identifiers. 1091 Hence, the qualified fields become variables, and making it easier to optimizing field references in a block. 1064 1092 \begin{cfa} 1065 struct S { int i, j; }; 1066 int mem( S & `this` ) { $\C{// explicit "this" parameter}$ 1067 `this.`i = 1; $\C{// "this" is not elided}$ 1068 `this.`j = 2; 1093 void f( S s ) `with s` { $\C{// with clause}$ 1094 c; i; d; $\C{\color{red}// s.c, s.i, s.d}$ 1069 1095 } 1070 1096 \end{cfa} 1071 but it is cumbersome having to write "this." many times in a member. 1072 1073 \CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided the "@this.@" by opening a scope containing field identifiers, changing the qualified fields into variables and giving an opportunity for optimizing qualified references. 1097 and the equivalence for object-style programming is: 1074 1098 \begin{cfa} 1075 int mem( S &this ) `with this` { $\C{// with clause}$ 1076 i = 1; $\C{\color{red}// this.i}$ 1077 j = 2; $\C{\color{red}// this.j}$ 1099 int mem( S & this ) `with this` { $\C{// with clause}$ 1100 c; i; d; $\C{\color{red}// this.c, this.i, this.d}$ 1078 1101 } 1079 1102 \end{cfa} 1080 which extends to multiple routine parameters:1103 The key generality over the object-oriented approach is that one aggregate parameter \lstinline[language=C++]@this@ is not treated specially over other aggregate parameters: 1081 1104 \begin{cfa} 1082 1105 struct T { double m, n; }; 1083 int mem2( S & this1, T & this2 ) `with this1, this2` { 1084 i = 1; j = 2; 1085 m = 1.0; n = 2.0; 1106 int mem( S & s, T & t ) `with s, t` { $\C{// multiple aggregate parameters}$ 1107 c; i; d; $\C{\color{red}// s.c, s.i, s.d}$ 1108 m; n; $\C{\color{red}// t.m, t.n}$ 1109 } 1110 \end{cfa} 1111 The equivalent object-oriented style is: 1112 \begin{cfa} 1113 int S::mem( T & t ) { $\C{// multiple aggregate parameters}$ 1114 c; i; d; $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$ 1115 `t.`m; `t.`n; 1086 1116 } 1087 1117 \end{cfa} … … 1092 1122 struct S1 { ... } s1; 1093 1123 struct S2 { ... } s2; 1094 `with s1` { $\C{// with statement}$1124 `with s1` { $\C{// with statement}$ 1095 1125 // access fields of s1 without qualification 1096 `with s2` { $\C{// nesting}$1126 `with s2` { $\C{// nesting}$ 1097 1127 // access fields of s1 and s2 without qualification 1098 1128 } … … 1110 1140 struct T { int i; int k; int m } b, c; 1111 1141 `with a, b` { 1112 j + k; $\C{// unambiguous, unique names define unique types}$1113 i; $\C{// ambiguous, same name and type}$1114 a.i + b.i; $\C{// unambiguous, qualification defines unique names}$1115 m; $\C{// ambiguous, same name and no context to define unique type}$1116 m = 5.0; $\C{// unambiguous, same name and context defines unique type}$1117 m = 1; $\C{// unambiguous, same name and context defines unique type}$1118 } 1119 `with c` { ... } $\C{// ambiguous, same name and no context}$1120 `with (S)c` { ... } $\C{// unambiguous, same name and cast defines unique type}$1142 j + k; $\C{// unambiguous, unique names define unique types}$ 1143 i; $\C{// ambiguous, same name and type}$ 1144 a.i + b.i; $\C{// unambiguous, qualification defines unique names}$ 1145 m; $\C{// ambiguous, same name and no context to define unique type}$ 1146 m = 5.0; $\C{// unambiguous, same name and context defines unique type}$ 1147 m = 1; $\C{// unambiguous, same name and context defines unique type}$ 1148 } 1149 `with c` { ... } $\C{// ambiguous, same name and no context}$ 1150 `with (S)c` { ... } $\C{// unambiguous, same name and cast defines unique type}$ 1121 1151 \end{cfa} 1122 1152 … … 1234 1264 \TODO{finish reference conversions; look at user manual} 1235 1265 1266 1236 1267 \subsection{Constructors and Destructors} 1237 1268 … … 1252 1283 1253 1284 \TODO{Some text already at the end of Section~\ref{sec:poly-fns}} 1285 1254 1286 1255 1287 \subsection{Units}
Note: See TracChangeset
for help on using the changeset viewer.