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

[Craig Dedo]

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:  < <mailto:craig at ctdedo.com> craig at ctdedo.com>

USA

Linked-In:   <http://www.linkedin.com/in/craigdedo> http://www.linkedin.com/in/craigdedo

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20100829/80e02dce/attachment.htm>