Changeset ce02877 for doc/user

Timestamp:

Jul 29, 2024, 1:32:51 PM (14 months ago)

Author:

JiadaL <j82liang@…>

Branches:

master

Children:

f3d2a4f

Parents:

38e20a80 (diff), 1661ad7 (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.

Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:

• doc/user/user.tex (modified) (7 diffs)

doc/user/user.tex

@@ -11 +11 @@
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
-%% Last Modified On : Tue Jul  9 10:43:40 2024
-%% Update Count     : 6887
+%% Last Modified On : Fri Jul 26 06:56:11 2024
+%% Update Count     : 6955
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -1598 +1598 @@
 and implicitly opened \emph{after} a function-body open, to give them higher priority:
 \begin{cfa}
-void f( S & s, char ®c® ) with ( s ) ®with( §\emph{\R{params}}§ )® { // syntax not allowed, illustration only
+void f( S & s, char ®c® ) with ( s ) ®with( §\emph{\R{params}}§ )® { // syntax disallowed, illustration only
         s.c = ®c;®  i = 3;  d = 5.5;
 }
@@ -3313 +3313 @@
 for example, the following is incorrect:
 \begin{cfa}
-* [ int x ] f () fp; §\C{// routine name "f" is not allowed}§
-\end{cfa}
-
-
-\section{Named and Default Arguments}
-
-Named\index{named arguments}\index{arguments!named} and default\index{default arguments}\index{arguments!default} arguments~\cite{Hardgrave76}\footnote{
+* [ int x ] f () fp; §\C{// routine name "f" is disallowed}§
+\end{cfa}
+
+
+\section{Default and Named Parameter}
+
+Default\index{default parameter}\index{parameter!default} and named\index{named parameter}\index{parameter!named} parameters~\cite{Hardgrave76}\footnote{
 Francez~\cite{Francez77} proposed a further extension to the named-parameter passing style, which specifies what type of communication (by value, by reference, by name) the argument is passed to the routine.}
 are two mechanisms to simplify routine call.
-Both mechanisms are discussed with respect to \CFA.
-\begin{description}
-\item[Named (or Keyword) Arguments:]
-provide the ability to specify an argument to a routine call using the parameter name rather than the position of the parameter.
-For example, given the routine:
-\begin{cfa}
-void p( int x, int y, int z ) {...}
-\end{cfa}
-a positional call is:
-\begin{cfa}
-p( 4, 7, 3 );
-\end{cfa}
-whereas a named (keyword) call may be:
-\begin{cfa}
-p( z : 3, x : 4, y : 7 );  §\C{// rewrite \(\Rightarrow\) p( 4, 7, 3 )}§
-\end{cfa}
-Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
-The compiler rewrites a named call into a positional call.
-The advantages of named parameters are:
-\begin{itemize}
-\item
-Remembering the names of the parameters may be easier than the order in the routine definition.
-\item
-Parameter names provide documentation at the call site (assuming the names are descriptive).
-\item
-Changes can be made to the order or number of parameters without affecting the call (although the call must still be recompiled).
-\end{itemize}
-
-Unfortunately, named arguments do not work in C-style programming-languages because a routine prototype is not required to specify parameter names, nor do the names in the prototype have to match with the actual definition.
-For example, the following routine prototypes and definition are all valid.
-\begin{cfa}
-void p( int, int, int ); §\C{// equivalent prototypes}§
-void p( int x, int y, int z );
-void p( int y, int x, int z );
-void p( int z, int y, int x );
-void p( int q, int r, int s ) {} §\C{// match with this definition}§
-\end{cfa}
-Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
-Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports.
-The former is easy to do, while the latter is more complex.
-
-Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching.
-For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site:
-\begin{cfa}
-int f( int i, int j );
-int f( int x, double y );
-
-f( j : 3, i : 4 ); §\C{// 1st f}§
-f( x : 7, y : 8.1 ); §\C{// 2nd f}§
-f( 4, 5 );  §\C{// ambiguous call}§
-\end{cfa}
-However, named arguments compound routine resolution in conjunction with conversions:
-\begin{cfa}
-f( i : 3, 5.7 ); §\C{// ambiguous call ?}§
-\end{cfa}
-Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
-Adding named argument into the routine resolution algorithm does not seem worth the complexity.
-Therefore, \CFA does \emph{not} attempt to support named arguments.
-
-\item[Default Arguments]
-provide the ability to associate a default value with a parameter so it can be optionally specified in the argument list.
-For example, given the routine:
-\begin{cfa}
-void p( int x = 1, int y = 2, int z = 3 ) {...}
-\end{cfa}
-the allowable positional calls are:
-\begin{cfa}
-p(); §\C{// rewrite \(\Rightarrow\) p( 1, 2, 3 )}§
-p( 4 ); §\C{// rewrite \(\Rightarrow\) p( 4, 2, 3 )}§
-p( 4, 4 ); §\C{// rewrite \(\Rightarrow\) p( 4, 4, 3 )}§
-p( 4, 4, 4 ); §\C{// rewrite \(\Rightarrow\) p( 4, 4, 4 )}§
-// empty arguments
-p(  , 4, 4 ); §\C{// rewrite \(\Rightarrow\) p( 1, 4, 4 )}§
-p( 4,  , 4 ); §\C{// rewrite \(\Rightarrow\) p( 4, 2, 4 )}§
-p( 4, 4,   ); §\C{// rewrite \(\Rightarrow\) p( 4, 4, 3 )}§
-p( 4,  ,   ); §\C{// rewrite \(\Rightarrow\) p( 4, 2, 3 )}§
-p(  , 4,   ); §\C{// rewrite \(\Rightarrow\) p( 1, 4, 3 )}§
-p(  ,  , 4 ); §\C{// rewrite \(\Rightarrow\) p( 1, 2, 4 )}§
-p(  ,  ,   ); §\C{// rewrite \(\Rightarrow\) p( 1, 2, 3 )}§
-\end{cfa}
+
+
+\subsection{Default}
+
+A default parameter associates a default value with a parameter so it can be optionally specified in the argument list.
+For example, given the routine prototype:
+\begin{cfa}
+void f( int x ®= 1®, int y ®= 2®, int z ®= 3® );
+\end{cfa}
+allowable calls are:
+\begin{cquote}
+\setlength{\tabcolsep}{0.75in}
+\begin{tabular}{@{}ll@{}}
+\textbf{positional arguments} & \textbf{empty arguments} \\
+\begin{cfa}
+f();                    §\C[0.75in]{// rewrite \(\Rightarrow\) f( 1, 2, 3 )}§
+f( 4 );                 §\C{// rewrite \(\Rightarrow\) f( 4, 2, 3 )}§
+f( 4, 4 );              §\C{// rewrite \(\Rightarrow\) f( 4, 4, 3 )}§
+f( 4, 4, 4 );   §\C{// rewrite \(\Rightarrow\) f( 4, 4, 4 )}\CRT§
+
+
+
+\end{cfa}
+&
+\begin{cfa}
+f( ®?®, 4, 4 );         §\C[1.0in]{// rewrite \(\Rightarrow\) f( 1, 4, 4 )}§
+f( 4, ®?®, 4 );         §\C{// rewrite \(\Rightarrow\) f( 4, 2, 4 )}§
+f( 4, 4, ®?® );         §\C{// rewrite \(\Rightarrow\) f( 4, 4, 3 )}§
+f( 4, ®?®, ®?® );       §\C{// rewrite \(\Rightarrow\) f( 4, 2, 3 )}§
+f( ®?®, 4, ®?® );       §\C{// rewrite \(\Rightarrow\) f( 1, 4, 3 )}§
+f( ®?®, ®?®, 4 );       §\C{// rewrite \(\Rightarrow\) f( 1, 2, 4 )}§
+f( ®?®, ®?®, ®?® );     §\C{// rewrite \(\Rightarrow\) f( 1, 2, 3 )}\CRT§
+\end{cfa}
+\end{tabular}
+\end{cquote}
+where the ©?© selects the default value as the argument.
 Here the missing arguments are inserted from the default values in the parameter list.
 The compiler rewrites missing default values into explicit positional arguments.
@@ -3408 +3364 @@
 \item
 Routines with a large number of parameters are often very generalized, giving a programmer a number of different options on how a computation is performed.
-For many of these kinds of routines, there are standard or default settings that work for the majority of computations.
+For many of these routines, there are standard or default settings that work for the majority of computations.
 Without default values for parameters, a programmer is forced to specify these common values all the time, resulting in long argument lists that are error prone.
 \item
@@ -3422 +3378 @@
 Instead, a default value is used, which may not be the programmer's intent.
 
-Default values may only appear in a prototype versus definition context:
-\begin{cfa}
-void p( int x, int y = 2, int z = 3 ); §\C{// prototype: allowed}§
-void p( int, int = 2, int = 3 ); §\C{// prototype: allowed}§
-void p( int x, int y = 2, int z = 3 ) {} §\C{// definition: not allowed}§
+Default parameters may only appear in a prototype versus definition context:
+\begin{cfa}
+void f( int x, int y = 2, int z = 3 );  §\C{// prototype: allowed}§
+void f( int, int = 2, int = 3 );                §\C{// prototype: allowed}§
+void f( int x, int y = 2, int z = 3 ) ®{}® §\C{// definition: disallowed}§
 \end{cfa}
 The reason for this restriction is to allow separate compilation.
-Multiple prototypes with different default values is an error.
-\end{description}
-
-Ellipse (``...'') arguments present problems when used with default arguments.
-The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities:
-\begin{cfa}
-p( /* positional */, ... , /* named */ );
-p( /* positional */, /* named */, ... );
-\end{cfa}
-While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:
-\begin{cfa}
-p( int x, int y, int z, ... );
-p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
-p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
-\end{cfa}
-In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin.
-Hence, this approach seems significantly more difficult, and hence, confusing and error prone.
-In the second call, the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
-
-The problem is exacerbated with default arguments, \eg:
-\begin{cfa}
-void p( int x, int y = 2, int z = 3... );
-p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
-p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
-\end{cfa}
-The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
-therefore, argument 5 subsequently conflicts with the named argument z : 3.
-In the second call, the default value for y is implicitly inserted after argument 1 and the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
-For these reasons, \CFA requires named arguments before ellipse arguments.
-Finally, while ellipse arguments are needed for a small set of existing C routines, like ©printf©, the extended \CFA type system largely eliminates the need for ellipse arguments \see{\VRef{s:Overloading}}, making much of this discussion moot.
+Multiple prototypes with different default values is undefined.
 
 Default arguments and overloading \see{\VRef{s:Overloading}} are complementary.
@@ -3466 +3393 @@
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}}   & \multicolumn{1}{c}{\textbf{overloading}}      \\
 \begin{cfa}
-void p( int x, int y = 2, int z = 3 ) {...}
+void f( int x, int y = 2, int z = 3 ) {...}
 
 
@@ -3472 +3399 @@
 &
 \begin{cfa}
-void p( int x, int y, int z ) {...}
-void p( int x ) { p( x, 2, 3 ); }
-void p( int x, int y ) { p( x, y, 3 ); }
+void f( int x, int y, int z ) {...}
+void f( int x ) { f( x, 2, 3 ); }
+void f( int x, int y ) { f( x, y, 3 ); }
 \end{cfa}
 \end{tabular}
 \end{cquote}
 the number of required overloaded routines is linear in the number of default values, which is unacceptable growth.
-In general, overloading should only be used over default arguments if the body of the routine is significantly different.
-Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
-\begin{cfa}
-p( 1, /* default */, 5 ); §\C{// rewrite \(\Rightarrow\) p( 1, 2, 5 )}§
-\end{cfa}
-
-Given the \CFA restrictions above, both named and default arguments are backwards compatible.
-\Index*[C++]{\CC{}} only supports default arguments;
-\Index*{Ada} supports both named and default arguments.
+In general, overloading is used over default parameters, if the body of the routine is significantly different.
+Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list.
+\begin{cfa}
+f( 1, ®?®, 5 );                                                 §\C{// rewrite \(\Rightarrow\) f( 1, 2, 5 )}§
+\end{cfa}
+
+
+\subsection{Named (or Keyword)}
+
+A named (keyword) parameter provides the ability to specify an argument to a routine call using the parameter name rather than the position of the parameter.
+For example, given the routine prototype:
+\begin{cfa}
+void f( int ®?®x, int ®?®y, int ®?®z );
+\end{cfa}
+allowable calls are:
+\begin{cfa}
+f( ?x = 3, ?y = 4, ?z = 5 );                    §\C{// rewrite \(\Rightarrow\) f( 3, 4, 5 )}§
+f( ?y = 4, ?z = 5, ?x = 3 );                    §\C{// rewrite \(\Rightarrow\) f( 3, 4, 5 )}§
+f( ?z = 5, ?x = 3, ?y = 4 );                    §\C{// rewrite \(\Rightarrow\) f( 3, 4, 5 )}§
+f( ?x = 3, ?z = 5, ?y = 4 );                    §\C{// rewrite \(\Rightarrow\) f( 3, 4, 5 )}§
+\end{cfa}
+Here the ordering of the the parameters and arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
+The compiler rewrites a named call into a positional call.
+Note, the syntax ©?x = 3© is necessary for the argument, because ©x = 3© has an existing meaning, \ie assign ©3© to ©x© and pass the value of ©x©.
+The advantages of named parameters are:
+\begin{itemize}
+\item
+Remembering the names of the parameters may be easier than the order in the routine definition.
+\item
+Parameter names provide documentation at the call site (assuming the names are descriptive).
+\item
+Changes can be made to the order or number of parameters without affecting the call (although the call must still be recompiled).
+\end{itemize}
+
+Named parameters may only appear in a prototype versus definition context:
+\begin{cfa}
+void f( int  x, int ?y, int ?z );               §\C{// prototype: allowed}§
+void f( int ?x, int , int ?z );                 §\C{// prototype: allowed}§
+void f( int x, int ?y, int ?z ) ®{}®    §\C{// definition: disallowed}§
+\end{cfa}
+The reason for this restriction is to allow separate compilation.
+Multiple prototypes with different positional parameter names is an error.
+
+The named parameter is not part of type resolution;
+only the type of the expression assigned to the named parameter affects type resolution.
+\begin{cfa}
+int f( int ?i, int ?j );
+int f( int ?i, double ?j );
+f( ?j = 3, ?i = 4 );                                    §\C{// 1st f}§
+f( ?i = 7, ?j = 8.1 );                                  §\C{// 2nd f}§
+\end{cfa}
+
+
+\subsection{Mixed Default/Named}
+
+Default and named parameters can be intermixed and named parameters can have a default value.
+For example, given the routine prototype:
+\begin{cfa}
+void f( int x, int y ®= 1®, int ®?®z ®= 2® );
+\end{cfa}
+allowable calls are:
+\begin{cfa}
+f( 3 );                                                                 §\C{// rewrite \(\Rightarrow\) f( 3, 1, 2 )}§
+f( 3, 4 );                                                              §\C{// rewrite \(\Rightarrow\) f( 3, 4, 2 )}§
+f( 3, ?z = 5 );                                                 §\C{// rewrite \(\Rightarrow\) f( 3, 1, 5 )}§
+f( 3, 4, ?z = 5 );                                              §\C{// rewrite \(\Rightarrow\) f( 3, 4, 5 )}§
+f( ?z = 5, 3 );                                                 §\C{// rewrite \(\Rightarrow\) f( 3, 1, 5 )}§
+f( 3, ?z = 5, 4 );                                              §\C{// rewrite \(\Rightarrow\) f( 3, 4, 5 )}§
+\end{cfa}
+Finally, the ellipse (``...'') parameter must appear after positional and named parameters in a routine prototype.
+\begin{cfa}
+void f( int i = 1, int ?j = 2, ®...® );
+\end{cfa}
+
+\CFA named and default arguments are backwards compatible with C.
+\Index*[C++]{\CC{}} only supports default parameters;
+\Index*{Ada} supports both named and default parameters.