Changeset d02d223 for doc/user

Timestamp:

Jul 25, 2024, 4:59:34 PM (4 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

3cb693c

Parents:

878b1385

Message:

rewrite section on default/named parameters

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 : Thu Jul 25 16:53:43 2024
+%% Update Count     : 6945
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -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 provides 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 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}
 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 +3363 @@
 \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 +3377 @@
 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 +3392 @@
 \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 +3398 @@
 &
 \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.
+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, 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.
+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;
+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 arguments;
 \Index*{Ada} supports both named and default arguments.