(j3.2006) type parameter scoping question
Craig Dedo
craig
Thu Nov 21 22:08:02 EST 2013
Everyone:
Malcolm Cohen says, "This is the only interpretation [i.e., option 2] that
could be supported by the standard." Yet he offers no explanation as to why the standard
requires this interpretation.
Could Malcolm or someone else please explain his reasoning as to why the
standard requires the interpretation of option 2? What normative text leads to option 2
being the only legitimate interpretation?
Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423 Mobile Phone: (414) 412-5869
Brookfield, WI 53008-0423 E-mail: <craig at ctdedo.com>
USA
Linked-In: http://www.linkedin.com/in/craigdedo
From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On
Behalf Of Daniel C Chen
Sent: Thursday, November 21, 2013 20:45
To: fortran standards email list for J3
Cc: j3-bounces at mailman.j3-fortran.org
Subject: Re: (j3.2006) type parameter scoping question
I agree with Malcolm's explanation. Number 2 is the behavior of IBM's compiler. The
program prints '8'.
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 "Malcolm Cohen" ---11/21/2013 19:15:26---Hi Bill, >For this
(intentionally perverse) program:"Malcolm Cohen" ---11/21/2013 19:15:26---Hi Bill, >For
this (intentionally perverse) program:
From: "Malcolm Cohen" <malcolm at nag-j.co.jp>
To: "fortran standards email list for J3" <j3 at mailman.j3-fortran.org>,
Date: 11/21/2013 19:15
Subject: Re: (j3.2006) type parameter scoping question
Sent by: j3-bounces at mailman.j3-fortran.org
_____
Hi Bill,
>For this (intentionally perverse) program:
I don't see anything more perverse about this than about type parameters in
general.
>What should happen? I'm seeing three different compiler behaviors:
>
>1) Multiple errors at compile time because the PDT feature is not supported.
A reasonable response.
>2) Compile with no errors; executes and prints 8.
This is what the standard requires, IF and ONLY IF there is an integer kind 8.
If you change the declaration to
integer n(nasty+nasty)
and the enquiry to
size(x%n)
then it will surely print 8 on any machine with enough memory to support arrays
of that size.
>3) Compile time error for an unsupported KIND for the integer N
>(presumably either 20 or 6, with 20 being more likely).
That would be a compiler bug.
>The argument for compiler 2 is that the scope of the type parameter
>nasty is the type definition, and in that scope valid uses of nasty
>refer to the type parameter and not the named parameter of the same name
>in the host scope.
Absolutely, that's how it works. Otherwise you can't use them.
>The argument for compiler 3 appears to be that since the type parameter
>and named constant are in different classes of local identifiers, they
>can both used in the type definition.
Hmm, that would be right for the outer scope, but not for the type definition
scope. That classification is so that there is no question of being able to
write
x%componentname
or
x%typeparametername
and getting the component or the type parameter of x, even though there might be
another entity with the same name (componentname or typeparametername) in the
outer scope.
I won't try to defend the design of this classification scheme.
> And the named parameter "wins".
Well no, why would it "win"? At best this could be construed as an ambiguity in
the standard.
>I'm partial to the compiler 2 interpretation since it is not ambiguous,
>and makes intuitive sense in that local host entities normally block
>access to host entities with the same name.
This is the only interpretation that could be supported by the standard.
> (Though that last argument
>is usually applied to identifiers in the same class.) The compiler 3
>interpretation seems to make it easy to render the type parameter
>useless inside the type definition.
There is no support at all for this interpretation! We NEVER do ANYTHING like
this at all anywhere else in the language, why on earth would we start doing it
here!
This sounds more like post-hoc rationalisation of "this isn't really a compiler
bug".
>An alternative is to say that the code is not conforming at all. But
>I'm not seeing the argument for that.
Well, the argument would be that the standard is ambiguous, therefore by the
usual clause 1 rule, the program is not conforming because no interpretation is
established for it.
I am very sympathetic to the "you didn't explain this properly" complaint -
because it is true. But not very sympathetic to the idea of therefore making up
rules that don't make sense. Of course, if you believe that the classification
means that with the derived-type definition scope, N is both the type parameter
name and the named constant, you straightaway arrive at the "not conforming
because ambiguous" and "not conforming" means the compiler can do whatever it
pleases, but still...
>In any event, there are implementation conflicts. It would be
>interesting to see how the Sun, IBM, and NAG compilers handle this
>program - I don't have any of them installed locally.
The compiler 2 interpretation is the only one (of 1-3) that is consistent with
the standard, and is how the NAG compiler would behave if it supported PDTs.
Obviously (!) we intended this to work the same way that scoping works
everywhere else...
Cheers,
--
................................Malcolm Cohen, Nihon NAG, Tokyo.
_______________________________________________
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/20131121/4ce808db/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20131121/4ce808db/attachment-0001.gif
More information about the J3
mailing list