Declaring arguments to a function

[Peter A. Friend]

On Wed, 16 Jun 1999, Jeremy Dunn wrote:

> 
> 
> Peter A. Friend wrote:
>  
> > 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)?
> 
> 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 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 suppose this is true, I guess it comes down to doing a study of
> looking at all kinds of programs that you and I and others have written
> and ask ourselves what an average number of arguments is that goes into
> a typical function and how often this will really be a problem. I would
> say that typically I write functions with less than 10 arguments with an
> occasional doozy that might need 30. What has your experience been?

After some thought, I realized that before I started doing GUI work in
Java I NEVER had a function with more than 10 arguments. Even in the
GUI work  those large ones are a rare occurrence. So in my case, it
isn't an issue.

> Something else I didn't think about in all this discussing of arguments
> is when we wish the return type of the function to be more than one type
> or if when we want an argument to be of more than one type. We might
> want to declare something like
> 
> 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...

> where the function may return either type depending on how the function
> reacts to the arguments we input to the function. Similarly, (in my
> syntax) we want the user to be able to declare an indice more than once
> for the type settings. An example, let us have a function called
> Approx() that behaves as follows
> 		Approx(X)      this rounds X up to the nearest integer
> 		Approx(X,Y)    this rounds X to Y places
> 		Approx(X,Y,Z)  this returns TRUE if X=Y to within +-Z
> 		Approx(X,Y,Z,) if X=Y to within +-Z then X is returned
> 
> It is clear the above function needs to be able to return both double
> and bool values. Similarly we wish to write functions that can take
> different input types and react differently depending on what they get.
> 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?

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

Peter


---
Software Engineer
EarthLink Network