Declaring arguments to a function

[Peter A. Friend]

On Tue, 15 Jun 1999, Jeremy Dunn wrote:

> On Tue, 15 Jun 1999, Peter Friend wrote:
> > 
> >3. We want to define default values if the argument position is present but empty.
> > 
> >>I have no experience with this kind of functionality. I DO think the
> >>default value idea is useful.
> > 
> >4. We want to define default values if the argument position is not present.
> > 
> >> This makes we wince a bit. I think this would cause problems with
> >> knowing which argument gets the default value and which gets the
> >>specified value.
> 
> I can see why it would make you wince but my example with the Pwr
> function illustrates the distinction I wish to make. Case 3 is
> illustrated by the statement Pwr(x,) and Case 4 is illustrated by
> Pwr(x). Both C and VB will not allow you to write an expression like
> Pwr(x,), they don't like empty arguments. But it is precisely this
> distinction that allowed us to write both squares and cubes succinctly,
> the other languages allow you to do only one.
>  
> > Why do we need to have the programmer state the number of arguments? To
> > me, this sounds like a job for the compiler. Even if there are variable
> > numbers of arguments, you would have to specify these optional
> > arguments in the function declaration, so the total should be
> > available. While C and Java folks like me are used to 0 based arrays,
> > making a programmer use this in a function declaration is asking for
> > off-by-one errors. Also, I think the name, type and default value
> > should all be grouped together. Making the arguments associative
> > arrays is confusing I think.
> 
> I think it would be bad practice to have 0 based arrays everywhere else
> EXCEPT for arguments, don't get me used to one syntax and then make me
> have to remember exceptions to the rule. Your argument could just as
> easily be made for arrays in general.

It was meant to be a general argument about 0 based arrays. I would
NEVER suggest a mix and match approach (yuck). All I saw was one more
place for people to get tripped up, since it is such a common error,
especially with beginning programmers.

> do you want to declare an
> int 6 times in a row or specify it as (int) once? I find that grouping
> them all together often results in having to repeat information
> unnecessarily.

No, I'd rather not, and yes it does require a lot of extra typing. That
is why I suggested using blanks for implicit types.

> > But perhaps I have missed the point. I see a potential problem in
> > situations where you have two consecutive arguments of the same type,
> > but when the function is called one of the arguments is not present.
> > How do we know which of the arguments the supplied value applies to,
> > and which one gets the default value? Are you using the numeric indexes
> > to resolve the ambiguity?
> 
> Yes, the indexes are the only way to be unambiguous.

... and after some coffee this point is clearer.

I have been wondering about the initial arguent, where the number of
arguents is specified. I am not clear whether that is required in your
representation. If not, is it one of those things to force the
programmer to be clear about what he is doing (which is often good)?

> and my way would be
> 
> double FUNCTION(4,
>                 (X1,X2,X3,X4),
>                 (int(1,3),double(0),string(2)),
> 		(3(1),"A"(3))
>                )
> {
>   <program statements>
> }
> 
> I don't know, I see some advantages to doing it my way as the number of
> arguments increases.

I agree with this with regards to having to type all the bloody things
out.

I do know that if I had a lot of long function declarations with your
syntax I would be sitting there with a pen on my monitor, stepping
through them to make sure I had the indexes right. But then, I would
probably wrap some of the stuff in a struct or class anyway.

I think that using the indexes to refer to specific arguments to set
their type, default values, and such is concise, but I wonder if from a
documentation standpoint it is better to do that or set these values by
referring to the variable name. It is more typing, but 6 months later,
when the code has to be changed, will I be wondering why I set the
default of a certain index to A? I don't know if seeing the name
associated with the default value instead of having to step through the
argument name list is will be clearer or not.

> > I think the ability to programmatically determine the number and type
> > of arguments supplied to your function at runtime is exceedingly
> > useful. My only concern is with space and speed. It seems that these
> > days with all of the information hiding going on and global variables
> > being evil we are supposed to be passing everything to functions
> > directly. This is fine, but the more arguments you have, the more stack
> > space you are going to require upon function entry and exit. This also
> > takes time. If we are going to be passing objects by reference (I
> > assume we are), then this really isn't an issue.
> 
> Space and speed. Well if you want speed write Assembly code! How much
> speed do you need? Computers are getting up to 500Mhz now and speed is
> becoming less and less of an issue. I don't think my argument syntax is
> going to make much difference space or speed-wise. I would think
> defining a paramarray like in VB or the equivalent in C is going to take
> more time and space than if the user explcitly declares a specific
> number of inputs.

Reading all of the stuff about long argument lists just got me thinking
about the direction that software engineering seems to be going. It was
not meant as a criticism of your syntax, just something that has been
bothering me lately. Some people I work with think that processor
speed is a panacea, and optimization is NEVER worth their time.

Peter


---
Software Engineer
EarthLink Network