(j3.2006) Conceptual Gap with BLOCK Construct, Scope, and Host Association?

[Bill Long]

The relevant F2008 document is N1826 (10-007), which contains the 
results of  substantial work to clarity (or at least make more precise) 
the scoping rules for BLOCK constructs.   You should discard N1814.

In terms of conceptualization, I think of a BLOCK construct as similar 
to an in-line, nameless internal procedure that has no arguments.  After 
all those deductions, you end up with a section of code that accesses 
its surroundings by host association and has the capability of declaring 
variables that have scope local to the block.

Cheers,
Bill



Craig Dedo wrote:
> Everyone:
> 
>             The discussion today about ?IEEE and the GPU World?, 
> especially the comments by John Reid and Bill Long, suggest that there 
> appears to be a substantial conceptual gap about BLOCK constructs and 
> scope in the Fortran 2008 FDIS.
> 
>  
> 
>             Up until Fortran 2008, blocks were not separate scoping 
> units.  Thus, the contents of blocks followed the same scoping rules as 
> the rest of the procedure that they were a part of.
> 
>  
> 
>             This changed in Fortran 2008 with the creation of the BLOCK 
> construct.  Section 1.3.124 of WG5/N1814 defines ?scoping unit? as a 
> ?BLOCK construct, ..., excluding all scoping units within it.?  This 
> means that any entities defined within a BLOCK construct only are 
> defined within that particular BLOCK construct.
> 
>  
> 
>             However, it is unspecified what other entities are visible 
> within a BLOCK construct.  From the general discussion, it appears that 
> the original intent of the committee was that executable statements 
> within a BLOCK construct would have access to all definitions within all 
> enclosing scopes, up to the procedure level.  This would also include 
> access to all definitions available to the procedure via use association 
> or host association.
> 
>  
> 
>             If this is the intent, then the creation of the BLOCK 
> construct and its status as a separate scoping unit defines a new form 
> of host association.  However, that is not specified in section 
> 16.5.1.4p1, ?Host association?.  Thus, the conceptual gap of a new form 
> of host association without it being explicitly defined.
> 
>  
> 
>             It appears that this is an oversight.  If so, then ?BLOCK 
> construct? needs to be added to the list of thingos that have access to 
> host definitions by host association.
> 
>  
> 
>             It appears that defining BLOCK constructs as participating 
> in host association is the cleanest and most straightforward method of 
> resolving some of the complications that have been mentioned in the 
> ?IEEE and the GPU World? discussion.
> 
>  
> 
>             If the committee adopts this approach, then it would be 
> necessary to add some extra syntax in order to turn off definitions that 
> are not desired within the scope of a BLOCK construct.  Particularly, if 
> any of the definitions in any of the IEEE_* intrinsic modules are within 
> the scope of the enclosing procedure, then the same set of definitions 
> are, by rule, available in any BLOCK constructs within that procedure.  
> If programmers want to create a BLOCK construct for execution on a GPU, 
> then they will want to turn off these IEEE_* definitions and they need 
> some way of doing so explicitly without resorting to obtuse hacks.  
> FWIW, I strongly agree with Bill Long that explicit syntax to turn off 
> definitions within BLOCK constructs is far preferable to the nearly 
> inscrutable method of re-defining IEEE_ARITHMETIC, etc.
> 
>  
> 
>             What do others think about this?
> 
>  
> 
>             What are the advantages and disadvantages of explicitly 
> defining BLOCK constructs as participating in host association?
> 
>  
> 
>             If new syntax is desirable in order to give the programmer 
> the ability to turn off definitions within a particular scope, how 
> should this be done?  Would a Type 2 TR be the best solution?  Or, would 
> some other method be preferable?  If so, what method, considering the 
> publication schedule of Fortran 2008?
> 
>  
> 
>             FWIW, I am willing to write up the necessary interpretation 
> request if it appears that this is a desirable solution to this issue.
> 
>  
> 
> Sincerely,
> 
> *Craig T. Dedo*
> 
> 17130 W. Burleigh Place
> 
> P. O. Box 423                         Mobile Phone:  (414) 412-5869
> 
> Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com 
> <mailto:craig at ctdedo.com>>
> 
> USA
> 
> Linked-In:  http://www.linkedin.com/in/craigdedo
> 
>  
> 

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101