Split C's handling of global arrays was influenced by HPF, but is quite different [62]. Here, there are no directives or alignment clauses; rather, array operations are an extension of the array declaration. There is also such a thing as a spread pointer, which is an alternate form of a global pointer. The programmer has full control over array layout.
HyperC [57] is a ``second generation data parallel extension of C'', according to the authors from Ecole Polytechnique. The language provides support for collections (ensembles of processors get a name, and then variables can be declared to be spread across that named processor pool). Communications are explicit operators in the language.
Data Parallel C (DPC) is a recently proposed data parallel extension to standard C. DPC is implemented by a product from Pacific Sierra. It resembles HPF and is based on Thinking Machines older C*.
Several papers have pointed out the relationship between CM-Fortran
[179]
and
subset HPF. Surry and Wylie [175] lists those CM constructs,
modulo syntax, that are in 
HPF (they coined this neat logo).
Knies, O'Keefe and MacDonald [111] use experiences
with the CM Fortran compiler as an object lesson to future HPF programmers
and compiler writers.
Fortran D [74] and Vienna Fortran [45,189,187] are variants of HPF to a great degree. Vienna Fortran, the successor to SUPERB [190], supports array overlaps and routines that return data in a different order from which it was received. It is now called the Vienna Fortran Compilation System, or VFCS. See Fahringer [66,67] for the sort of performance tools that come along with this compiler. VFCS compiles both HPF and Vienna Fortran to the same internal program. See [19,20] for the definition of the Vienna Fortran language. Fortran D is a research version of HPF that supports interprocedural analysis, irregular computation, index vectors, and parallel I/O. A variant of Fortran D is being compiled by Fox et al. at Syracuse. They call their language ``Fortran 90D'' and ``Fortran 77D'' [35]. Because their Fortran 90D is so close to HPF, they refer to their language and compiler as ``Fortran 90D/HPF'' and or HPF/Fortran 90D. (Doesn't exactly roll off the tongue, does it.) It takes Fortran 90 as input, has lots of run-time support, recognizes certain patterns (which are translated into intrinsic calls), but does not do ``automatic'' parallelization. The compiling techniques used are described in [34,36].
Cray's CRAFT language for the T3D [153] was based on Fortran D and was designed before HPF came out so while it has similarities to HPF it has a different syntax. It is a cross between X3H5 and HPF, but its I/O model is superior (in my opinion). The DOSHARED directive [137] controls parallel execution as does INDEPENDENT, except they add the ON clause to make sure that all references on that array are local; current (1995) version of CRAFT has a 2n restriction on distributed dimensions. In Supercomputing '95, it was announced that Cray would be moving to HPF, first via CRAFT-90, and then with CRAFT being an extrinsic type in PGHPF. In fact, HPF_CRAFT made it into the HPF 2.0 language specification as an appendix (not pre-approved, but defined anyway).
There is even a C++ variant of HPF, called pC++ [28]. In this language the basic notion is distributed collection. The programmer describes the distribution of a collection over the memory hierarchy and over the array of machines. Operations can be performed in parallel on a collection. The hope is eventually to allow interoperability between pC++ distributed collections and HPF distributed arrays. What is called a ``template'' in HPF is called an ``abstract coordinate system'' in pC++.
In fact, the Parallel Compiler Runtime Consortium coined a new acronym to cover HPF and pC++ (and data parallel forms of ADA): HPL for High Performance Language [73]. One goal is to allow all HPL's to interoperate with each other.
The participants in the Cancun panel [184] made a number of interesting observations on HPF's role as a portable parallel language. Steve Otto thought that objects would be needed but that they would need to interoperate with HPF. At the lowest level, methods should be written in Fortran. Higher level methods should be in C++. I believe vendors will develop their own directives to give clues to their own compilers; APR's imperative DO directive, !APR$ PAR DO ON () is often invaluable.
And then there is ZPL, designed by Larry Snyder and his group at the University of Washington. They have compared the results of a number of benchmarks written in both HPF and ZPL; ZPL programs are shorter, performance is comparable [126].
Folks at INRIA in France who are working on the PANDORE compiler project (also data parallel) have written an HPF-to-PANDORE translator; the output is C. The goal of this project was to be able to test their compiler using HPF programs [104]. The Pandore programming environment is data-parallel C subset, based on HPF-like distribution. The environment provides a compiler, a machine independent run-time tool, and execution analysis tools, including a profiler and a trace generator. Another INRIA project which has the same goals as HPF but does not want to rely on a compiler (``compilers are tricky to implement'') is Fortran-S [29]. The Fortran-S/SvmView programming environment allows easy porting of applications on architectures such as the Intel Paragon XP/S and the KSR1. Their approach is sequential Fortran 77 code plus directives to specify parallel loops and shared variables. The generated code takes advantage of KOAN, a runtime virtual shared memory package for distributed memory machines. Gives you X3H5 on a cluster...