(j3.2006) IMPLICIT NONE in BLOCK

[Robert Corbett]

Before the meeting in October 2017,
the draft standard accidentally allowed IMPLICIT statements in BLOCK constructs.  I thought the committee had intentionally extended the language and I posted an e-mail message to the J3 mailing list explaining what a bad idea that was (with examples).  Malcolm responded to that message, saying that the extension was accidental.  I wrote paper 17-232 to remove the accidental extension.

The problem is that because items implicitly declared in BLOCK constructs have inclusive scope,  the semantics of implicit declarations become confusing and possibly even contradictory unless every BLOCK construct in an inclusive scope uses the same IMPLICIT mapping.

If a user wants IMPLICIT NONE to be in effect within a BLOCK construct, he or she should put an IMPLICIT NONE statement in a non-BLOCK scoping unit containing the BLOCK construct.  Because it is good practice to always use IMPLICIT NONE, putting IMPLICIT NONE in one or more of the containing scoping units should not be too great a burden.

Robert Corbett

> On Feb 22, 2018, at 10:28 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
> 
>> On Fri, 2018-02-23 at 12:12 +0900, Malcolm Cohen wrote:
>> No.
>> 
>> 
>> 
>> NOTHING is implicitly type inside a BLOCK construct.  Changing this
>> design principle would be a terrible mistake.
> 
> In this little program
> 
> program foo
>  block
>    x = 42.0
>  end block
>  block
>    print *, x
>  end block
> end program foo
> 
> one processor prints 42.0000000.
> 
> Another processor printed 0.0000000E+00 until I compiled with undefined
> variable checking turned on, after which it announced that the variable
> referenced in the print statement was undefined.
> 
> Either way, the variable X clearly is implicitly typed as real.  The
> processors disagree whether X has inclusive scope, or there are two
> different X variables in different scopes (I assume one is mistaken),
> but neither one complains that X is not declared.
> 
> What Vipul Parekh was advocating, and the question I asked, is if it is
> worth pondering whether it would be too difficult, too disruptive of
> existing practice, or not sufficiently useful to allow
> 
> program foo
>  block
>    implicit NONE
>    x = 42.0
>  end block
>  block
>    implicit NONE
>    print *, x
>  end block
> end program foo
> 
> and no other flavor of implicit except variations of
> 
>  implicit NONE(TYPE,EXTERNAL)
> 
> in a BLOCK construct, which would make this program invalid because X is
> not declared in either BLOCK construct, which is exactly what is
> desired.
> 
> As Vipul pointed out, if one has a large ancient legacy code that needs
> a few small changes, a good way to introduce them without fear of
> colliding with other variables would be to declare any newly-needed
> variables in BLOCK constructs.  IMPLICIT NONE with IMPORT, NONE would be
> useful to guard against accidentally forgetting to declare one, thereby
> getting what might well be the wrong implicit type.
> 
> An IMPORT, NONE statement alone doesn't solve this problem.  I don't see
> a way that allowing IMPLICIT NONE in a BLOCK construct could affect a
> program that conforms to the 2018 standard.
> 
>> 
>> 
>> 
>> Cheers,
>> 
>> -- 
>> 
>> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>> 
>> 
>> 
>> 
>> From: J3 [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Van
>> Snyder
>> Sent: Friday, February 23, 2018 11:23 AM
>> To: j3 <j3 at j3-fortran.org>
>> Subject: (j3.2006) IMPLICIT NONE in BLOCK
>> 
>> 
>> 
>> 
>> Is it worth contemplating the ramifications of allowing IMPLICIT NONE
>> (but no other IMPLICIT) in a BLOCK construct? It seems to be useful.
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> 
>> 
>> 
>> Disclaimer
>> 
>> The Numerical Algorithms Group Ltd is a company registered in England
>> and Wales with company number 1249803. The registered office is:
>> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>> 
>> This e-mail has been scanned for all viruses and malware, and may have
>> been automatically archived by Mimecast Ltd, an innovator in Software
>> as a Service (SaaS) for business.
>> 
>> 
>> _______________________________________________
>> 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