(j3.2006) IMPLICIT NONE in BLOCK
Bill Long
longb
Fri Feb 23 15:02:27 EST 2018
> On Feb 23, 2018, at 12:27 PM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov> wrote:
>
> I fear the ship has already sailed on this issue, and I joined the committee after the major decisions were made on this feature.
>
> But a few points in case they matter:
>
> 1) As Van has asserted retroactively putting in IMPLICIT NONE into large legacy applications is an extremely tedious process. I tried it once with a code that was ~20k lines, and eventually gave up. May have been partially my fault at the time for not knowing how to force the compiler to generate _all_ undeclared variable messages. Instead I had to work through 10-20 in each compilation.
Some compilers have a command line option to force the effect of IMPLICIT NONE in all the program units in the file being compiled. Essentially requires declarations for all variables without modifying the source code.
>
> 2) Next, I have _never_ encountered a situation in which I want a BLOCK variable to be accessible in other blocks. So the inclusive scope aspect seems to have been designed for a use case that I?ve not encountered (or simply not considered).
If, by "BLOCK variable? you mean a variable explicitly declared in the block (other than only in an ASYNCHRONOUS or VOLATILE statement), then there is no issue. Such variables are local to the block and unrelated to any variable outside the block that might have the same name. If you always include a type declaration for the variable in the block then there is no possibility for confusion. This seems like a good recommendation for new code.
Similarly, variables that are explicitly declared, or even just appear in the scope surrounding the BLOCK construct are accessible within the BLOCK as long as there is not a block-local declaration for the same name. Again pretty obvious what is intended.
The confusion is for a variable that is not declared anywhere, and hence relies on implicit typing, and appears in the block, but not in the surrounding scope. (As in Van?s contrived [one hopes] example.) Admittedly, in actual practice this would be unusual, and probably a programming mistake. For these variables, the question is whether they are (1) local to the block and rely on the implicit type rules currently in effect (Malcolm says No), or (2) ?as if? they appeared in the surrounding scope. As I understood the design discussion, if you retrofit a BLOCK construct around an existing sequence of statements in an old code, option (2) is the choice that leads to the ?least surprise?.
Cheers,
Bill
>
> 3) Next, I have never made my block constructs more than 10 or so lines. (Undergraduate CS profs would be so proud.) As such, I?ve never even had an issue with explicitly declaring that handful of block variables. I?m fortunate enough these days to be working with codes that already have IMPLICIT NONE, so the compiler has generally caught me quickly when I goofed. I do intend to start religiously using IMPORT, ONLY going forward to escape any rare unintended conflicts.
>
> So the case where the existing standard appears to be a problem is in a large legacy program unit that lacks IMPLICIT NONE in the inclusive scope _and_ where the BLOCK is large enough that IMPORT, ONLY becomes itself impractical. So while I would not oppose some attempt to somehow strengthen the rules for requiring declarations for block variables, I think the practical solution is to avoid large BLOCKs. Large BLOCKs should be considered an anti-pattern and abuse will push the feature towards the obsolescent end of the feature pool.
>
> I have been very appreciative of BLOCK as a debugging aid when analysis required access to global data that were not otherwise available at the point in the code and wanted to avoid permanently adding extra declarations at the top of a large legacy procedure. But it has also become part of the process in my group to prune out blocks shortly thereafter. If some aspects need to be preserved, we properly integrate them without the BLOCK. Sometimes that means introducing an internal procedure (which does allow IMPLICIT NONE, BTW), and sometimes it means polluting the declarations at the top of the procedure.
>
> Cheers,
>
> - Tom
>
>
>
>
>> On Feb 23, 2018, at 4:45 AM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>>
>> On Fri, 2018-02-23 at 17:33 +0900, Malcolm Cohen wrote:
>>
>>>> Either way, the variable X clearly is implicitly typed as real. The
>>>> processors disagree whether X has inclusive scope,
>>>
>>> The standard explicitly states that local variables have inclusive
>>> scope.
>>>
>>> Lacking an explicit declaration, it is not a construct entity.
>>
>> The message to which I replied said
>>
>>> NOTHING is implicitly type inside a BLOCK construct.
>>
>> The little program appears to have created an implicitly-typed variable,
>> which contradicts that assertion. Maybe instead of the words that
>> appeared I should have read "Anything that is implicitly typed and
>> springs into existence in a BLOCK construct without a declaration is not
>> a construct entity, even if it appears nowhere else. It's still
>> implicitly typed; it's just not a construct entity."
>>
>> Probably I don't understand the objection to allowing IMPLICIT NONE in a
>> BLOCK construct. I would expect it to mean that an implicitly-typed
>> variable is not allowed to spring into existence in a BLOCK construct.
>> I understand that if it were to spring into existence in a BLOCK
>> construct without being declared, it would become a local entity instead
>> of a construct entity. That's what I would hope to prevent. Is the
>> problem that IMPLICIT NONE in a BLOCK construct couldn't really have an
>> effect, because an entity that is not declared in the construct is a
>> local entity? That is, it doesn't spring into existence where one hoped
>> to prevent it from springing into existence without a declaration, it
>> springs into existence in the inclusive scope, where the IMPLICIT NONE
>> in the BLOCK construct that one hoped to use to prevent its existence
>> doesn't apply.
>>
>> If IMPORT,NONE (or IMPORT,ONLY) appears in a BLOCK construct, and a
>> variable springs into existence therein without a declaration, it
>> becomes a local entity, not a construct entity, and is therefore not
>> accessible in the BLOCK construct (because of IMPORT,whatever), even
>> though it doesn't appear anywhere else. If so, that has the effect of
>> IMPLICIT NONE, in a weird perverse contorted way that needs a bit of ink
>> in textbooks and deserves a note in the standard. Being a local entity
>> instead of a construct entity, it would be accessible in other BLOCK
>> constructs, if they don't have IMPORT,whatever. But then the program is
>> invalid because it's not accessible where it sprang into existence.
>> Weird.
>>
>> I haven't been able to ask any processors what they think about
>>
>> program foo
>> block
>> import, none
>> x = 42
>> print *, x
>> end block
>> end program foo
>>
>> because none of the ones I have allow IMPORT in BLOCK yet. Is this a
>> valid program? Or is it invalid because X is a local entity, not a
>> construct entity, and can't be accessed at the only place where it
>> appears because of IMPORT, NONE? If so, this is precisely what I would
>> want from IMPLICIT NONE in a BLOCK construct. But it's a weird way to
>> get it. Some ink, and the "slippery road" sign from the TeXBook, would
>> be helpful.
>>
>>
>> _______________________________________________
>> 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
Principal Engineer, Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9143
Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
More information about the J3
mailing list