Subject: Resend of "an implementor's request for clarification"

From: Guy Steele <[email-masked]>
Date: Tue, 26 May 92 15:23:54 EDT

Date: Tue, 26 May 92 08:34:13 PDT
   From: David Loveman <[email-masked]>
   Apparently-To: [email-masked], [email-masked]

   . . . . .

   An Implementor's concerns:

     Q1:  The DECOMPOSITION directive must precede a DISTRIBUTION directive
	  and ALIGN directives when the arrays and decompositions
	  relate to each other?

	    Answer:		True		False	      DontKnow

	    Note:  Please say True.

False.  Seems to me that it would be consistent with Fortran 90 to
adopt that attitude that if a name appears before its type has
been established, then the type of that name is established by the
implicit typing rules then in effect, and any following declaration
must confirm that type.

	    Example (i)

	    !HPF$  DECOMPOSITION   ...  decomposition-name  ...		
	    !HPF$  DISTRIBUTE	...  decomposition-name  ...
	    !HPF$  ALIGN		...  array-name ... decomposition-name ...

To be more specific:

!HPF$ DISTRIBUTE BROWNIE_POINTS(*) ONTO SYCOPHANTS

The implicit typing declarations would establish BROWNIE_POINTS as
having type REAL, and an error would then ensue because it ought to
be of type TEMPLATE.  (If, however, in a distant future we were to
permit

      IMPLICIT TEMPLATE(B)

then BROWNIE_POINTS would then have implicit type TEMPLATE, which might
be confirmed by a subsequent TEMPLATE definition.)

The same comments apply to SYCOPHANTS: the implicit typing rules
would make it of type REAL when it ought to be of type PROCESSORS,
so in practice you would get an error.

So the answer to your question is "true" in the absence of IMPLICIT
TEMPLATE, but "false" when looking forward to a more general
hypothetical future where HPF is absorbed into Fortran 90.

     Q2:  Must all f90 declarations for  array-name  be uttered before
	  an ALIGN directive referring to array-name is seen?

	    Answer:		True		False	      DontKnow

	    Notes: One can write in f90 in any order, e.g.:

		  REAL	 x
		  DIMENSION x(100)

	    Furthermore, COMMON, INTENT, PUBLIC, PRIVATE, ALLOCATABLE, etc.,
	    can be written in random order provided that combination of
	    attributes can semantically merge.  F90 does have the composite
	    type statement, but F90 allows for specifying the attributes
	    on separate statements, too.

	    We don't want unneeded implementation complexities because of the
	    directives, if possible.

	    Example (ii)

	    !HPF$  ALIGN	...	x	...
		   REAL x; DIMENSION x(100)

		   REAL x; DIMENSION x(100)	! this is the only combo
	    !HPF$  ALIGN	...	x	...	!  I'd like to be okay

		   DIMENSION 	x(100)
	    !HPF$  ALIGN	...	x	...
		   REAL x

				   True		False		DontKnow

Again, to be consistent with a Fortran 90 future, I would say "false".
"ALIGN" is just another attribute.  Of course, if "x" first appears in
an ALIGN statement, its type will be established by implicit typing
rules and can only be confirmed by a subsequent type statement.

     Q3:   An association directive with an  entity-list, e.g.,

	    !HPF$ SEQUENCE_ASSOCIATION  s

	   must be processed when seen and there can be no f90 declaration
	   statement or ALIGN directive referencing  s  appearing ahead it.

	   Answer:		True		False		DontKnow

Is SEQUENCE_ASSOCIATION to be considered an attribute?
Do you envision being able to say

      INTEGER,DIMENSION(100),SEQUENCE_ASSOCIATION::P,Q,R

?

     Q4:   An association directive with no  entity-list, e.g.,

	    !HPF$ SEQUENCE_ASSOCIATION

	   must appear before any declarations are made?

	   Answer:		True		False		DontKnow

		   SUBROUTINE T(X,Y)
	     !HPF$ SEQUENCE_ASSOCIATION  
		   REAL x(100), Y(100)

	   or should it be

	     !HPF$ SEQUENCE_ASSOCIATION  		! This in my opinion is
		   SUBROUTINE T(X,Y)		!  the correct form
		   REAL x(100), Y(100)		

	   but never

		   SUBROUTINE T(X,Y)
		   REAL x(100), Y(100)
	     !HPF$ SEQUENCE_ASSOCIATION  

The problem is that a program unit currently must begin with a SUBROUTINE
or FUNCTION statement or perhaps a PROGRAM statement.  Maybe you just have
to use the entity-list form to disavow sequence association for dummies.
Or maybe we make a weird exception if the entity-list-less form immediately
follows a SUBROUTINE, FUNCTION, or PROGRAM statement.

     Q5:   A decomposition-name  or a  processor-name, i.e., an abstract name
	   from directives, must not be the name of any other entity in a
	   scoping unit (other than the name sharing of COMMON block names
	   that already is in Fortran).

	   Note:  Please, please, say true on this one.

	   Answer:		True		False		DontKnow

True.

     Q6:  An  align-subscript-name  is described as a 'distinct, simple variable
	  name'.  Is this the same as the statement:  'an align-subscript-name
	  has the scope of the directive only'?

	   Answer:		True		False		DontKnow

False; the two statements are not the same.  However,
I think that both statements are intended to be true.

     Q7:  The type of an  align-subscript-name  is default integer, and the
	  appearance of an  align-subscript-name  on a type statement has no
	  effect.

	   Answer:		True		False		DontKnow

	   Note: align-subscript-names  are akin to  implied-do-variables on
	     DATA statements and statement function dummy arguments in that the
	     scope of these guys is that statement only, but appearance of the
	     name on a type statement (assuming it appears ahead)
	     is permitted and honored.  Otherwise implicit typing rules are in
	     effect.

True.

     S1:   If Q6 is true, then the statement

	      align-spec-expr  is  specification-expr      -- for ALIGN
	      align-spec-expr  is  int-expr		-- for REALIGN

	   is wrong since an align-spec-expr will contain  primaries  that are
	   align-subscript-names.  Such critters are not allowed either in a
	   specification-expr  or an  int-expr   as defined in the f90 Manual.

Right; so we'll have to fix that.

--Guy