Declaring arguments to a function

[Jeremy Dunn]

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.

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

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

This is a valid point that I didn't consider. This would only be a
problem with functions that say had more than 10 arguments. I suppose
the user could write ((int(X1,X2,X3)) with argument names rather than
the indices but that would repeat the argument names twice. Perhaps with
a very long list of arguments we could write them like
(0-X1,1-X2,2-X3,....N-Xn) where we have the indice next to the name with
a hyphen seperator, this way the user could see immediately which indice
referred to which name. This would only be necessary in functions with
long numbers of arguments, in most cases the user should not need the
indices but could just look. I would say if there are more than 10
arguments then note the indice next to the name.

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

I did not take your comments as criticism, I don't mind criticism so
long as it isn't insulting. There is always the occasion for concern
about processing speed, one has only to boot up Windows and drink coffee
while waiting, to see that. My concern is with the opposite scenario of
what you are talking about. I notice that many programmers that are
guru's are obssessed with speed even when the user would be incapable of
perceiving any performance difference whatsoever. I have written
hundreds of AutoLISP programs for AutoCAD and I have only run across
four situations in many years that I had to go to a higher language to
get acceptable run times. As computer speed goes up, the occasions where
one has to use the sledgehammer diminish. We should always use the tool
that fits the situation and not use a nail gun when we can use a stapler
and vice-versa.

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

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.

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