Changeset 43bbdf3


Ignore:
Timestamp:
Feb 5, 2018, 9:09:44 PM (4 years ago)
Author:
Peter A. Buhr <pabuhr@…>
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, resolv-new, with_gc
Children:
6bfe5cc
Parents:
cbe477e
Message:

initial work in "with" clause/statement

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/papers/general/Paper.tex

    rcbe477e r43bbdf3  
    6161\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}}}}
    6262\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}
    6371
    6472% Latin abbreviation
     
    10401048\TODO{choose and fallthrough here as well?}
    10411049
     1050
    10421051\subsection{\texorpdfstring{\LstKeywordStyle{with} Clause / Statement}{with Clause / Statement}}
    10431052\label{s:WithClauseStatement}
    10441053
    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.
     1054Grouping 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}
     1056struct S {                                                              $\C{// aggregate}$
     1057        char c;                                                         $\C{// fields}$
     1058        int i;
     1059        double d;
     1060};
     1061S s, as[10];
     1062\end{cfa}
     1063However, routines manipulating aggregates have repeition of the aggregate name to access its containing fields:
     1064\begin{cfa}
     1065void f( S s ) {
     1066        `s.`c; `s.`i; `s.`d;                            $\C{// access containing fields}$
     1067}
     1068\end{cfa}
     1069A similar situation occurs in object-oriented programming, \eg \CC:
    10541070\begin{C++}
    10551071class 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}$
    10601077        }
    10611078}
    10621079\end{C++}
    1063 Since \CFA is non-object-oriented, the equivalent object-oriented program looks like:
     1080Nesting 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.
     1091Hence, the qualified fields become variables, and making it easier to optimizing field references in a block.
    10641092\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;
     1093void f( S s ) `with s` {                                $\C{// with clause}$
     1094        c; i; d;                                                        $\C{\color{red}// s.c, s.i, s.d}$
    10691095}
    10701096\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.
     1097and the equivalence for object-style programming is:
    10741098\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}$
     1099int mem( S & this ) `with this` {               $\C{// with clause}$
     1100        c; i; d;                                                        $\C{\color{red}// this.c, this.i, this.d}$
    10781101}
    10791102\end{cfa}
    1080 which extends to multiple routine parameters:
     1103The key generality over the object-oriented approach is that one aggregate parameter \lstinline[language=C++]@this@ is not treated specially over other aggregate parameters:
    10811104\begin{cfa}
    10821105struct 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;
     1106int 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}
     1111The equivalent object-oriented style is:
     1112\begin{cfa}
     1113int 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;
    10861116}
    10871117\end{cfa}
     
    10921122        struct S1 { ... } s1;
    10931123        struct S2 { ... } s2;
    1094         `with s1` {                                     $\C{// with statement}$
     1124        `with s1` {                                             $\C{// with statement}$
    10951125                // access fields of s1 without qualification
    1096                 `with s2` {                             $\C{// nesting}$
     1126                `with s2` {                                     $\C{// nesting}$
    10971127                        // access fields of s1 and s2 without qualification
    10981128                }
     
    11101140struct T { int i; int k; int m } b, c;
    11111141`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}$
    11211151\end{cfa}
    11221152
     
    12261256\TODO{Pull more draft text from user manual; make sure to discuss initialization and reference conversions}
    12271257
     1258
    12281259\subsection{Constructors and Destructors}
    12291260
     
    12441275
    12451276\TODO{Some text already at the end of Section~\ref{sec:poly-fns}}
     1277
    12461278
    12471279\subsection{Units}
Note: See TracChangeset for help on using the changeset viewer.