In what circumstances would IMPLICIT NONE in a block instead of its host
(sub)program be a good idea?
On Thu, 22 Feb 2018, Vipul Parekh wrote:
> Date: Thu, 22 Feb 2018 01:00:24 -0500
> From: Vipul Parekh <[log in to unmask]>
> Reply-To: Fortran 90 List <[log in to unmask]>
> To: [log in to unmask]
> Subject: Re: Starting with Fortran 2018,
> is IMPLICIT statement permitted in a BLOCK construct?
>
> 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.
>>
>
>
-- John Harper, School of Mathematics and Statistics
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail [log in to unmask] phone (+64)(4)463 5276 fax (+64)(4)463 5045
|