Subject: hpff-doc: mapping-subr.tex comments

From: Carol Munroe <[email-masked]>
Date: Thu, 17 Oct 96 15:07:30 EDT

---------------------------------------------------------------------------
[email-masked] is a mailing list for HPF 2.0 language specification
authors and editors.  Instructions for adding or deleting yourself from this
list appear at the bottom of this message.
---------------------------------------------------------------------------

I apologize for reading this text and sending out comments so late.  I'm
including a mixture of petty changes, mostly inserting commas, and
serious technical questions about a couple of points.

Section 4.1, p. 64, l. 44
	I would change "(in this case of course there is no ALIGN ...)"
	        to     "(in this case, of course, there is no ALIGN ...)"
Section 4.1, p. 65, l. 7
	I would change "This is in effect a transcriptive form..."
	        to     "This is, in effect, a transcriptive form..."
Section 4.1, p. 65, l. 15-16
	I would change "Now remapping can happen ..."
	to             "Now, remapping can happen ..."
Section 4.2, p. 65, l. 33
	I would change "...for the called subprgram and that interface..."
	to             "...for the called subprgram, and that interface..."
Section 4.2, p. 65, l. 47
	I would change "...see for instance sections..."
	to             "...see, for instance, sections..."

Section 4.4.2, p. 69, lines 1-4:
  The restriction that "an inheritee must be a dummy argument" has
been made a formal constraint here. Shouldn't at least two more
restrictions, the ones that an ineritee not be a distributee or an alignee,
also be stated as formal constraints to make the BNF a little more complete?
In other words, I suggest replacing

  \begin{constraints}

  \item An \textit{inheritee} must be a dummy argument.

  \end{constraints}

  \begin{users}
  This constraint is relaxed for pointers under the approved extensions
  (see section~\ref{POINTERS-SECTION}).
  \end{users}

with 

 \begin{constraints}

 \item An \textit{inheritee} must be a dummy argument.
 \item An \textit{inheritee} must not be an \textit{alignee}.
 \item An \textit{inheritee} must not be a \textit{distributee}.

 \end{constraints}

 \begin{users}
 The first constraint is relaxed for pointers under the approved extensions
 (see section~\ref{POINTERS-SECTION}).
 \end{users}

***
Section 4.5 Equivalence and Partial Ordering on the Set of Mappings

The existing text states:
p. 73, l. 45
	"The set of mappings in endowed with a partial order 
	 modulo a certain equivalence."
p. 74, l. 20
   "Now the partial order on mappings is defined."
Comments:
	First, a partial order on a set must be a relation, <=, that is
	a) reflexive:  A <= A  for all A
	b) transitive:  A <= B and B <= C implies A <= C, for all A,B,C, and
	c) antisymmetric: A <= B and B <= A implies A = B, for all A and B.

There are problems here with all three of these properties. First, (a)
reflexivity fails, without at least limiting the set to the class of "named
objects". 

Then (c) antisymmetry is a problem, unless, as I believe was actually
intended, the claim of a partial ordering is really being made for the set
of equivalence classes of mappings of named objects, as indicated by the
references to "mappings ... modulo equivalence" on the following page.
Otherwise, it is easy to find examples of conformable named objects with
similar mappings (or no explicit mappings) that qualify as specializations
of each other without the objects being equal.

Transitivity (property b) also does not appear to follow from this current
definition of specialization, as discussed below.

So the phrase "here the partial order on mappings is defined" might be 
replaced by an introductory comment like

	"Here we define a relation between (named? mappable?) data objects
(mappings?):"

For an example of why the current definition of "S is a specialization
of G" might not establish a transitive relation, consider the following:

	REAL, DIMENSION (100,200) :: A,B,C,D
	!HPF$ ALIGN WITH D        :: A
	!HPF$ INHERIT 	          :: B
	!HPF$ DISTRIBUTE (BLOCK)  :: C

I believe that, by the given definitions, 
   (i) the mapping of B is a specialization of the mapping of A
	  since neither ultimate align target has an explicit mapping,
though the ultimate align target at B has an implied mapping of 
DISTRIBUTE * ONTO *),

   (ii) the mapping of C is a specialization of the mapping of B
	  since B has the INHERIT attribute,

   but the mapping of C is NOT a specialization of the mapping of A,
	  since the ultimate align target of C has an explicit
	  distribution, while that of A has none, and A does not have
          the INHERIT attribute.

Maybe the definition can be fixed up to provide a transitive relation on
the set of mappings of named objects, in which case the rest of the section
can be kept pretty much as is (transitivity is essential for an equivalence
relation), but I couldn't think of a quick fix right off. Another option is
to forget about a partial ordering completely, and just leave this set of
conditions as it is, as a definition to be referred to in two later places
in the text. I will point out below the remaining references that might
need some changes, if the definition of specialization is kept as it is.

****
Section 4.5, p. 75, ll. 8-18 currently reads:
  \begin{itemize}
  \item Any mapping is a specialization of itself.

If kept at all, I would change "Any mapping is a specialization of itself."
to             "Any mapping of a named object is a specialization 
		of itself."
(the original statement is not true for all mappings, because of
the one-sided requirement of being a named object)

  \item If \(A\), \(B\), and \(C\) are named objects, and if the mapping
    of \(A\) is a specialization of the mapping of \(B\) and the mapping
    of \(B\) is a specialization of the mapping of \(C\), then the
    mapping of \(A\) is a specialization of the mapping of \(C\).

This property, though desirable, does not clearly follow unless the
definition is somehow changed.

  \end{itemize}

  That is, the specialization relation, as applied to mappings of named
  objects, is reflexive and transitive, and it can therefore be applied
  to produce an equivalence relation on the set of mappings of named
  objects: two such mappings can be said to be equivalent iff each is a
  specialization of the other.  With this definition, the specialization
  relation yields a partial ordering on the set of mappings of named
  objects[,] modulo equivalence.  The \texttt{INHERIT} mapping is the
  unique maximal element in this partial order.

Unless the transitivity property is established, this paragraph, as well
as the preceding itemized list, could just be dropped. (It is also not
clear whether there could be a single equivalence class containing
all named objects with the INHERIT attribute, or whether rank and shape
matter as well, or whether that class would also include other named
objects with implicit mappings.)

****
Section 4.6, p. 76, ll. 6-10 currently reads

  \item A plain Fortran program (i.e., with no HPF directives) will
    continue to be legal without the need to add additional interfaces.
    ...

A qualification is needed here, to make sure that sequential and
nonsequential arrays always correspond to the right type via argument
association. I would modify this to

  \item A plain Fortran program (i.e., with no HPF directives) will
    continue to be legal without the need to add additional interfaces,
    at least in a compilation environment in which all variables are
    sequential by default. ...

****
Section 4.8.3 Examples of Sequence Association, p. 80, l. 5

Current text:  "Likewise, by rule 2 and 4"
Suggested:     "Likewise, by rules 2 and 4,"

****
Section 4.8.3, p. 80, ll. 9-10

Current text:  "requires either that ET and X are both sequential arrays
	 or that ET and X have the same shape and have the same sequence
	 attribute."

The fragment shown doesn't indicate whether or not an explicit interface
is present. If it is, and if ET and X have the same shape, they need not
have the same sequence attribute, so I would suggest as replacement text:

  "requires either that ET and X are both sequential arrays or that
   ET and X have the same shape and (in the absence of an explicit interface)
   have the same sequence attribute."

---------------------------------------------------------------------------
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>
---------------------------------------------------------------------------