Fortran - F2007 possible improvement

Author

F2007 possible improvement

John Harper

2004-10-27, 8:57 pm

I have long been in the habit of declaring functions that return scalars
with their type in the FUNCTION statement (rather than in a separate
statement after it), but there seems no way in f95 or f2003 to do that
if the function returns an array. May I suggest that
DIMENSION(array-spec) be allowed in a FUNCTION statement in the
next revision of the standard, so one could write things like
REAL, DIMENSION(n) :: FUNCTION f(x)
instead of the currently valid
FUNCTION f(x)
REAL, DIMENSION(n) :: f
It would mean the same as that, and have the same restrictions on n.

I'd be even happier if the syntax could be like this:
REAL,DIMENSION(n) FUNCTION f(x)
or even
REAL DIMENSION(n) FUNCTION f(x)
by analogy with the way PURE, RECURSIVE and ELEMENTAL are treated now.
COMPLEX, INTEGER, LOGICAL, CHARACTER, TYPE and kind could fit in as
they do now, I think.
Clearly one couldn't use REAL(n) FUNCTION f(x) for this purpose because
n there specifies the kind, and REAL FUNCTION f(x)(n) would require
thought about which (...) does what, like CHARACTER c(m)*(n) does now.

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Paul Van Delst

2004-10-28, 3:59 pm

John Harper wrote:
> I have long been in the habit of declaring functions that return scalars
> with their type in the FUNCTION statement (rather than in a separate
> statement after it), but there seems no way in f95 or f2003 to do that
> if the function returns an array. May I suggest that
> DIMENSION(array-spec) be allowed in a FUNCTION statement in the
> next revision of the standard, so one could write things like
> REAL, DIMENSION(n) :: FUNCTION f(x)
> instead of the currently valid
> FUNCTION f(x)
> REAL, DIMENSION(n) :: f
> It would mean the same as that, and have the same restrictions on n.
>
> I'd be even happier if the syntax could be like this:
> REAL,DIMENSION(n) FUNCTION f(x)
> or even
> REAL DIMENSION(n) FUNCTION f(x)
> by analogy with the way PURE, RECURSIVE and ELEMENTAL are treated now.

Not that I'm necessarily arguing against the change/addition you're proposing, but PURE,
RECURSIVE and ELEMENTAL are clauses. DIMENSION is an attribute. I'm not a lexical lawyer
so distinguishing between these may not be a big deal -- but I doubt it. :o)

And, from the other side of the argument, I've always been in the habit of doing the
opposite of what you do wrt function declarations - whether or not the result is a scalar.
In fact, I use the RESULT clause for nearly every function, e.g.
FUNCTION f(x) RESULT (y)
REAL, INTENT( IN ) :: x
REAL, :: y
.....
or
FUNCTION f(x) RESULT (y)
REAL, DIMENSION(:), INTENT( IN ) :: x
REAL, DIMENSION(SIZE(x)) :: y
.....
Same dog different leg I reckon (but I'll admit I am a verbose typer.)

cheers,

paulv

p.s. My last example above got me thinking. If you could do something like:

REAL DIMENSION(SIZE(x)) FUNCTION f(x) RESULT (y)
REAL, DIMENSION(:), INTENT( IN ) :: x
......
wouldn't you need the dummy arg "x" to be declared before you used it in a SIZE() for the
function decl? After seeing it written out like above, my personal preference now tends
even more strongly to the current syntax. It just looks easier to read to me. (Sorry.)

James Giles

2004-10-28, 3:59 pm

John Harper wrote:
> I have long been in the habit of declaring functions that return scalars
> with their type in the FUNCTION statement (rather than in a separate
> statement after it), but there seems no way in f95 or f2003 to do that
> if the function returns an array. May I suggest that
> DIMENSION(array-spec) be allowed in a FUNCTION statement in the
> next revision of the standard, so one could write things like
> REAL, DIMENSION(n) :: FUNCTION f(x)
> instead of the currently valid
> FUNCTION f(x)
> REAL, DIMENSION(n) :: f
> It would mean the same as that, and have the same restrictions on n.

I think the declaration of function result types in the function
statement itself should be discouraged. So, adding yet additional
features to the syntax should be avoided. (Of course, I also think
*all* uses of the DIMENSION keyword should also be discouraged.)

And, in reference to another response on this thread, I think the use
of the RESULT clause for non-recursive functions should be avoided.
In fact, I always thought that the RECURSIVE keyword on the
declaration should have the result variable named with it:

recursive(abc) function xyz(args)

This declares a function xyz whose result is called abc within the
function itself. And, it shouldn't make any difference which (abc or
xyz) you declare in the code. With this syntax there would never
be a need for a RESULT clause, and the whole feature could have
been avoided.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Richard E Maine

2004-10-28, 3:59 pm

"James Giles" <jamesgiles@worldnet.att.net> writes:

> I think the declaration of function result types in the function
> statement itself should be discouraged. So, adding yet additional
> features to the syntax should be avoided. (Of course, I also think
> *all* uses of the DIMENSION keyword should also be discouraged.)

My personal style agrees with you (Giles) on all of the above
points. But I've noticed that these choices are far from universal,
even among expert users. Thus I don't tend to push my style
choices very hard on those items.

On the other hand, I'm not going to sign up as an advocate for
extending styles that I don't like either. I'd end up more in
the camp of "would slightly prefer not to add such things, but
won't object too much".

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Walter Spector

2004-10-31, 3:56 pm

James Giles wrote:
> ...
> And, in reference to another response on this thread, I think the use
> of the RESULT clause for non-recursive functions should be avoided.

Since Fortran does not have a macro or C++-like template capability,
I find that using RESULT is very handy when replicating a function
for different data types/kinds/ranks. Fewer places within the code
need to be changed for each variant.

Along these lines, I also find ELEMENTAL to be very handy. Because they
are not as rank-sensitive as normal routines, they can significantly reduce
the numbers of variants that need to be created.

Agree with you on the DIMENSION statement. It was redundant even
in Fortran-66.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

James Giles

2004-10-31, 3:56 pm

Walter Spector wrote:
....
> Since Fortran does not have a macro or C++-like template capability,
> I find that using RESULT is very handy when replicating a function
> for different data types/kinds/ranks. Fewer places within the code
> need to be changed for each variant.

I would prefer a real generic programming capability. The need
to have a separately named copy of the code for each combination
of argument (and result) type is not a good language design anyway.
And even if you do write two procedures with the same name
that are visible in the same contexts, as long as they have distinct
type signatures (different argument types) references to them can
be resolved generically. Other languages can do this even with
independently compiled code. (Most use "name mangling", which
is a lazy way to accomplish the feature. It makes debugging harder
since end-users need to know and understand the mangling rules.
But it works. Implementation of the feature needn't involve such
"name mangling" though.)

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Sponsored Links