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