Index: doc/papers/general/Paper.tex =================================================================== --- doc/papers/general/Paper.tex (revision 3f8ab8fd359a418186931b162a3db77fcb67e0e6) +++ doc/papers/general/Paper.tex (revision 06b176d95599fd6c07a6847a03edd53e69845911) @@ -2,4 +2,5 @@ \usepackage{fullpage} +\usepackage{epic,eepic} \usepackage{xspace,calc,comment} \usepackage{upquote} % switch curled `'" to straight @@ -36,5 +37,5 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\newcommand{\Textbf}[1]{{\color{red}\textbf{#1}}} +\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}} \newcommand{\TODO}[1]{\textbf{TODO}: {\itshape #1}} % TODO included %\newcommand{\TODO}[1]{} % TODO elided @@ -1079,4 +1080,12 @@ \end{C++} Nesting of member routines in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping. +However, for other aggregate parameters, qualification is necessary: +\begin{cfa} +struct T { double m, n; }; +int C::mem( T & t ) { $\C{// multiple aggregate parameters}$ + c; i; d; $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$ + `t.`m; `t.`n; $\C{// must qualify}$ +} +\end{cfa} % In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided. @@ -1088,5 +1097,5 @@ % \TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.} -\CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers. +To simplify the programmer experience, \CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers. Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block. \begin{cfa} @@ -1101,7 +1110,6 @@ } \end{cfa} -The generality over the object-oriented approach is that multiple aggregate parameters can be opened, not just \lstinline[language=C++]@this@: -\begin{cfa} -struct T { double m, n; }; +with the generality of opening multiple aggregate-parameters: +\begin{cfa} int mem( S & s, T & t ) `with( s, t )` { $\C{// multiple aggregate parameters}$ c; i; d; $\C{\color{red}// s.c, s.i, s.d}$ @@ -1109,10 +1117,38 @@ } \end{cfa} -The equivalent object-oriented approach is: -\begin{cfa} -int S::mem( T & t ) { $\C{// multiple aggregate parameters}$ - c; i; d; $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$ - `t.`m; `t.`n; $\C{// must qualify}$ -} + +In detail, the @with@ clause/statement has the form: +\begin{cfa} +$\emph{with-statement}$: + 'with' '(' $\emph{expression-list}$ ')' $\emph{compound-statement}$ +\end{cfa} +and may appear as the body of a routine or nested within a routine body. +Each expression in the expression-list provides a type and object. +The type must be an aggregate type. +(Enumerations are already opened.) +The object is the implicit qualifier for the open structure-fields. + +All expressions in the expression list are open in ``parallel'' within the compound statement. +This semantic is different from Pascal, which nests the openings. +The difference between parallel and nesting occurs for fields with the same name but different type: +\begin{cfa} +struct S { int i; int j; double m; } s, w; +struct T { int i; int k; int m } t, w; +with( s, t ) { + j + k; $\C{// unambiguous, s.j + t.m}$ + m = 5.0; $\C{// unambiguous, t.m = 5.0}$ + m = 1; $\C{// unambiguous, s.m = 1}$ + int a = s.i + m; $\C{// unambiguous, a = s.i + t.i}$ + int b = s.i + t.i; $\C{// unambiguous, qualification}$ + sout | (double)m | endl; $\C{// unambiguous, cast}$ + i; $\C{// ambiguous}$ +} +\end{cfa} +\CFA's ability to overload variables means usages of field with the same names can be automatically disambiguated, eliminating most qualification. +Qualification or a cast is used to disambiguate. +A cast may be necessary to disambiguate between the overload variables in a @with@ expression: +\begin{cfa} +with( w ) { ... } $\C{// ambiguous, same name and no context}$ +with( (S)w ) { ... } $\C{// unambiguous}$ \end{cfa} @@ -1149,46 +1185,4 @@ \end{cfa} -When opening multiple structures, fields with the same name and type are ambiguous and must be fully qualified. -For fields with the same name but different type, context/cast can be used to disambiguate. -\begin{cfa} -struct S { int i; int j; double m; } a, c; -struct T { int i; int k; int m } b, c; -`with( a, b )` { - j + k; $\C{// unambiguous, unique names define unique types}$ - i; $\C{// ambiguous, same name and type}$ - a.i + b.i; $\C{// unambiguous, qualification defines unique names}$ - m; $\C{// ambiguous, same name and no context to define unique type}$ - m = 5.0; $\C{// unambiguous, same name and context defines unique type}$ - m = 1; $\C{// unambiguous, same name and context defines unique type}$ -} -`with( c )` { ... } $\C{// ambiguous, same name and no context}$ -`with( (S)c )` { ... } $\C{// unambiguous, same name and cast defines unique type}$ -\end{cfa} - -The components in the "with" clause - - with( a, b, c ) { ... } - -serve 2 purposes: each component provides a type and object. The type must be a -structure type. Enumerations are already opened, and I think a union is opened -to some extent, too. (Or is that just unnamed unions?) The object is the target -that the naked structure-fields apply to. The components are open in "parallel" -at the scope of the "with" clause/statement, so opening "a" does not affect -opening "b", etc. This semantic is different from Pascal, which nests the -openings. - -Having said the above, it seems reasonable to allow a "with" component to be an -expression. The type is the static expression-type and the object is the result -of the expression. Again, the type must be an aggregate. Expressions require -parenthesis around the components. - - with( a, b, c ) { ... } - -Does this now make sense? - -Having written more CFA code, it is becoming clear to me that I *really* want -the "with" to be implemented because I hate having to type all those object -names for fields. It's a great way to drive people away from the language. - \subsection{Exception Handling ???} @@ -1204,4 +1198,200 @@ \subsection{Alternative Declaration Syntax} + +\newcommand{\R}[1]{\Textbf{#1}} +\newcommand{\B}[1]{{\Textbf[blue]{#1}}} +\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}} + +C declaration syntax is notoriously confusing and error prone. +For example, many C programmers are confused by a declaration as simple as: +\begin{flushleft} +\lstDeleteShortInline@% +\begin{tabular}{@{}ll@{}} +\begin{cfa} +int * x[5] +\end{cfa} +& +\raisebox{-0.75\totalheight}{\input{Cdecl}} +\end{tabular} +\lstMakeShortInline@% +\end{flushleft} +Is this an array of 5 pointers to integers or a pointer to an array of 5 integers? +The fact this declaration is unclear to many C programmers means there are productivity and safety issues even for basic programs. +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. +For example, a routine returning a pointer to an array of integers is defined and used in the following way: +\begin{cfa} +int `(*`f`())[`5`]` {...}; $\C{// definition}$ + ... `(*`f`())[`3`]` += 1; $\C{// usage}$ +\end{cfa} +Essentially, the return type is wrapped around the routine name in successive layers (like an onion). +While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice. + +\CFA provides its own type, variable and routine declarations, using a different syntax. +The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type. +In the following example, \R{red} is the base type and \B{blue} is qualifiers. +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. +\begin{quote} +\lstDeleteShortInline@% +\lstset{moredelim=**[is][\color{blue}]{+}{+}} +\begin{tabular}{@{}l@{\hspace{3em}}l@{}} +\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ +\begin{cfa} ++[5] *+ `int` x1; ++* [5]+ `int` x2; ++[* [5] int]+ f`( int p )`; +\end{cfa} +& +\begin{cfa} +`int` +*+ x1 +[5]+; +`int` +(*+x2+)[5]+; ++int (*+f`( int p )`+)[5]+; +\end{cfa} +\end{tabular} +\lstMakeShortInline@% +\end{quote} +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 routine parameter. +However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list. +For instance, variables ©x© and ©y© of type pointer to integer are defined in \CFA as follows: +\begin{quote} +\lstDeleteShortInline@% +\begin{tabular}{@{}l@{\hspace{3em}}l@{}} +\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ +\begin{cfa} +`*` int x, y; +\end{cfa} +& +\begin{cfa} +int `*`x, `*`y; +\end{cfa} +\end{tabular} +\lstMakeShortInline@% +\end{quote} +The downside of this semantics is the need to separate regular and pointer declarations: +\begin{quote} +\lstDeleteShortInline@% +\begin{tabular}{@{}l@{\hspace{3em}}l@{}} +\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ +\begin{cfa} +`*` int x; +int y; +\end{cfa} +& +\begin{cfa} +int `*`x, y; + +\end{cfa} +\end{tabular} +\lstMakeShortInline@% +\end{quote} +which is prescribing a safety benefit. +Other examples are: +\begin{quote} +\lstDeleteShortInline@% +\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} +\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ +\begin{cfa} +[ 5 ] int z; +[ 5 ] * char w; +* [ 5 ] double v; +struct s { + int f0:3; + * int f1; + [ 5 ] * int f2; +}; +\end{cfa} +& +\begin{cfa} +int z[ 5 ]; +char * w[ 5 ]; +double (* v)[ 5 ]; +struct s { + int f0:3; + int * f1; + int * f2[ 5 ] +}; +\end{cfa} +& +\begin{cfa} +// array of 5 integers +// array of 5 pointers to char +// pointer to array of 5 doubles + +// common bit field syntax + + + +\end{cfa} +\end{tabular} +\lstMakeShortInline@% +\end{quote} + +All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg: +\begin{quote} +\lstDeleteShortInline@% +\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}} +\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\ +\begin{cfa} +const * const int x; +const * [ 5 ] const int y; +\end{cfa} +& +\begin{cfa} +int const * const x; +const int (* const y)[ 5 ] +\end{cfa} +& +\begin{cfa} +// const pointer to const integer +// const pointer to array of 5 const integers +\end{cfa} +\end{tabular} +\lstMakeShortInline@% +\end{quote} +All declaration qualifiers, \eg ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier} +The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg: +\begin{quote} +\lstDeleteShortInline@% +\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} +\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ +\begin{cfa} +extern [ 5 ] int x; +static * const int y; +\end{cfa} +& +\begin{cfa} +int extern x[ 5 ]; +const int static * y; +\end{cfa} +& +\begin{cfa} +// externally visible array of 5 integers +// internally visible pointer to constant int +\end{cfa} +\end{tabular} +\lstMakeShortInline@% +\end{quote} + +The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©: +\begin{quote} +\lstDeleteShortInline@% +\begin{tabular}{@{}l@{\hspace{3em}}l@{}} +\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ +\begin{cfa} +y = (`* int`)x; +i = sizeof(`[ 5 ] * int`); +\end{cfa} +& +\begin{cfa} +y = (`int *`)x; +i = sizeof(`int * [ 5 ]`); +\end{cfa} +\end{tabular} +\lstMakeShortInline@% +\end{quote} + +Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration. +Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style. +Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.