(j3.2006) IMPLICIT NONE in BLOCK

[Robert Corbett]

We discussed programs like the one you show in your e-mail at the October 2017 meeting.  We decided that they were not intended to be standard conforming.

A similar issue comes up for IMPORT, ALL in interface procedures.  In our scoping model, the name of an interface procedure in the host scope identifies a different procedure entity from the entity declared with the same name in the interface procedure.  The procedure entities are distinct even though they are associated.  I think a strict reading of the DIS is that that is a constraint violation.  I do not know if our intent was to allow INTENT, ALL in interface procedures, but I think the DIS does not.  I do not care much one way or the other, because IMPORT, ALL does add not much that is useful beyond just IMPORT in the case of interface procedures.

Robert Corbett

> On Feb 23, 2018, at 1: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