Thanks much, Tom, for your input.
I think there is a bit of misunderstanding: as I mentioned earlier,
I'm curious about the situation where the host scope of a BLOCK indeed
has IMPLICIT typing but where a code does NOT want that in the BLOCK,
hopes to explicitly declare all the entities relevant to the BLOCK,
and seeks IMPLICIT NONE within the BLOCK to help the process.
Consider a slight revision of your example:
IMPLICIT INTEGER(I-N), .. !<-- Note outer scope has IMPLICIT typing
..
BLOCK
IMPORT NONE
!REAL :: local_var_1 !<-- commented out to indicate the
coder has forgotten this declaration
..
..
So in the above case then, local_var_1 implicitly gets the type of
INTEGER when it was meant to be REAL.
And a second problem (I'm not entirely sure about this given IMPORT
facilities starting with Fortran 2018, but you may know) might be that
local_var_1 gets an "inclusive scope" which the coder may not want,
(s)he may not even be aware of it, and might end up paying a price for
it at some point with unintended consequences.
Basically I'm trying to understand if there is a technical reason why
a BLOCK construct cannot allow an IMPLICIT NONE statement.
Best Regards,
Vipul
On Thu, Feb 22, 2018 at 7:59 AM, Clune, Thomas L. (GSFC-6101)
<[log in to unmask]> wrote:
> Hi Vipul,
>
> Just in case this is a simple matter of misunderstanding … If you have IMPLICIT NONE in the outer scope, then you effectively have it in the inner scope. You simply are not able to alter that.
>
> If instead you are hoping for a mechanism that _ignores_ any declared variables in the outer scope, then you would presumably want to use IMPORT mechanism.
>
> BLOCK
> IMPORT, ONLY :: <list-of-external-entities that you want>
> REAL :: local_var_1
> INTEGER :: local_var_2
> …
> END BLOCK
>
> Combined with IMPLICIT NONE in the outer scope, this would force you to explicitly “acknowledge” each variable in the BLOCK construct. Each would either be imported or declared explicitly.
>
> Hope this helps,
>
> - Tom
>
>
>> On Feb 22, 2018, at 1:00 AM, Vipul Parekh <[log in to unmask]> wrote:
>>
>> Thank you very much for sharing your understanding on the BLOCK
>> construct, appreciate it greatly.
>>
>> My curiosity about IMPLICIT and NAMELIST statements in a BLOCK
>> construct are based on practical considerations and I'm looking at
>> this somewhat differently. I don't want to be bothered by an
>> "inclusive scope" particularly when it has IMPLICIT typing. I simply
>> want the "blade guard" of IMPLICIT NONE in the BLOCK scope then. Why
>> can this not be possible other than the current standard simply
>> stating it should not be? In fact there is an implementation out
>> there which conforms to constraint C806 except for allowing IMPLICIT
>> NONE in a BLOCK; it's a shame a bug report will undo this "good"
>> feature.
>>
>> ..
>> IMPLICIT INTEGER(I-K,M-N), LOGICAL(L), ..
>> ..
>> blk: block
>> implicit none !<--- Why not?
>> import, only :: ... !<-- introduced in Fortran 2018, a great facility
>> ..
>> namelist /blk_nml/ ... !<--- Why not NAMELIST in BLOCK?
>>
>> ..
>> if (..) read( unit=.., nml=blk_nml !<-- deserialize some data
>> toward this scope
>> ..
>> if (..) write( unit=.., nml=blk_nml, ..) !<-- serialize some data
>> ..
>> end block blk
>> ..
>>
>> Separately I think NAMELIST facility in the standard can continue to
>> bring great value and it needs to be nurtured and treated well into
>> the future and any issues with it sorted out, especially in light of
>> defined IO feature in Fortran and what one can then do with OO
>> 'classes' (derived types).
>>
>> Regards,
>> Vipul Parekh
>>
>>
>> On Wed, Feb 21, 2018 at 7:07 PM, Malcolm Cohen <[log in to unmask]> wrote:
>>> Nothing gets implicitly typed in a BLOCK construct, they always get typed in the "inclusive scope". You can think of that as being the scope ignoring the existence of BLOCK; basically, the innermost subprogram containing it.
>>>
>>> That is so that adding a BLOCK-ENDBLOCK in the middle of a subprogram, perhaps in an IF construct, to add an explicitly typed variable local to the BLOCK, does not change the scope of any pre-existing variable. Otherwise BLOCK would be so extremely error-prone as to be unusable without IMPLICIT NONE.
>>>
>>> So IMPLICIT simply does not make sense.
>>>
>>> The issue with NAMELIST is the same as that of COMMON: in a subprogram, multiple COMMON (or NAMELIST) statements with the same common block name (or namelist group name) add to the common block definition (or namelist definition). It was just thought to be too confusing to have these statements in a BLOCK construct as people would wonder what they were doing.
>>>
>>> BTW most discussion takes place at meetings. Sometimes there are papers before or after such discussions which mention rationale, but not always. And the rationale for one person is not necessarily the rationale for another (for example, someone might consider COMMON and NAMELIST to be old-fashioned and undesirable in principle, so prefers not to extend them further). So my stated rationale above is merely my opinion as to what the most important factors in the decisions were - it's common to have multiple factors affecting a decision, and someone else might well think something else was a more important factor.
>>>
>
|