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

[Craig Dedo]

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf Of
> Bill Long
> Sent: Sunday, August 29, 2010 17:52
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) Conceptual Gap with BLOCK Construct, Scope, and Host
> Association?
> 
> 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.

	As much as I highly respect and admire Bill, very simply he is factually incorrect
in these statements.

	I referenced N1814 because I have a printed copy.  I do have a copy of N1826, but
only in PDF, not on paper.

	WG5 / N1827 is the difference document between N1814 and N1826.  It contains only
a few typographical and formatting changes.  There is no wordsmithing or clarification.
Thus, the "substantial work to clarity" must have happened before the publication of
N1814.

	I also did a physical comparison of the text regarding the BLOCK construct between
N1814 and N1826.  There are no differences.

	I did not print a copy of N1826 because of the minor differences between the two
documents.  Since I am spending my own money, it seemed to me not worth the cost of 311
sheets of paper, half of an ink cartridge, and the cost of binding the copy in order to
correct a few typos.
 
> 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

	That was what I thought, based on the context of the current text and the
development history.  If that is truly the case, then my main conclusion is correct.  We
have developed a new form of host association, but without declaring it explicitly.

	It's definitely interpretation material.  I will write one up, but due to
competing priorities, I probably will not have it ready until tomorrow.  BTW, I read John
Reid's proposed interpretation, and his is completely independent logically from this
issue.  Either can stand on its own merits and there is no conflict between the two.

	I have to go now.  I'll address this issue in more depth later today.

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

	<snip>

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


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>
USA
Linked-In:  http://www.linkedin.com/in/craigdedo