Variable Length Array Passing, summary of proposals
uunet!cwi.nl!Dik.Winter
uunet!cwi.nl!Dik.Winter
Mon Dec 23 17:50:03 PST 1991
Many of the points Richard Stallman is making require pondering. He
is right in many cases. In order to pass dimensions through to a
routine there should not be a need to change semantical issues.
E.g.:
int foo(float a[n], int n)
what n should be used in the dimensioning? A previously declared one?
And if not, why not in this case? How is this different from:
int foo(float a[n], int m)
?
What I think is the best proposed syntax is:
int foo(float a[int n])
where n is a implicitly declared parameter, (and note emphasis):
*That should also be passed implicitly*.
This requires prototypes, I have no problem there. So in the context:
float par[1000];
...
foo(par);
the implicitly passed parameter for n is 1000. (And if the parameter
passed is of variable dimension, the actual dimension is passed.)
This more closely follows the way choosen by other higher order languages.
There are disadvantages:
1. You can not pass a pointer to foo. I have no problems with that.
If arrays are made first-class citizens, make them first-class
citizens.
2. You can not do the Fortran trick of looking at an array in different
ways. This gives subroutine bloat (look at the BLAS). But this has
been solved long ago for languages like Algol 60.
But, both disadvantages can be solved by an appropriate cast at the calling
side. Some extension is needed at that end, but in the above context the
call:
foo((float[500])par);
might just as well pass an implicit parameter for n of 500 (and par can be
a pointer, a differently sized array, or what you want).
I think this is better, both for compiler writers and for users. The compiler
has ways to know the declared size of an array. For the user it is much
cleaner to write something like:
saxpy(a, (float[5:15])x, (float[10:15])y);
in stead of:
SAXPY(A, X[5], Y[10], 15)
(Yes, there must still be some thought about the call side.)
dik
--
Let's forget the Fortran usage of passing dimensions explicitly. I have had
enough of LDA's.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland
dikacwi.nl
More information about the Numeric-interest
mailing list