(j3.2006) type parameter scoping question

[Bill Long]

Thanks Daniel, and especially thanks to Malcolm for his extensive reply. 
  The three of us are all in agreement here.  I'll file bugs as appropriate.

Cheers,
Bill


On 11/21/13 8:45 PM, Daniel C Chen wrote:
> 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
>
>
>
>
> _______________________________________________
> 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