Changes in / [0bbe172:485cf59]


Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/mike_brooks_MMath/background.tex

    r0bbe172 r485cf59  
    6565\end{itemize}
    6666
    67 
    68 \section{Reading Declarations}
    69 
    70 A significant area of confusion for reading C declarations results from embedding a declared variable in a declaration, mimicking the way the variable is used in executable statements.
    71 \begin{cquote}
    72 \begin{tabular}{@{}ll@{}}
    73 \multicolumn{1}{@{}c}{\textbf{Array}} & \multicolumn{1}{c@{}}{\textbf{Function}} \\
    74 \begin{cfa}
    75 int @(*@ar@)[@5@]@; // definition
    76   ... @(*@ar@)[@3@]@ += 1; // usage
    77 \end{cfa}
    78 &
    79 \begin{cfa}
    80 int @(*@f@())[@5@]@ { ... }; // definition
    81   ... @(*@f@())[@3@]@ += 1; // usage
    82 \end{cfa}
    83 \end{tabular}
    84 \end{cquote}
    85 Essentially, the type is wrapped around the name in successive layers (like an \Index{onion}).
     67The following sections introduce the many layers of the C array story, concluding with an \emph{Unfortunate Syntactic Reference}.
     68It shows how to define (spell) the types under discussion, along with interactions with orthogonal (but easily confused) language features.
     69Alternate spellings are listed within a row.
     70The simplest occurrences of types distinguished in the preceding discussion are marked with $\triangleright$.
     71The Type column gives the spelling used in a cast or error message (though note Section TODO points out that some types cannot be casted to).
     72The Declaration column gives the spelling used in an object declaration, such as variable or aggregate member; parameter declarations (section TODO) follow entirely different rules.
     73
     74After all, reading a C array type is easy: just read it from the inside out, and know when to look left and when to look right!
     75
     76
     77\CFA-specific spellings (not yet introduced) are also included here for referenceability; these can be skipped on linear reading.
     78The \CFA-C column gives the, more fortunate, ``new'' syntax of section TODO, for spelling \emph{exactly the same type}.
     79This fortunate syntax does not have different spellings for types vs declarations;
     80a declaration is always the type followed by the declared identifier name;
     81for the example of letting @x@ be a \emph{pointer to array}, the declaration is spelled:
     82\begin{cfa}
     83* [10] T x;
     84\end{cfa}
     85The \CFA-Full column gives the spelling of a different type, introduced in TODO, which has all of my contributed improvements for safety and ergonomics.
     86
     87Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site.
     88For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
     89\begin{cfa}
     90int @(*@f@())[@5@]@ {...}; $\C{// definition}$
     91 ... @(*@f@())[@3@]@ += 1; $\C{// usage}$
     92\end{cfa}
     93Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
    8694While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice, even though Dennis Richie believed otherwise:
    8795\begin{quote}
    8896In spite of its difficulties, I believe that the C's approach to declarations remains plausible, and am comfortable with it; it is a useful unifying principle.~\cite[p.~12]{Ritchie93}
    8997\end{quote}
    90 After all, reading a C array type is easy: just read it from the inside out, and know when to look left and when to look right!
    9198
    9299\CFA provides its own type, variable and routine declarations, using a different syntax.
    93100The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
    94 The qualifiers have the same meaning in \CFA as in C.
    95 Hence, a \CFA declaration is read left to right, where a function return type is enclosed in brackets @[]@.
     101In the following example, {\color{red}red} is the base type and {\color{blue}blue} is qualifiers.
     102The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
    96103\begin{cquote}
    97 \begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
    98 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C}}   & \multicolumn{1}{c}{\textbf{\CFA}} &   \\
    99 \begin{cfa}
    100 int @*@ x1 @[5]@;
    101 int @(*@x2@)[5]@;
    102 int @(*@f( int p )@)[5]@;
     104\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     105\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C}}   & \multicolumn{1}{c}{\textbf{\CFA}}     \\
     106\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
     107@int@ #*# x1 #[5]#;
     108@int@ #(*#x2#)[5]#;
     109#int (*#f@( int p )@#)[5]#;
    103110\end{cfa}
    104111&
    105 \begin{cfa}
    106 @[5] *@ int x1;
    107 @* [5]@ int x2;
    108 @[ * [5] int ]@ f( int p );
    109 \end{cfa}
    110 &
    111 \begin{cfa}
    112 // array of 5 pointers to int
    113 // pointer to array of 5 int
    114 // function returning pointer to array of 5 ints
    115 \end{cfa}
    116 \\
    117 & &
    118 \LstCommentStyle{//\ \ \ and taking an int argument}
     112\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
     113#[5] *# @int@ x1;
     114#* [5]# @int@ x2;
     115#[* [5] int]# f@( int p )@;
     116\end{cfa}
    119117\end{tabular}
    120118\end{cquote}
    121 As declaration complexity increases, it becomes corresponding difficult to read and understand the C declaration form.
    122 Note, writing declarations left to right is common in other programming languages, where the function return-type is often placed after the parameter declarations.
    123 
    124 \VRef[Table]{bkgd:ar:usr:avp} introduces the many layers of the C and \CFA array story, where the \CFA story is discussion in \VRef{XXX}.
    125 The \CFA-thesis column shows the new array declaration form, which is my contributed improvements for safety and ergonomics.
    126 The table shows there are multiple yet equivalent forms for the array types under discussion, and subsequent discussion shows interactions with orthogonal (but easily confused) language features.
    127 Each row of the table shows alternate syntactic forms.
    128 The simplest occurrences of types distinguished in the preceding discussion are marked with $\triangleright$.
    129 Removing the declared variable @x@, gives the type used for variable, structure field, cast or error message \PAB{(though note Section TODO points out that some types cannot be casted to)}.
    130 Unfortunately, parameter declarations \PAB{(section TODO)} have more syntactic forms and rules.
    131 
    132 \begin{table}
     119
     120\VRef[Figure]{bkgd:ar:usr:avp} gives this reference for the discussion so far.
     121
     122\begin{figure}
    133123\centering
    134 \caption{Syntactic Reference for Array vs Pointer. Includes interaction with constness.}
     124\setlength{\tabcolsep}{3pt}
     125\begin{tabular}{ll|l|l|l|l}
     126        & Description & Type & Declaration & \CFA  & \CFA-thesis \\ \hline
     127        $\triangleright$ & val. & @T@ & @T x;@ & @T@ & \\
     128        \hline
     129        & immutable val. & @const T@ & @T const x;@ & @const T@ & \\
     130        & & @T const@ & @T const x;@ & @T const@ & \\
     131        \hline \hline
     132        $\triangleright$ & ptr.\ to val. & @T *@ & @T * x;@ & @* T@ & \\
     133        \hline
     134        & immutable ptr. to val. & @T * const@ & @T * const x;@ & @const * T@ & \\
     135        \hline
     136        & ptr. to immutable val. & @const T *@ & @const T * x;@ & @* const T@ & \\
     137        & & @T const *@ & @T const * x;@ & @* T const@ & \\
     138        \hline \hline
     139        $\triangleright$ & ar.\ of val. & @T[10]@ & @T x[10];@ & @[10] T@ & @array(T, 10)@ \\
     140        \hline
     141        & ar.\ of immutable val. & @const T[10]@ & @const T x[10];@ & @[10] const T@ & @const array(T, 10)@ \\
     142    & & @T const [10]@ & @T const x[10];@ & @[10] T const@ & @array(T, 10) const@ \\
     143        \hline
     144        & ar.\ of ptr.\ to val. & @T * [10]@ & @T * x[10];@ & @[10] * T@ & @array(T * | * T, 10)@ \\
     145        \hline
     146        & ar.\ of imm. ptr.\ to val. & @T * const [10]@ & @T * const x[10];@ & @[10] const * T@ & @array(const * T, 10)@ \\
     147        \hline
     148        & ar.\ of ptr.\ to imm. val. & @const T * [10]@ & @const T * x[10];@ & @[10] * const T@ & @array(* const T, 10)@ \\
     149        & & @T const * [10]@ & @T const * x[10];@ & @[10] * T const@ & @array(* T const, 10)@ \\
     150        \hline \hline
     151        $\triangleright$ & ptr.\ to ar.\ of val. & @T(*)[10]@ & @T (*x)[10];@ & @* [10] T@ & @* array(T, 10)@ \\
     152        \hline
     153        & imm. ptr.\ to ar.\ of val. & @T(* const)[10]@ & @T (* const x)[10];@ & @const * [10] T@ & @const * array(T, 10)@ \\
     154        \hline
     155        & ptr.\ to ar.\ of imm. val. & @const T(*)[10]@ & @const T (*x)[10];@ & @* [10] const T@ & @* const array(T, 10)@ \\
     156        & & @T const (*) [10]}@ & @T const (*x)[10];@ & @* [10] T const@ & @* array(T, 10) const@ \\
     157        \hline
     158        & ptr.\ to ar.\ of ptr.\ to val. & @T*(*)[10]@ & @T *(*x)[10];@ & @* [10] * T@ & @* array(T * | * T, 10)@ \\
     159        \hline
     160\end{tabular}
     161\caption{Unfortunate Syntactic Reference for Array vs Pointer.  Includes interaction with constness.}
    135162\label{bkgd:ar:usr:avp}
    136 \begin{tabular}{ll|l|l|l}
    137         & Description & \multicolumn{1}{c|}{C} & \multicolumn{1}{c|}{\CFA}  & \multicolumn{1}{c}{\CFA-thesis} \\
    138         \hline
    139         $\triangleright$ & value & @T x;@ & @T x;@ & \\
    140         \hline
    141         & immutable value & @const T x;@ & @const T x;@ & \\
    142         & & @T const x;@ & @T const x;@ & \\
    143         \hline \hline
    144         $\triangleright$ & pointer to value & @T * x;@ & @* T x;@ & \\
    145         \hline
    146         & immutable ptr. to val. & @T * const x;@ & @const * T x;@ & \\
    147         \hline
    148         & ptr. to immutable val. & @const T * x;@ & @* const T x;@ & \\
    149         & & @T const * x;@ & @* T const x;@ & \\
    150         \hline \hline
    151         $\triangleright$ & array of value & @T x[10];@ & @[10] T x@ & @array(T, 10) x@ \\
    152         \hline
    153         & ar.\ of immutable val. & @const T x[10];@ & @[10] const T x@ & @const array(T, 10) x@ \\
    154     & & @T const x[10];@ & @[10] T const x@ & @array(T, 10) const x@ \\
    155         \hline
    156         & ar.\ of ptr.\ to value & @T * x[10];@ & @[10] * T x@ & @array(T *, 10) x@ \\
    157         & & & & @array(* T, 10) x@ \\
    158         \hline
    159         & ar.\ of imm. ptr.\ to val. & @T * const x[10];@ & @[10] const * T x@ & @array(* const T, 10) x@ \\
    160         & & & & @array(const * T, 10) x@ \\
    161         \hline
    162         & ar.\ of ptr.\ to imm. val. & @const T * x[10];@ & @[10] * const T x@ & @array(const T *, 10) x@ \\
    163         & & @T const * x[10];@ & @[10] * T const x@ & @array(* const T, 10) x@ \\
    164         \hline \hline
    165         $\triangleright$ & ptr.\ to ar.\ of value & @T (*x)[10];@ & @* [10] T x@ & @* array(T, 10) x@ \\
    166         \hline
    167         & imm. ptr.\ to ar.\ of val. & @T (* const x)[10];@ & @const * [10] T x@ & @const * array(T, 10) x@ \\
    168         \hline
    169         & ptr.\ to ar.\ of imm. val. & @const T (*x)[10];@ & @* [10] const T x@ & @* const array(T, 10) x@ \\
    170         & & @T const (*x)[10];@ & @* [10] T const x@ & @* array(T, 10) const x@ \\
    171         \hline
    172         & ptr.\ to ar.\ of ptr.\ to val. & @T *(*x)[10];@ & @* [10] * T x@ & @* array(T *, 10) x@ \\
    173         & & & & @* array(* T, 10) x@ \\
    174         \hline
    175 \end{tabular}
    176 \end{table}
     163\end{figure}
     164
     165
     166
     167
    177168
    178169TODO: Address these parked unfortunate syntaxes
Note: See TracChangeset for help on using the changeset viewer.