(j3.2006) type parameter scoping question

[Malcolm Cohen]

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.