On multiarray types

The most general multiarray type signature is:

$$T \verb$ [[$ \mbox{\it attr}_0, \ldots, \mbox{\it attr}_{R-1} \verb$]] $ \mbox{\it bras}$$

where $T$ is any Java type other than an array type, $R$ is the rank of the multiarray, each term $\mbox{\it attr}_r$ either consists of a single hyphen, -, or a single asterisk, *, and the term $\mbox{\it bras}$ is a string of zero or more bracket pairs, []. This signature represents the type of a multiarray whose elements have Java type

$$T \verb$ $ \mbox{\it bras}$$

In this appendix we will use ``multiarray'' as a general term including sequential multiarrays and distributed arrays.

In standard Java, arrays are not considered to be objects, but they effectively have a class--a class representing an array type. We prefer to avoid making the statement ``multiarrays have a class''. If we made this statement it would probably commit us to either:

A.

extending the definition of class in the Java base language, or

B.

creating genuine Java classes for each type of HPJava array that might be needed.

Class is such a fundamental concept in Java that option A looks infeasibly hard: would people expect us, for example, to integrate the complex runtime inquiries on HPJava multiarrays into some extended version of the Java reflection API? Or into the Java Native Interface, JNI? Such fundamental extensions to the Java platform look impractical.

Option B has its own problems. Presumably the associated class types should capture the rather complicated system of array types we have described for HPJava. Because there is an infinite number of multiarray types, the associated classes would certainly have to be created on demand by the translator. Does the translator have to create class files for these automatically generated classes? If so how should these files be managed? Distributed array types have a rather complex, multiple-inheritance-like lattice of subtype relations, illustrated in Figure A.1. This kind of type-lattice can be reproduced in Java by using interface types. But then, when we generate a new array class, we have to make sure all the interfaces it implements directly and indirectly are also defined.

Figure A.1: Part of the lattice of types for multiarrays of float

To avoid these problems an HPJava multiarray is not considered to have any class. Multiarray types are treated as a new kind of reference type in HPJava, separate from standard Java reference types.

The fact that a multiarray is not a member of any Java class has a real impact on how a multiarray can be used. For example, a multiarray cannot be an element of an ordinary Java array, nor can a multiarray reference be stored in a standard library class like Vector, which expects an Object. In practice this is not such a drastic limitation as it sounds, because the programmer can always create wrapper classes for particular types of multiarray. For example suppose we need a ``stack'' of two-dimensional multiarrays of floating point numbers. We can set this up along these lines:

$$\begin{minipage}[t]{\linewidth}\small\begin{verbatim}clas... ...Level(new float [[x, y]] on p) ; }\end{verbatim}\end{minipage}$$

So the fact that multiarrays cannot be treated as normal objects is usually a minor inconvenience, not a fundamental limitation^A.1.