(j3.2006) Question about statement functions and host association

[Bill Long]

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