Changeset dd37afa for doc


Ignore:
Timestamp:
Apr 8, 2024, 9:13:57 PM (7 months ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
master
Children:
0bbe172
Parents:
cb98d9d
Message:

more work on Figure 2.1 and surrounding text

File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/theses/mike_brooks_MMath/background.tex

    rcb98d9d rdd37afa  
    6565\end{itemize}
    6666
    67 The following sections introduce the many layers of the C array story, concluding with an \emph{Unfortunate Syntactic Reference}.
    68 It shows how to define (spell) the types under discussion, along with interactions with orthogonal (but easily confused) language features.
    69 Alternate spellings are listed within a row.
    70 The simplest occurrences of types distinguished in the preceding discussion are marked with $\triangleright$.
    71 The 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).
    72 The 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 
    74 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!
    75 
    76 
    77 \CFA-specific spellings (not yet introduced) are also included here for referenceability; these can be skipped on linear reading.
    78 The \CFA-C column gives the, more fortunate, ``new'' syntax of section TODO, for spelling \emph{exactly the same type}.
    79 This fortunate syntax does not have different spellings for types vs declarations;
    80 a declaration is always the type followed by the declared identifier name;
    81 for 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}
    85 The \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 
    87 Another 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.
    88 For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    89 \begin{cfa}
    90 int @(*@f@())[@5@]@ {...}; $\C{// definition}$
    91  ... @(*@f@())[@3@]@ += 1; $\C{// usage}$
    92 \end{cfa}
    93 Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
     67
     68\section{Reading Declarations}
     69
     70A 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}
     75int @(*@ar@)[@5@]@; // definition
     76  ... @(*@ar@)[@3@]@ += 1; // usage
     77\end{cfa}
     78&
     79\begin{cfa}
     80int @(*@f@())[@5@]@ { ... }; // definition
     81  ... @(*@f@())[@3@]@ += 1; // usage
     82\end{cfa}
     83\end{tabular}
     84\end{cquote}
     85Essentially, the type is wrapped around the name in successive layers (like an \Index{onion}).
    9486While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice, even though Dennis Richie believed otherwise:
    9587\begin{quote}
    9688In 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}
    9789\end{quote}
     90After 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!
    9891
    9992\CFA provides its own type, variable and routine declarations, using a different syntax.
    10093The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
    101 In the following example, {\color{red}red} is the base type and {\color{blue}blue} is qualifiers.
    102 The \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.
     94The qualifiers have the same meaning in \CFA as in C.
     95Hence, a \CFA declaration is read left to right, where a function return type is enclosed in brackets @[]@.
    10396\begin{cquote}
    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]#;
     97\begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
     98\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C}}   & \multicolumn{1}{c}{\textbf{\CFA}} &   \\
     99\begin{cfa}
     100int @*@ x1 @[5]@;
     101int @(*@x2@)[5]@;
     102int @(*@f( int p )@)[5]@;
    110103\end{cfa}
    111104&
    112 \begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
    113 #[5] *# @int@ x1;
    114 #* [5]# @int@ x2;
    115 #[* [5] int]# f@( int p )@;
    116 \end{cfa}
     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}
    117119\end{tabular}
    118120\end{cquote}
    119 
    120 \VRef[Figure]{bkgd:ar:usr:avp} gives this reference for the discussion so far.
    121 
    122 \begin{figure}
     121As declaration complexity increases, it becomes corresponding difficult to read and understand the C declaration form.
     122Note, 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}.
     125The \CFA-thesis column shows the new array declaration form, which is my contributed improvements for safety and ergonomics.
     126The 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.
     127Each row of the table shows alternate syntactic forms.
     128The simplest occurrences of types distinguished in the preceding discussion are marked with $\triangleright$.
     129Removing 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)}.
     130Unfortunately, parameter declarations \PAB{(section TODO)} have more syntactic forms and rules.
     131
     132\begin{table}
    123133\centering
    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@ & \\
     134\caption{Syntactic Reference for Array vs Pointer. Includes interaction with constness.}
     135\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;@ & \\
    131143        \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@ & \\
     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;@ & \\
    138150        \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)@ \\
     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@ \\
    150164        \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)@ \\
     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@ \\
    159174        \hline
    160175\end{tabular}
    161 \caption{Unfortunate Syntactic Reference for Array vs Pointer.  Includes interaction with constness.}
    162 \label{bkgd:ar:usr:avp}
    163 \end{figure}
    164 
    165 
    166 
    167 
     176\end{table}
    168177
    169178TODO: Address these parked unfortunate syntaxes
Note: See TracChangeset for help on using the changeset viewer.