(j3.2006) Question about statement functions and hostassociation

Bill Long longb
Sat Jul 22 00:18:55 EDT 2017


> On Jul 22, 2017, at 1:53 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
> 
> Hi Bill,
>  
> It does not say ?previously declared?.  That is what the problem is!  If it had used the wording you are saying, there would be no problem and no issue to address.

Sorry. It seemed like Van was talking about declared as well. 
>  
> It says
>    ?its definition shall have been provided earlier in the scoping unit?
>  
> Literally, ***its definition***, viz the <stmt-function-stmt>, must be ?provided earlier in the scoping unit?.

Like declarations, a statement function definition is a similar sort of non-executable statement.  However, ?earlier IN the scoping unit? is problematic. 

>  
> There is no room here for host association unless you try the Very Unconvincing Weasel that the lack of any prior definition is a ?provision? of the statement function definition.  That really does stretch Suspension of Disbelief beyond even the realms of a fantasy novel!
>  
> Fixing this is easy, just use the words you thought it already used!
>  
> However, it would be a Technical Change to the language.  Although I know of no examples, it is very plausible that someone trying to read the statement function constraints and doing what they say, instead of what would be obviously sensible.  Especially if that someone is not a native English speaker.  And so would need to be added to the Introduction.
>  
> I have no objection in principle to improving statement functions, but is that really sending the right signal?  After all, we might delete them in 2020, so enhancing them now seems ... a waste of effort.

Agreed. Making edits for statement functions should be at the bottom of the priority queue.  The part of the queue we?re likely not going to reach.

Cheers,
Bill

>  
> Cheers,
>  
> From: Bill Long
> Sent: Friday, July 21, 2017 5:33 PM
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) Question about statement functions and hostassociation
>  
> If you access something by host or use association, how could it not have been previously declared (at least implicitly) in the host or module? Once you start executing the section of code that is accessing things from a host or module, the declaration part of that host or module is not going to be executed while you current scope is executing. What you get to access is what was there when you started executing. Seems like that qualifies as ?previously?. 
> 
> Cheers,
> Bill
> 
> 
> > On Jul 21, 2017, at 10:14 AM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
> > 
> > On Fri, 2017-07-21 at 15:29 +0900, Malcolm Cohen wrote:
> >> I agree that on the face of it, C1576 forbids use of a host-associated
> >> statement function within a statement function definition. This
> >> wording is identical to that of F95.
> > 
> > There are numerous places where we say "defined previously" or
> > "previously defined" without saying "or accessed by use or host
> > association," but we (and common practice) appear to agree that
> > "previously defined" includes "accessed by use or host association" in
> > those cases. For example, 7.3.2.2p1, 7.3.2.3p2, C733, C745, 8.5.13p2,
> > C881, C882, C1515. 8.9p5 says accessed by use or host association, and
> > goes into a great deal of detail about what attributes have to be
> > earlier declared. The last sentence of 14.2.2p2 explicitly says that a
> > use-associated entity is considered to be previously defined (but it
> > doesn't say "or declared" so it's not obvious whether a use-associated
> > variable is previously declared). I couldn't find anything similar for
> > host association, but that doesn't mean it's not there. Maybe I missed
> > one, but it seems that C1577 is the only place that says "earlier in the
> > scoping unit or made accessible by use or host association." If we
> > assume "earlier" or "previously" includes "or accessed by use or host
> > association" could we just delete "or made accessible by use or host
> > association" in C1577 so it doesn't make C1576 look like it prohibits
> > them? Could we delete it in 8.9p5, and just say that the specified
> > attributes have to be declared previously?
> > 
> >> 
> >> 
> >> 
> >> A quick test of 4 compilers found none which complained about this
> >> constraint violation. Probably no-one noticed. (I do recall the
> >> statement function constraints were so badly written in Fortran 90
> >> that I decided to ignore all of them and just do whatever I thought
> >> was best!).
> >> 
> >> 
> >> 
> >> OTOH I am not sure it is worth making into an official new feature?
> >> which we?d need to do if we cared about it. (It is certainly
> >> plausible that some compiler somewhere actually enforces this.)
> >> 
> >> 
> >> 
> >> Cheers,
> >> 
> >> -- 
> >> 
> >> ..............Malcolm Cohen, NAG Oxford/Tokyo.
> >> 
> >> 
> >> 
> >> 
> >> From: j3-bounces at mailman.j3-fortran.org
> >> [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Van Snyder
> >> Sent: Tuesday, July 18, 2017 10:36 AM
> >> To: j3 <j3 at j3-fortran.org>
> >> Subject: (j3.2006) Question about statement functions and host
> >> association
> >> 
> >> 
> >> 
> >> 
> >> 19.5.1.4 says a nested scoping unit has access to named entities from
> >> its host.
> >> 
> >> C1576 says that if a reference to a statement function appears in the
> >> <scalar-expr> of the definition of a statement function, "its
> >> definition
> >> shall have been provided earlier in the scoping unit."
> >> 
> >> I couldn't find a place where "shall have been provided earlier in the
> >> scoping unit" is specified to include host association.
> >> 
> >> Can a reference to a statement function within the <scalar-expr> of
> >> the
> >> definition of a statement function be a reference to one accessed by
> >> host association?
> >> 
> >> 
> >> _______________________________________________
> >> J3 mailing list
> >> J3 at mailman.j3-fortran.org
> >> http://mailman.j3-fortran.org/mailman/listinfo/j3
> >> 
> >> 
> >> 
> >> Disclaimer
> >> 
> >> The Numerical Algorithms Group Ltd is a company registered in England
> >> and Wales with company number 1249803. The registered office is:
> >> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
> >> 
> >> This e-mail has been scanned for all viruses and malware, and may have
> >> been automatically archived by Mimecast Ltd, an innovator in Software
> >> as a Service (SaaS) for business.
> >> 
> >> 
> > 
> > 
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Bill Long longb at cray.com
> Principal Engineer, Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9143
> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> 
> 
> Disclaimer
> 
> The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
> 
> This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425





More information about the J3 mailing list