(j3.2006) Generic resolution of assumed-size dummy
Daniel C Chen
cdchen
Fri Jun 3 14:03:43 EDT 2016
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
http://www.ibm.com/software/awdtools/fortran/xlfortran
From: Tom Clune <Thomas.L.Clune at nasa.gov>
To: fortran standards email list for J3 <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
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> wrote:
On Jun 3, 2016, at 11:56 AM, Tom Clune <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> 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] 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>
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> 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
http://www.ibm.com/software/awdtools/fortran/xlfortran
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long
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
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
Thomas Clune, Ph. D. <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
http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long
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
http://mailman.j3-fortran.org/mailman/listinfo/j3
Thomas Clune, Ph. D. <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
http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160603/507730dd/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20160603/507730dd/attachment-0001.gif
More information about the J3
mailing list