Declaring arguments to a function

[Jeremy Dunn]

"Peter A. Friend" wrote:

>> Obviously it is not NECESSARY that the programmer explicitly state
the
>> number of arguments since we are already getting away with not doing
it,
>> but I do think it would add some clarity. 6 says that you MUST have 6
>> arguments, (>1,<7) means you MUST have more than 1 argument and no
more
>> than 6. This will affect whether you get errors or not.

>Oh I get it now. So, we can control the min/max number of arguments. So
>what do you think of being able to specify WHICH arguments are
>required?

I believe at this point that we CAN specify which arguments are
required. We know the number of arguments input, we know which indices
are empty or full, we know what every indice's type is and we have
control of the max/min number of arguments. Are we missing anything for
complete control? I would think this would provide enough information
for the programmer to control the program flow to allow only the right
combination of inputs.

> >
> > double|bool FUNCTION (){
> >   <statements>
> > }
> 
> This one raised my eyebrows.
> 
> The type returned is determined by the arguments and the code, but
> during compilation, we need to check the type of the variable that the
> function output is being assigned to. Now, the type we return may be
> determined by factors that are only known at runtime, so the compiler
> may be unable to type-check this. I think our options are to restrict
> how the multiple return type can be used, or throw an exception at
> runtime if there is a type mismatch. Just thinking about the casting
> issues involved with this could blow my whole work day...

VB would use the type VARIANT to handle the situation I described but I
thought it would be nicer for the programmer to somehow see explicitly
what types the function can return. Perhaps we can think of this as a
conceptual aid, we see all the types stated but the compiler just sees
it as VARIANT and acts accordingly.


> > Another example, let us say that the function NumList(X,Y,Z) returns a
> > list of numbers where X is the start number, Y is the number of terms
> > and Z is the increment i.e. NumList(2,3,2) would return (2,4,6).
> > Wouldn't it be nice to have this function react differently to a string
> > number and give us a list of incremented strings so that the expression
> > NumList("2",3,2) would return ("2","4","6")? Ergo we need to declare two
> > different types for the first argument.
> 
> By that last sentence are you referring to function overloading? If so,
> do we want to follow the common method of separate declarations for
> each, or do we want a facility for doing it all within a single
> function body?

Yes, function overloading. Obviously I favor doing things in one shot
but I may be outvoted. I also liked LISP syntax better than C syntax and
I am outvoted on that one too.

> > I also see that we need another system function called ArgumentTypes()
> > that returns a list of the type of argument at each indice i.e. it would
> > return a list like (int,double,int,int,void,...). This would further
> > increase our ability to control input and decision making. So now our
> > complement of functions include
> >               NumberOfArguments()- returns the number of argument slots available
> >               EmptyArguments()   - returns list of indices that have no input
> >               FullArguments()    - returns list of indices that have an input of
> > some type
> >               ArgumentTypes()    - returns actual input type for each index
> 
> Unrelated to functions, this reminded me how useful I have found the
> instanceof operator in Java.

Don't know a thing about Java, never messed with it. I guess I will have
to check it out soon.