Subject: Criterion for intrinsics: F90 defined functions

From: "Rex Page" <[email-masked]>
Date: Fri, 08 May 92 16:45:05 -0500

To me it seems imprudent to define extensions to Fortran 90 in HPF
because it circumvents the usual sources of new features of
Fortran (ISO and ANSI) and could lead to eventual conflicts between
HPF and standard Fortran.  I hope we'll be able to do everything
within the language (e.g., as comment-style directives).

The FORALLextension will, it appears violate this principle, but
maybe that will be the only exception.

Intrinsic functions need not go beyond Fortran 90.  We just need
to take care to defined within the existing Fortran 90 framework,
potentially implementable as part of an HPF module.  Vendors might
not implement them in this way, but HPFF can define them so that
such an implementation is possible.

CRITERION: All HPF intrinsics should be implementable as defined
functions in Fortran 90.

All of the intrinsics proposed so far meet this criterion, I think,
but we need to be a little careful in how we describe them.

For example, MAXLOC with a DIM parameter (Steele) could be
implemented as an overload of the F90 intrinsic MAXLOC.  There
would be a definition in the HPF module of 7 MAXLOC functions,
one for each possible rank of the array argument.  The programmer
gets the same facility that an intrinsic F90 MAXLOC with an
optional parameter would provide, but HPFF would define MAXLOC
as a generic function (in F90 terms) with 7 incarnations.
Technically, the DIM argument would not be optional in these
incarnations, but since the F90 intrinsic MAXLOC could be invoked
by leaving off the DIM argument, it would behave, from the source
code standpoint, as an optional argument.

Similarly, proposed bit manipulation funtions (POPCNT etc.)
would not be "elemental" in a technical F90 sense, but would be
generic F90 functions with definitions for each possible rank of
the argument (rank=0 through rank=7).  This gives the effect of
elemental functions and avoids extending F90.

Rex Page

---

From: Guy Steele <[email-masked]>
Date: Mon, 11 May 92 10:32:26 EDT

I am in complete agreement with the following message
with one very important exception.

   Date: Fri, 08 May 92 16:45:05 -0500
   From: "Rex Page" <[email-masked]>

I will take strong exception to the remark about "the usual sources".
While I agree that, as a matter of fact, ANSI and ISO committees have
been sources of features, as a matter of principle they are not
supposed to be--certainly they are not intended to be the *sole*
source of new design!  On the contrary, HPF is exactly the kind of
industry activity that ought to provide the first-level experiments
from which grist may be chosen in future for the X3J3 mill.

"Standardization" is not the same thing as "invention".  The
theoretical purpose of an ANSI committee is to standardize existing
practice, not to invent new practice.  Such committees do find
themselves forced into invention for various reasons (to resolve
inconsistencies, enable portability, achieve consensus, etc.), but
that should not be their primary purpose.

Moreover, I have had exchanges with long-time members of X3J3 of the
general form: "Why is this restriction in the Fortran 90 standard?"
"Just to avoid complexity for now, but we strongly encourage
companies like yours to explore extensions in this direction".

So I think HPF need not be afraid to explore extensions to the
language for fear of offending X3J3 or ANSI!  Of course, I would also
recommend that we be conservative; we should not add features
frivolously or gratuitously, but only to meet some perceived need,
consistent with our overall goals.

Foe example, I do not necessarily think we should accept all of the
intrinsics proposals I have recently generated.  I think some meet
real needs; others I created because other people had expressed an
interest and no other proposals had been forthcoming on the mailing
list yet (and I am fairly practiced at spewing forth first drafts of
this kind of text).  (On the other hand, I don;t think any of these
proposals is gratuitous; Thinking Machines will be providing *some*
form of that functionality in each case--the question is whether HPF
whishes to require it of, or recommend it for, all HPF
implementations.)  So now we have some material to attract pot-shots
and, preferably, counterproposals.

This is an excellent goal.

All these points are well taken.

--Guy

---

From: "Rex Page" <[email-masked]>
Date: Mon, 11 May 92 12:22:47 -0500

[Steele]                        ... ANSI and ISO committees have

   "Standardization" is not the same thing as "invention".  The
   theoretical purpose of an ANSI committee is to standardize existing
   practice, not to invent new practice.

I've been thinking of HPF as something more like a standard than an
experiment.  I hope it will be possible for HPF programs to survive
in a "Fortran 2000" environment, if there is one.  This will be
easy to manage if HPF's experiments are compatible with Fortran 90.
It will be hard to manage if HPF includes extensions that conflict
with future changes.

   [Steele]

The proposed data distribution directives and intrinsics do seem
to be on the conservative side.  They standardize existing practice
in a sense (CM Fortran, Fortran D, etc.), and people seem inclined
to encode them within Fortran 90 using comment-style directives
where necessary.  I hope this continues.

I agree that we should not concern ourselves about offending X3J3.
What we should worry about is the survivability of HPF code in the
face of possible extensions to Fortran 90 in the next decade.

Rex Page

---

From: Guy Steele <[email-masked]>
Date: Mon, 11 May 92 13:39:39 EDT

Right.  I think we are now in "violent agreement"!

--Guy