Optional arguments (again) on Sun
Salvatore
A colleague who has access to a Sun machine has tried out some codes
of mine, and we're stuck on a compile error I can't figure out, given
the discussion on this newsgroup a couple of days ago.
I created a small sample I am attaching, ad he's getting the
following:
----------------------- compile log ---------------
ires = size(a1,dim=opt1)
^
"tv2.f90", Line = 5, Column = 22: ERROR: This actual argument must not
be an optional dummy argument.
f90: COMPILE TIME 0.050000 SECONDS
f90: MAXIMUM FIELD LENGTH 5025462 DECIMAL WORDS
f90: 6 SOURCE LINES
f90: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
-------------------------------------------- tv2.f90 ----------------
subroutine checkv(ires,a1,opt1)
integer :: a1(:,:)
integer, optional :: opt1
ires = size(a1,dim=opt1)
end subroutine checkv
----------------------------------------------------------------------
Thoughts anybody?
Thanks in advance
Salvatore Filippone
Dan Nagle
There is an explicit prohibition on the dim= variable
being an optional dummy argument. Try something like this:
if( present( opt1) )then
local_opt1 = opt1
endif
if( present( opt1) )then
... sum( ... , dim= local_opt1)
else
... sum( ... )
endif
Modify to suit.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
Salvatore
because (in M&R) it was actually stated in the LBOUND description and
then referred to.
Ok, thanks a lot.
Richard Maine
> Ah. yes, I was missing the small print on the SIZE description,
[that dim must not be an optional dummy argument]
The reason for that small print is that having dim changes the rank of
the result. F90/95/2003 is designed so that the rank of everything is
known at compile time. The presence of an optional dummy argument is not
in general known until run time (and may vary from call to call).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Salvatore
The funny thing is that in my original code (not the one I first
posted here) the size(arg,dim=dim) was inside an IF (PRESENT(DIM)),
presumably it was hard for the compiler to figure out it was safe in
that case.
Thanks
Salvatore
Salvatore
However, according to my copy of M&R,
"size(array,[dim=]) returns a scalar default integer that is the size
of the array array or extent along dimension dim .... "
so it would seem that your explanation, while certainly appropriate
for LBOUND/UBOUND, is at least surprising here where there seems to
be no such change of rank.
Salvatore
Richard Maine
> On Feb 19, 4:03 pm, nos...@see.signature (Richard Maine) wrote:
> > Salvatore <sfilipp...@uniroma2.it> wrote:
> > > Ah. yes, I was missing the small print on the SIZE description,
> >
> > [that dim must not be an optional dummy argument]
> >
> > The reason for that small print is that having dim changes the rank of
> > the result.
>
> However, according to my copy of M&R,
>
> "size(array,[dim=]) returns a scalar default integer that is the size
> of the array array or extent along dimension dim .... "
>
> so it would seem that your explanation, while certainly appropriate
> for LBOUND/UBOUND, is at least surprising here where there seems to
> be no such change of rank.
Good point. I just reacted to the bit about dim not being optional
bcause that's usually the reason for that kind of restriction. Hmm. Now
that you mention it, why is there such a restriction for size()?... And
checking further, where is it that this alleged restriction is found? I
can't find any such thing or figure out why there would be one. Did I
just miss it, or is it not actualy there. Anyone have a citation from
the standard on this (not from M&R or any other source - though I don't
off-hand see this one in skimming the latest MR&C either)?
On the point in your other posting:
> The funny thing is that in my original code (not the one I first
> posted here) the size(arg,dim=dim) was inside an IF (PRESENT(DIM)),
> presumably it was hard for the compiler to figure out it was safe in
> that case.
If there is a restriction (which I'm not convinced that there is), then
it wouldn't be that detailed. There are lots of restrictions for things
that don't have the envisioned problem in special cases. Nonetheless,
the restrictions still apply. In a case like UBOUND, which does have the
mentioned restriction, the restriction does not read "unless the
compiler can figure out that it is ok". So it really doesn't matter
whether or not the compiler can figure out that it is ok. What would be
too complicated here would be precisely elaborating a virtually infinite
number of special cases for all kinds of things like that throughout the
standard.
Dan Nagle
Richard Maine wrote:
<snip>
> ... And
> checking further, where is it that this alleged restriction is found?
I found it at 07-007 [429:2-3].
<snip the rest>
Salvatore
> .....
> Good point. I just reacted to the bit about dim not being optional
> bcause that's usually the reason for that kind of restriction. Hmm. Now
> that you mention it, why is there such a restriction for size()?... And
> checking further, where is it that this alleged restriction is found? I
> can't find any such thing or figure out why there would be one. Did I
Well, I'm not sure there is one, except that there is the error
message from the compiler on the SUN machine.
Indeed, this might be the reason for me hitting the problem, since by
reading M&R&C I could figure out the LBOUND issue, but I thought there
was no such issue with SIZE; I have successfully built my stuff with
at least 5 other compilers before this one....
Salvatore
Richard Maine
> Richard Maine wrote:
> > ... And
> > checking further, where is it that this alleged restriction is found?
>
> I found it at 07-007 [429:2-3].
That appears to be in the description of the SUM intrinsic - not SIZE.
SUM is one of the ones where it does change the rank. I don't see
corresponding words (or reference to them) under SIZE.
Dick Hendrickson
> Hi,
>
> Richard Maine wrote:
>
> <snip>
>
>> ... And
>> checking further, where is it that this alleged restriction is found?
>
> I found it at 07-007 [429:2-3].
That's for the SUM intrinsic, where it makes sense because,
as you said earlier, surprise rank changes aren't allowed.
But, the original question was about SIZE, which is always
scalar.
I looked around in the INTENT and OPTIONAL descriptions, thinking
that maybe INTENT(IN) arguments couldn't be OPTIONAL. But, I
couldn't find anything there either.
Dick Hendrickson
>
> <snip the rest>
>
Dan Nagle
Richard Maine wrote:
> Dan Nagle <dann...@verizon.net> wrote:
>
>> Richard Maine wrote:
>>> ... And
>>> checking further, where is it that this alleged restriction is found?
>> I found it at 07-007 [429:2-3].
>
> That appears to be in the description of the SUM intrinsic - not SIZE.
> SUM is one of the ones where it does change the rank. I don't see
> corresponding words (or reference to them) under SIZE.
Are my eyes really getting that bad? (no answer needed :-)
I don't see anything under size() either.
I can see where someone could be fooled, because it's the same
square bracket notation as the rank-changing ones.
Richard Maine
I think you found a compiler bug. Probably caused by making the same
mistake of applying the restriction to an intrinsic where it doesn't
belong.
Thomas Koenig
>I don't see anything under size() either.
Is the OP's code (which passed the optional argument to the
intrinsic size without checking with PRESENT first) OK?
Dick Hendrickson
Sure, because we think it was a compiler error, not a coding
error ;). There is no restriction about DIM not being an
optional argument for SIZE. The general rule is that
OPTIONALness propagates down through the call tree. So that
in something like
subroutine xxx(a)
real, optional :: z
call yyy(a)
if "a" is not present, then it won't be present in yyy either.
That means that yyy must have an optional argument. So
SIZE(x,DIM=optional_thingo) should work either way.
For your more general question. There's never a rule that the
PRESENT function must be used when you fool around with optional
arguments. It's just a handy way to do it. The real rule is that
an optional argument can't be used any context that requires a
value or defines a value unless it is present. It can be used in
some inquire functions, KIND for example, and not others, SHAPE
for example. It can be passed as an actual argument only to
procedures that expect an optional argument (unless it is present).
So long as you obey those rules, you don't need to use PRESENT,
like most of Fortran, you merely have to do the right thing.
Dick hendrickson
Richard Maine
> For your more general question. There's never a rule that the
> PRESENT function must be used when you fool around with optional
> arguments.
And it would be virtually impossible to write such a rule in any kind of
reasonable way either. There certainly would not be a rule that enforced
particular program structures such as an IF block; that would be
unreasonably restrictive. Other than that, how would you even begin to
write such a rule in any kind of precise way? About the only thing I can
think of would be to require that the present() intrinsic be referenced
with the appropriate argument sometime before the call. I can't imagine
how to write in any kind of precise way that something depend on the
result of that function - again, assuming that you don't dictate
specific styles in program structure.
There have been several posts here recently on related subjects. But as
Dick says, it is a broad general principle: the standard doesn't have
conditions that talk about any feature requiring that you check
something first. The standard just requires that you get it right in the
end. In this case, that means that you don't use an optional argument in
some contexts when it is not present.
You almost don't need to go any deeper into the specific cases; the
standard just doesn't have requirements anywhere that read anything like
that.
(But as noted, the code in question here isn't using one of those
contexts anyway. The call is perfectly valid regardless of whether or
not DIM is present).
Steven Correll
> Dick Hendrickson <dick.hendrick...@att.net> wrote:
> > For your more general question. There's never a rule that the
> > PRESENT function must be used when you fool around with optional
> > arguments.
>
> And it would be virtually impossible to write such a rule in any kind of
Along this line, am I right to think that there's a bug in gfortran,
Sun f90, and Lahey Fortran 90 with regard to the random_seed
intrinsic? The standard says that "there shall be exactly one or no
arguments present." I think that means "present" in the sense that the
"present" intrinsic would return "true" during execution, but the
compilers think it means "present as lexemes in the source file."
Here's a program, which those compilers reject, in which no more than
one argument is actually present during execution:
program trs
implicit none
integer :: size, ierr
integer, allocatable, dimension(:) :: seed
call test_random_seed(size)
allocate(seed(size), stat=ierr)
if (ierr /= 0) stop
call test_random_seed(get=seed)
call test_random_seed(put=seed)
contains
subroutine test_random_seed(size, put, get)
integer, optional :: size
integer, dimension(:), optional :: put
integer, dimension(:), optional :: get
call random_seed(size, put, get)
end subroutine test_random_seed
end program trs
> f90 trs.f90
call random_seed(size, put, get)
^
"trs.f90", Line = 17, Column = 5: ERROR: There must be only one or
zero arguments present when calling this intrinsic.
f90comp: 20 SOURCE LINES
f90comp: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
> gfortran trs.f90
trs.f90:17.26:
call random_seed(size, put, get)
1
Error: Too many arguments to random_seed at (1)
trs.f90:17.31:
call random_seed(size, put, get)
1
Error: Too many arguments to random_seed at (1)
glen herrmannsfeldt
(snip)
> Along this line, am I right to think that there's a bug in gfortran,
> Sun f90, and Lahey Fortran 90 with regard to the random_seed
> intrinsic? The standard says that "there shall be exactly one or no
> arguments present." I think that means "present" in the sense that the
> "present" intrinsic would return "true" during execution, but the
> compilers think it means "present as lexemes in the source file."
> Here's a program, which those compilers reject, in which no more than
> one argument is actually present during execution:
(snip)
> contains
> subroutine test_random_seed(size, put, get)
> integer, optional :: size
> integer, dimension(:), optional :: put
> integer, dimension(:), optional :: get
> call random_seed(size, put, get)
> end subroutine test_random_seed
> end program trs
(snip)
> call random_seed(size, put, get)
> ^
> "trs.f90", Line = 17, Column = 5: ERROR: There must be only one or
> zero arguments present when calling this intrinsic.
I think I agree with you, though it might be that you should have
INTENT(OUT), INTENT(IN), INTENT(OUT), respectively, on the
arguments to test_random_seed. That would, at least, make
it consistent with random_seed(). (Even thought I don't believe
that is the cause of the error message.)
-- glen
Ron Shepard
"Steven Correll" <steven....@gmail.com> wrote:
> The standard says that "there shall be exactly one or no
> arguments present."
Maybe "arguments present" means something different than "present
arguments"? :-)
To answer your question, instead of using positional arguments, try
to write your call using keywords. The fact that you can't do it
means that it is not legal.
The same would be true of a user-written subprogram with two
optional arguments. If you were to call it with three arguments
(whether positional or keyword, and regardless of their present()
status), it would not be legal.
$.02 -Ron Shepard
Richard Maine
> In article <1171987364.2...@k78g2000cwa.googlegroups.com>,
> "Steven Correll" <steven....@gmail.com> wrote:
>
> > The standard says that "there shall be exactly one or no
> > arguments present."
>
> Maybe "arguments present" means something different than "present
> arguments"? :-)
No. I saw the smiley, but thought I'd better answer seriously just in
case.
>
> To answer your question, instead of using positional arguments, try
> to write your call using keywords. The fact that you can't do it
> means that it is not legal.
Huh? I must have misread that part. Did you actually just say that the
fact that it didn't work with those compilers means that it is
nonstandard (aka illegal)? That's how I read what you said, but I'll
just assume I misunderstood. The fact that serveral compilers reject
something is plausible grounds to wonder whether it might be
nonstandard, but that certainly does not "mean" that it is nonstandard.
To the contrary, I think the code in question is standard-conforming -
based on the standard rather than on seeing what particular compilers do
with it.
> The same would be true of a user-written subprogram with two
> optional arguments. If you were to call it with three arguments
> (whether positional or keyword, and regardless of their present()
> status), it would not be legal.
That's true, but that is not the situation here. Random_seed has 3
arguments - not 2. There is a restriction that two of them not be both
present in the same call, but that's not at all the same thing as having
only 2 arguments. Your whole point in the above para is based on there
being only 2 arguments, so yes, it matters. That's because matching of
actual with dummy arguments is conceptually done before determination of
presence. First you match the actual and dummy arguments lists. Then,
the present dummy args are the ones that are matched, and where the
matching actual is not in turn a non-present dummy at the next level up.
An intrinsic with 3 arguments, two of which are mutually exclusive is
not like a user routine with only 2 arguments. It is like a user routine
with 3 arguments, two of which are mutually exclusive. It turns out that
you can't directly express the mutual exclusion in user code in a way
that will get caught at compilation time - only at run time.
What user code could do is write it as a generic with two specifics.
Then, having both of the mutually exclusive arguments would be diagnosed
at compile time. But that's not the same situation, partly because
generic resolution is done at compile time. That would not allow
run-time selection in the same way that optional arguments do.
It does make me slightly suspicious that the generic with two specifics
might be how the implementations that get this wrong do it under the
surface.
Ron Shepard
nos...@see.signature (Richard Maine) wrote:
> That's true, but that is not the situation here. Random_seed has 3
> arguments - not 2.[...]
> What user code could do is write it as a generic with two specifics.
> Then, having both of the mutually exclusive arguments would be diagnosed
> at compile time.
This is the situation I was thinking about. I did not explain it
very well in my previous post.
$.02 -Ron Shepard