Index: doc/user/user.tex =================================================================== --- doc/user/user.tex (revision 878b1385fe27c9319958bdb5da85d88798f2768b) +++ doc/user/user.tex (revision d02d223749b5d23ea78e8a77adfb55e33cabf249) @@ -11,6 +11,6 @@ %% 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,5 +1598,5 @@ 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,93 +3313,48 @@ 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,5 +3363,5 @@ \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,41 +3377,12 @@ 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,5 +3392,5 @@ \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,18 +3398,86 @@ & \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.