Generics with alternate-return arguments?
Brooks Moses
one with an alternate-return dummy argument, and one without. This is
legal, right?
module arswitch
implicit none
interface foo
module procedure with
module procedure without
end interface
contains
subroutine with(i,*)
integer i
return 1
end subroutine
subroutine without(i)
integer i
return
end subroutine
end module
Thanks,
- Brooks (currently doing gfortran bug-hunting)
--
The "bmoses-nospam" address is valid; no unmunging needed.
David Frank
"Brooks Moses" <bmoses...@cits1.stanford.edu> wrote in message
news:4584E44C...@cits1.stanford.edu...
> The following code has a generic interface with a couple of subroutines,
> one with an alternate-return dummy argument, and one without. This is
> legal, right?
>
> module arswitch
> implicit none
> interface foo
> module procedure with
> module procedure without
> end interface
> contains
> subroutine with(i,*)
> integer i
> return 1
> end subroutine
> subroutine without(i)
> integer i
> return
> end subroutine
> end module
>
> Thanks,
> - Brooks (currently doing gfortran bug-hunting)
>
Your code runs ok using CVF..
I can understand your investigating this, as its a means of getting
acceptance of generics that
otherwise have SAME arg-types and would be rejected, nice insight!
Michael Metcalf
"Brooks Moses" <bmoses...@cits1.stanford.edu> wrote in message
news:4584E44C...@cits1.stanford.edu...
> one with an alternate-return dummy argument, and one without. This is
> legal, right?
>
CVF accepts it and g95 gives an internal error. However, I think its wrong
as the first argument is identical between the two, and the alternate return
does not count towards the number of arguments as the standard specifies the
number of *data-object* arguments (MR&C, p. 93). (I believe this was an
interpretation. TBC.)
HTH,
Mike Metcalf
paul.rich...@gmail.com
Michael,
> CVF accepts it and g95 gives an internal error. However, I think its wrong
> as the first argument is identical between the two, and the alternate return
> does not count towards the number of arguments as the standard specifies the
> number of *data-object* arguments (MR&C, p. 93). (I believe this was an
> interpretation. TBC.)
My g95 compiles it successfully and I have now posted a patch to
PR30236 that allows gfortran to do likewise. Are you sure about this
interpretation because most compilers out there dutifully count the
alternate returns?
Paul Thomas
Brooks Moses
After looking at the standard a bit more closely, I'm not surprised at
this being subject to an interp. The standard's wording (F95, section
14.1.2.3) seems to lead to a bizarre conclusion. Consider clause (2) of
the "two procedures must satisfy one of these" conditions in the middle
of the section: "at least one of them shall have both (a) a nonoptional
dummy argument that corresponds by position in the argument list to a
dummy argument not present in the other...; and (b) a nonoptional dummy
argument that corresponds by argument keyword to a dummy argument not
present in the other...."
If one reads the wording completely literally, then the case I gave with
argument lists of (i,*) and (i) satisfies clause (a) since the * is not
present in the other, but it doesn't satisfy (b) because alternate
returns don't get keywords, and the first arguments have the same
keyword. However, if the argument lists were (i,*) and (j), with the
same type definitions, the i vs. j would then satisfy clause (b), making
this legal. I have a hard time imagining that splitting that fine hair
was the intention of the standard's authors, however!
I'll also note that the F2003 wording changed "dummy argument" to "dummy
data object" in the first clause, but it did _not_ change it in this
clause. Thus, Mike's comment about "data objects" doesn't directly
apply. (In the F95 wording, the language seems to imply that the first
clause already is only applying to arguments which have kinds, which
implies data objects only, but isn't as clear.)
Anyhow, Paul, I'll note that regardless of the standard interpretation,
your patch is useful -- gfortran currently ICEs regardless of whether
the other arguments are identical or not. (And it's probably legal on
the compiler side in any case; it's just a missed diagnostic.)
- Brooks
paul.rich...@gmail.com
Brooks,
> Anyhow, Paul, I'll note that regardless of the standard interpretation,
> your patch is useful -- gfortran currently ICEs regardless of whether
> the other arguments are identical or not. (And it's probably legal on
> the compiler side in any case; it's just a missed diagnostic.)
OK - let's make it standard dependent and warn anyway. There's no
point in getting too deeply into the use of an obsolescent feature.
Regards
Paul
Michael Metcalf
<paul.rich...@gmail.com> wrote in message
news:1166431333....@f1g2000cwa.googlegroups.com...
>
> OK - let's make it standard dependent and warn anyway. There's no
> point in getting too deeply into the use of an obsolescent feature.
>
Interpretation for f95 is number 101. I'm getting a third opinion on whether
the code is legal (the second opinion was that it isn't).
Regards,
Mike Metcalf
Brooks Moses
Thanks! I'll be interested to hear what the third opinion says.
For the record, I think I confused things a little by posting this
question at the same time that I posted almost-identical code as a
GFortran bug report. The bug report (which is what Paul's patch
actually fixes) involves the case where the argument lists differ in
places other than just the alternate-return argument -- e.g., one is
(i,*) and the other is (). My impression is that this case is quite
clearly legal; that is, that there's no global prohibition against
alternate returns in generic interfaces, or something like that.
Michael Metcalf
> Michael Metcalf wrote:
>> <paul.rich...@gmail.com> wrote in message
>> news:1166431333....@f1g2000cwa.googlegroups.com...
>>>
>>> OK - let's make it standard dependent and warn anyway. There's no
>>> point in getting too deeply into the use of an obsolescent feature.
>>>
>> Brooks has noted that the wording has changed in f2003. The relevant
>> Interpretation for f95 is number 101. I'm getting a third opinion on
>> whether the code is legal (the second opinion was that it isn't).
>
> Thanks! I'll be interested to hear what the third opinion says.
>
Well, the third opinion is that it's allowed but is an error in the
standard! The point is, do you really want to leave such backdoors open to
allow the use of an obsolescent feature to defeat the disambiguation rules?
"A label dummy argument does not have a type (and so does not have
a different type). Therefore it was always technically invalid.
[I]t looks to me like NAG, Sun, IBM and Cray are all correct,
and the standard itself is wrong.
This is just too obviously for words a matter of poor wording in the
generic resolution rules. We've fixed bigger glitches than this by
interp."
Regards,
Mike
James Giles
...
> Well, the third opinion is that it's allowed but is an error in the
> standard! The point is, do you really want to leave such backdoors
> open to allow the use of an obsolescent feature to defeat the
> disambiguation rules?
>
> "A label dummy argument does not have a type (and so does not have
> a different type). Therefore it was always technically invalid.
>
> [I]t looks to me like NAG, Sun, IBM and Cray are all correct,
> and the standard itself is wrong.
>
> This is just too obviously for words a matter of poor wording in the
> generic resolution rules. We've fixed bigger glitches than this by
> interp."
How does one write robust code without some sort of exception
handling? Alternate return isn't the best, but it's what Fortran has.
The replacement suggested in annex B is laughable.
--
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
Brooks Moses
> How does one write robust code without some sort of exception
> handling? Alternate return isn't the best, but it's what Fortran has.
> The replacement suggested in annex B is laughable.
Well, g77 in all but one of its intrinsic functions uses a "STATUS"
return variable, equivalent to IOSTAT in an i/o statement. (One of the
instrinsics uses an optional alternate return instead. Want to guess
which one g77 intrinsic isn't implemented in gfortran yet?)
The only place where an "IF (STATUS > 0) GOTO 1200" statement after the
procedure call is insufficient for error handling is when the procedure
is a function, and thus one needs to jump to the exception handling in
the middle of an expression. However, alternate returns don't solve
that one either, since they only apply to subroutines.
I suppose this isn't that much different from the replacement suggested
in Annex B, but then I don't really understand why that's "laughable".
Richard E Maine
> How does one write robust code without some sort of exception
> handling? Alternate return isn't the best, but it's what Fortran has.
> The replacement suggested in annex B is laughable.
I'm not going to participate in an argument about whether alternate
returns should or should not have been declared obsolescent. (I agree
with the standard's obsoleting them, but I won't argue the point).
I post this just to note that, regardless of whether one thinks it wise
or note, the standard does in fact have them labelled as obsolescent.
The standard has been fairly consistent about not enhancing obsolescent
features: if a feature is labelled as obsolescent, it isn't also
enhanced.
--
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
James Giles
...
> I suppose this isn't that much different from the replacement
> suggested in Annex B, but then I don't really understand why that's
> "laughable".
Because it's so verbose. It makes code using the thing look like the
major purpose of calling the procedure is to set the return code.
That's probably the least significant reason for calling the procedure.
Indeed, it's usually introduced at the end of code development.
Prior to that, the programmeer should prefer to halt the code at the
first sign of trouble to make debugging easier. But when you're
about ready to release the code to users that can't (or won't) do
such debugging, you need the exception handling to go back up
the call chain. The expectation is that the alternate return (or
any other indication) is not part of the main purpose of calling
the procedure at all. Alternate returns even *look* like footnotes.
Given the choice between alternate returns or just halting within the
procedure itself when an error occurs I *sometimes* opt for an alternate
return. Given a choice between using a return code or halting within
the procedure itself, I much more often prefer just halting.