Declaring arguments to a function

[Jeremy Dunn]

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. I don't care if we start at 1 so
long as that decision is consistently made. An argument list in my mind
is simply another array that must have space allocated for it and so on.
In C if we accept that we must declare the length of string and all
other kinds of arrays then why not be consistent and do it for the
argument array also? It is true that there is no reason why the name,
type and default can't be declared together except that doing them
seperately can result in a decrease in typing, 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.

>We should be writing this language for program writers, not compiler writers. :-)

Oops! I thought I WAS designing for programmers, I certainly have never
written a compiler in my life and wouldn't know where to begin. I
thought my approach was unusual but not frivolous or designed just for
the compiler writer, it more closely followed the way I tended to think
about the situation.

> 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.

> Again, I am having trouble with the whole numeric indexing idea. My
> take on this is borrowed from how zone files work. If you have a
> resource record of this form:
> 
> www.domain.com. IN A 127.0.0.1
>                 IN A 127.0.0.2
> 
> A blank owner (the first item) defaults to the last explicitly stated
> owner. Therefore, www.domain.com would have both 127.0.0.1 and
> 127.0.0.2 as IP addresses. My thought is that an argument declaration
> without a type defaults to the last explicitly stated type. Whether
> this provides more rope for hanging and reduces clarity I am not sure.
> All I can see it saving is some typing. This could also be used to
> handle the case where we have multiple arguments of the same type. We
> state one, then leave the others empty, which means there are of the
> same type as the last specified, and the name is the same but with the
> numeric index tacked onto the end. 

There is nothing wrong with doing it this way and my form has its own
equivalent. I think the thing to do might be to write several
complicated argument declarations in both systems and see how it looks.
For instance, doing it your way we might have something like

double FUNCTION(double X1 optional = 3, int X2, string X3 optional =
"A", int X4){
  <program statements>
}

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 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.

>So, does anyone like any of this? Detest it? I await your insightful
>comments.
> 
>>For the most part, I really like it. My only concerns are essentially
>>semantic, which we can discuss.

Yes, my ONLY concerns are semantic. The way I see it is that all
languages are basically limited by Assembly or Machine Code and can
offer nothing beyond that except packaging. We write other languages
because we want something easier to deal with than Assembly. We want the
language to fit us, not the other way around. I want syntax that either
gives me more control or takes care of more overhead for me and
preferably does both.