(j3.2006) IMPLICIT NONE in BLOCK

[Bill Long]

> On Feb 23, 2018, at 5:56 AM, Robert Corbett <rpcorbett at att.net> wrote:
> 
> 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.

Now we have one person saying this program is not conforming and another saying it is conforming.   That alone seems a symptom of lack of clarity.  Compounded by the definition of ?scoping unit? including ?BLOCK construct?. 

Cheers,
Bill

> 
> 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
> 
> _______________________________________________
> 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