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