Re: Optional arguments in nested subroutines



In article
<FiVAh.49985$2m6.18237@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"James Giles" <jamesgiles@xxxxxxxxxxxxxxxx> wrote:

Although not all arguments are named particularly well. Consider
the SIGN function. SIGN(A=P, B=Q) isn't anywhere near as
clear as SIGN(MAG=Q,SGN=P) - or is it the ohter way around?
I always have to look it up.

I sometimes get that one right because I remember it is exactly the
*opposite* of the way it should be. :-) However, I almost always
look it up to make sure. If someone uses a feature of the language
for 30+ years, and still must consult a reference book to see if he
is getting it right, then it almost certainly means that it was
poorly designed.

Here is the way I think SIGN() should have been written. First,
there should be a 1-argument version SIGN(X) that returns simply
+1.0 or -1.0 of the appropriate kind. Then there should be an
optional argument, call it FACTOR if you want, where the function
could be invoked as SIGN(X,FACTOR=Y) or as SIGN(X,Y) which returns
SIGN(X)*ABS(FACTOR). Obviously SIGN(X) is a short form of writing
SIGN(X,1.0_correct_kind) or SIGN(X,FACTOR=1.0_correct_kind).

This, of course, is the *opposite* to the way the 2-argument fortran
SIGN() function really works, and there is no 1-argument version.
So if you just think of it in the logical way, and reverse the
arguments, then you can get it right without looking it up.

$.02 -Ron Shepard
.