Changes in / [3cb693c:c1b0b8f]

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 : Thu Jul 25 16:53:43 2024
-%% Update Count     : 6945
+%% Last Modified On : Tue Jul  9 10:43:40 2024
+%% Update Count     : 6887
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -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 disallowed, illustration only
+void f( S & s, char ®c® ) with ( s ) ®with( §\emph{\R{params}}§ )® { // syntax not allowed, 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 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{
+* [ 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{
 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.
-
-
-\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}
+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}
 Here the missing arguments are inserted from the default values in the parameter list.
 The compiler rewrites missing default values into explicit positional arguments.
@@ -3363 +3408 @@
 \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 routines, there are standard or default settings that work for the majority of computations.
+For many of these kinds of 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
@@ -3377 +3422 @@
 Instead, a default value is used, which may not be the programmer's intent.
 
-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}§
+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}§
 \end{cfa}
 The reason for this restriction is to allow separate compilation.
-Multiple prototypes with different default values is undefined.
+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.
 
 Default arguments and overloading \see{\VRef{s:Overloading}} are complementary.
@@ -3392 +3466 @@
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}}   & \multicolumn{1}{c}{\textbf{overloading}}      \\
 \begin{cfa}
-void f( int x, int y = 2, int z = 3 ) {...}
+void p( int x, int y = 2, int z = 3 ) {...}
 
 
@@ -3398 +3472 @@
 &
 \begin{cfa}
-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 ); }
+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 ); }
 \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 is used over default parameters, if the body of the routine is significantly different.
+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}
-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.
+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.