(j3.2006) type parameter scoping question

[Daniel C Chen]

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



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/0ef88eb3/attachment.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/20131121/0ef88eb3/attachment.gif