Subject: hpff-interpret: EXTRINSIC comments/questions

From: [email-masked]
Date: Tue, 23 Jan 1996 16:17:38 +0100 (CET)

---------------------------------------------------------------------------
[email-masked] is a mailing list for corrections,
clarifications, and interpretations related to High Performance Fortran.
Instructions for adding or deleting yourself from this list appear at the
bottom of this message.
---------------------------------------------------------------------------

Hello,

some questions and comments on EXTRINSIC are added below. I assembled them when
collecting some material for the Fortran-C interoperability report of WG5.
My general impression is that section 6 should be (a) sorted to put the v1.1
additions to more suitable places and (b) significantly shortened to only
those aspects that do not depend on possible restrictions for 
<extrinsic-kind-keyword>s other than HPF. 
All such material should be collected in the annexes (A and B for the HPF_* 
keywords) to separate the general EXTRINSIC functionality from the specific 
implementations of the two interfaces defined within the HPF language.

Regards,
Michael Hennecke

 ======================================================================
  Michael Hennecke      http://www.uni-karlsruhe.de/~Michael.Hennecke/ 
 ----------------------------------------------------------------------
  University of Karlsruhe         RFC822: [email-masked] 
  Computing Center (G20.21 R210)           BITNET: [email-masked] 
  Zirkel 2  *  P.O. Box 69 80                 Phone: +49 721  608-4862 
  D-76128  Karlsruhe                               Fax: +49 721  32550 
 ======================================================================

HPF v1.1, section 6

143:14+  change "subprograms" to "procedures"
         SISAL and C extrinsics are not subprograms.

143:14+  Is a FORTRAN_LOCAL subprogram an HPF subprogram?

143:16.5 "It defines the means for handling distributed and replicated
          data at the interface."

         I do not see these definitions in section 6, which only
         imposes general restrictions on the callee in 6.3.
         IMHO, this is not in the scope of this section which only
         defines the caller's (declaration) part. Everything else is
         processor-dependent, except for the HPF_LOCAL and HPF_SERIAL
         specifications which are also not in section 6 but in annex A and B.

144:6.8  "should be declared EXTRINSIC ..."
         Is this a requirement or a recommendation?
         (Since HPF supports EXTERNAL, it probably cannot be a requirement.)
         If it is a recommendation, perhaps add more explanatory material
         like "Because HPF has to communicate some information about the
         distribution/alignment of procedure arguments, a user's assumptions
         about implementation details are more likely to fail as in sequential
         languages."

144:11   "6.2  Definition and Invocation ..."
         Change "Definition" to "Declaration". Except for the requirement
         that EXTRINSIC(HPF) is redundant and may appear in the definition
         of an HPF subprogram, this section is about declaring interfaces
         to EXTRINSIC procedures, not defining them.

144:26   Change "\bnf{extrinsic-kind}" to "\bnf{extrinsic-kind-keyword}"
         (alternatively, delete \bnf markup.)

144:29   Add a reference to annex B for HPF_SERIAL specifications:
         "The keyword HPF_SERIAL is intended for use in calling uniprocessor
          routines described in Annex B."

144:41.6 change "subprogram" to "procedure" (see 143:14+)

144:42.7 change "subprograms" to "procedures" (see 143:14+)

145:1+   The examples given implicitly require the C_LOCAL and SISAL
         languages to be able to pass arrays by descriptor because
         assumed shape arrays are passed to them.
         On 146+:43+, COBOL_LOCAL also recieves assued-shape arrays.
         This should be avoided. However: all argument passing becomes 
         tricky if the EXTRINSIC is not Fortran...

145:9+   The OPERATOR(+) interface is not standard-conforming:
	 add INTENT(IN) for X and Y.

145:32.8 "The intent is ... "
         Context lost... This should be a general requirement on EXTRINSIC,
         here it appears after the discussion of a generic interface example.

145:33.7 change "has been" to "had been"

146:2    "... mut have an explicit interface"
         Question 1: shoudn't this be "EXTRINSIC interface"? A mere interface
                     block does not help, except for the default case.
         Question 2: Shouldn't this requirement be less strict? To my 
                     understanding, the only case where such an interface is
                     always required is when the procedure arguments are 
                     distributed HPF arrays (or the Fortran standard requires 
		     one).

146:11   Move this stuff up to then beginning of 6.2.

146:28   "main-program"
         Change from \tt to \bnf markup

146:41   "... as the host scoping unit" (and the following example)
         There is no such thing: host association is restricted to internal
         and module subprograms, and derived type definitions (14.6.1.3).
         An interface block always has its own scope, it cannot access anything
         from outside by host association. Introducing such mechanisms
         in HPF seems to be very confusing.

147:38   change " ahs " to " has "

HPF v1.1, annex A

162:8    Change "accessible to an extrinsic procedure (arrays passed as 
         arguments)" to "passed as actual arguments to an extrinsic procedure",
         because there are more arrays accessible than array arguments: COMMON
         and MODULE objects.

164:4.5  "distributed HPF array"
         Does this include replicated arrays? If not, list them in the same
         lines as scalars.

165:3+   change \tt to \bnf markup three times

165:6    change "the the" to "the"

166:8.5  change "type" to "type and type parameters"

178:30   change "type" to "type and type parameters"

---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to
[email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------