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

Mon Aug 30 14:37:17 EDT 2010

Hello,

 as far as I remember, there were indeed problems with the BLOCK construct
in drafts up to beginning of this year. Then, BLOCK was made a scoping
unit, and the concept of "inclusive scope" was introduced to assure that
the block construct has access to entities declared outside it.

There may still be issues with this (I don't understand the matter well
enough to tell whether the IEEE stuff is one), but I suspect that - unless
a really bad inconsistency is identified - the fixes will be against
inclusive scope rather than host association.

Regards

Reinhold

>>
>> 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
>
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>