(j3.2006) IMPLICIT NONE in BLOCK

Fri Feb 23 13:27:01 EST 2018

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. 

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).

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