(j3.2006) Generic resolution of assumed-size dummy
john.reid at stfc.ac.uk
john.reid
Sun Jun 5 18:59:03 EDT 2016
The ambiguity rules do not apply to this generic because it has only one specific.
Hence I think there is no problem.
Cheers,
John.
________________________________________
From: j3-bounces at mailman.j3-fortran.org [j3-bounces at mailman.j3-fortran.org] on behalf of Daniel C Chen [cdchen at ca.ibm.com]
Sent: 05 June 2016 22:26
To: fortran standards email list for J3
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
Case1:
Interface
Subroutine sub(arg)
Integer :: arg(*)
End
End interface
Integer :: iarr(10, 10)
Call sub(iarr)
End
Case 2,
Interface sub
Subroutine sub1(arg)
Integer :: arg(*)
End
End interface
Integer :: iarr(10, 10)
Call sub(iarr)
End
Call sub in Case 1 resolves to specific subroutine sub, but call sub in Case 2 cannot resolves to specific subroutine sub1 even though it has exactly the same interface.
I would think there is some kind of inconsistency here.
Thanks,
Daniel
XL Fortran Development - IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
http://www.ibm.com/software/awdtools/fortran/xlfortran
[Inactive hide details for "Lionel, Steve" ---06/03/2016 14:37:10---I don?t see an inconsistency. The carve-out for assumed-si]"Lionel, Steve" ---06/03/2016 14:37:10---I don?t see an inconsistency. The carve-out for assumed-size rank mismatch applies to the actual pr
From: "Lionel, Steve" <steve.lionel at intel.com>
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Date: 06/03/2016 14:37
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
Sent by: j3-bounces at mailman.j3-fortran.org
________________________________
I don?t see an inconsistency. The carve-out for assumed-size rank mismatch applies to the actual procedure reference. That generic selection doesn?t have the same carve-out isn?t inconsistent ? in fact I?d say it?s required or else the rules of generic selection get more complicated (and less useful) than they already are.
Steve
From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Daniel C Chen
Sent: Friday, June 3, 2016 2:04 PM
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
Checki1 is fine since it has different KIND parameter.
I would think that checki2, checki3 and checki4 are supposed to be ambiguous because they are either assume-size or explicit-shape array based on the sequence association rule that both calls to the generic name check can resolve to any of these specifics.
However, the current wording in the standard (as Steve also said) seems disallow the ambiguity (by saying TKR must be differ), but at the same time, introduce the inconsistency of how a generic name or specific procedure is referenced.
So the question is: is this inconsistency desired?
Thanks,
Daniel
XL Fortran Development - IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com<mailto:cdchen at ca.ibm.com>
http://www.ibm.com/software/awdtools/fortran/xlfortran
[Inactive hide details for Tom Clune ---06/03/2016 13:55:04---Bill, OK - maybe I was reading too quickly, but I thought your res]Tom Clune ---06/03/2016 13:55:04---Bill, OK - maybe I was reading too quickly, but I thought your response was implying that checki3()
From: Tom Clune <Thomas.L.Clune at nasa.gov<mailto:Thomas.L.Clune at nasa.gov>>
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Date: 06/03/2016 13:55
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
Sent by: j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>
________________________________
Bill,
OK - maybe I was reading too quickly, but I thought your response was implying that checki3() and checki1() could be overloaded. And both would match any assumed size array regardless of rank.
- Tom
On Jun 3, 2016, at 1:34 PM, Bill Long <longb at cray.com<mailto:longb at cray.com>> wrote:
On Jun 3, 2016, at 11:56 AM, Tom Clune <Thomas.L.Clune at nasa.gov<mailto:Thomas.L.Clune at nasa.gov>> wrote:
We then have the rather odd situation that the mere act of adding an additional interface can change which procedure is called in an already working code.
That should never happen, since it would imply that the CALL matched two of the specifics (the old one and the newly added one). The rules for generic disambiguation are designed to make sure that never happens.
Cheers,
Bill
Not necessarily a bad thing, but it does seem that it could be rather surprising to the developer that thought he was ?guaranteed? not to be changing results as he was only implementing a new interface and had not added client code to use it ?
On Jun 3, 2016, at 10:55 AM, Lionel, Steve <steve.lionel at intel.com<mailto:steve.lionel at intel.com>> wrote:
True, but Daniel's question really is about whether a rank-1 assumed-size
dummy is distinguishable from a rank-N assumed-size dummy, since as he says,
we allow a rank mismatch for an assumed-size dummy (16-007r1 5.5.8.5p1).
Given that there's no wording in 12.4.3.5.5 (again, 16-007r1) carving out an
exemption for assumed-size dummies, I would say that they are
distinguishable and that generic selection would require that the specific
that matches the rank be called.
Steve
-----Original Message-----
From: j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>
[mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Bill Long
Sent: Friday, June 03, 2016 10:41 AM
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
assumed-rank is dimension(..). That is different from assumed-size.
Cheers,
Bill
On Jun 3, 2016, at 9:35 AM, Daniel C Chen <cdchen at ca.ibm.com<mailto:cdchen at ca.ibm.com>> wrote:
Hello,
Consider the following code:
module checktest
interface check
module procedure checki1, checki2
end interface
contains
subroutine checki1(ia1)
integer*1, dimension(*) :: ia1
end subroutine checki1
subroutine checki2(ia1)
integer*2, dimension(*) :: ia1
end subroutine checki2
subroutine checki3(ia1)
integer*2, dimension(4,*) :: ia1
end subroutine checki3
subroutine checki4(ia1)
integer*2, dimension(4,4,4) :: ia1
end subroutine checki4
end module checktest
program main
use checktest
integer*2, dimension(10,5) :: ia1
integer*2, dimension(4,4,4) :: ia2
call check(ia1)
Call check(ia2)
end program main
While we allow assumed-size dummy argument of a specific procedure
correspond to an array actual argument of any rank, it seems we don't allow
it for generic procedure.
In the standard, we have:
12.4.3.5.5
"A dummy argument is type, kind, and rank compatible, or TKR compatible,
with another dummy argument if the first is type compatible with the second,
the kind type parameters of the first have the same values as the
corresponding kind type parameters of the second, and both have the same
rank or either is assumed-rank.
...
Two dummy arguments are distinguishable if ...
they are both data objects or known to be functions, and neither is
TKR compatible with the other, ..
"
1. It seems ia1 of checki2, checki3 and checki4 are distinguishable
according to the standard I quoted at the above because they have different
ranks, Is this expected?
2. If 1 is expected, should call check(ia1) resolves to checki3 and call
check(ia2) resolves to checki4? If so, it seems contradict to the sequence
association rule.
Thanks,
Daniel
XL Fortran Development - IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com<mailto:cdchen at ca.ibm.com>
http://www.ibm.com/software/awdtools/fortran/xlfortran
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long
longb at cray.com<mailto:longb at cray.com>
Fortran Technical Support & voice:
651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
Thomas Clune, Ph. D. <Thomas.L.Clune at nasa.gov<mailto:Thomas.L.Clune at nasa.gov>>
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long longb at cray.com<mailto:longb at cray.com>
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
Thomas Clune, Ph. D. <Thomas.L.Clune at nasa.gov<mailto:Thomas.L.Clune at nasa.gov>>
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: graycol.gif
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20160605/3a93d262/attachment.gif
More information about the J3
mailing list