Unexpected lack of host association?

[acar]

I have a module in which I declare some variables. The module 'contains' a subroutine which uses the previously defined variable. However I have discovered that I can declare the same variable in the subroutine without any warning or error being flagged up:

Module test

real(8)::delta=0d0

contains

subroutine test_routine

implicit none

real(8)::delta=0d0

end subroutine

end module

This finding has rather thrown my understanding of scoping units and host association.

I'd be grateful if someone could help explain the flaw in my understanding?

[Steven_L_Intel1]

It's not an error - that is the way the language is specified. You probably expect the same behavior as USE association, where such a declaration would be an error, but for host association, it isn't, and the inner declaration hides the outer one.

[acar]

Thanks Steve but I still don't really understand. If I place the subroutine outside the module and add a 'use' to the module then I get an error that there is a name conflict which makes sense to me. Why not when the subroutine is contained in the module?

[Steven_L_Intel1]

Because that's what the standard says. Use association and host association are different. It may help to look at it this way.

When you have a contained routine there are two scopes, one for the contained routine and an outer one for the host. A name declared in the host and a name declared in the contained are in two different scopes - the inner one hides the outer.

When you have USE, all of the public names from the module become names defined in the scope of the routine that did the USE. If you declare the same name in that same scope, that's an error.

[acar]

I'll have to get used to it then!! Thanks for enlightening me Steve.

[Steven_L_Intel1]

Modules and USE association are often confusing, especially when looking at the PUBLIC/PRIVATE attributes. I find it helpful to think of USE as very much like INCLUDE, with selectivity and renaming. Once you do a USE, it is as if all those names were declared in the scope that did the USE - there is no concept of nested USE scopes.

[acar]

The logic that has confused me was to think that procedures that are contained in a module have an implied USE to the variables declared in the module and therefore to expect the same behaviour that would have occurred if the procedure were outside of the module. They do have an implied USE except where one overrides this, again implicitly, by using a local variable with the same name. For external procedures the override is explicit since one would need to exclude the variable in question by qualifying the USE statement.

There is a subtle difference apparently and as yet I don't see the reason for it.

Maybe a switchable option for providing a warning could save some confusion?

[Steven_L_Intel1]

It's not an "implicit USE", it's a nested scope. The standard has several places where it describes how it looks for names in the various scopes. You should stop thinking of USE as any kind of separate scope - think of it like INCLUDE for the declarations. This is even more important when there are nested USEs.

The problem with a switchable warning is that sometimes the programmer wants the host scope variable and sometimes they want a local variable. I've seen errors in both directions (and have made such errors myself.) No matter what we did for a warning, it would be wrong some of the time.

[acar]

I agree, it was my naivity that caused me to think like that; a paradym shift is required on my behalf. Agreed regarding the warning - in my unenlightened state it would have just annoyed me that I didn't understand properly!!