<Array TypeSpec> ::= CommonMetaOperatorPkt(MP_Array) <Prototype AP>
In the first case, the prototype consists
of a common meta operator whose value is
MP_Array and whose
number of arguments field is non-zero.
The common meta operator has a prototype specifying the type of
each argument to the
Here the number of arguments field specifies the number of data items
that will appear later in the data packet and not the
number of arguments that immediately follow the operator within the prototype.
Consider, for example, a matrix of reals given as an array of arrays.
In the second case, a
operator with 0 in the number of arguments field appears in a
As in the first case, the nested prototype gives the type of each of
the arguments of the top-level operator.
The 0 in the number of arguments field of the meta operator
indicates that the actual number of arguments the operator
has was not known at prototype specification time and will be given as
an IMP_Uint32 in the data packet in the place where this
operator would have appeared (this value could be 0).
Consider an array of arrays of different lengths.
((-1, -2, -3), (-4, -5)) in Figure 5.
The prototype operator on line 1 is an array with no arguments,
indicating that at this node's position in the linearized tree (data
packet) the receiver should look for an IMP_Uint32 giving the number of
arguments for the subarray,
as seen on lines 4 and 5.
The receiver knows from the prototype which operator should appear
What the sender cannot say at prototype specification time is how many arguments
it actually has.
The head of the prototype, line 1, is an
operator with 0 in the #args field, so the first thing the receiver
would look for is an IMP_Uint32 giving the length of the first
The receiver would read in the ``3'' on line 4 and then read in three
IMP_Sint32s, as specified by the nested prototype on line 3.
After having read in the first subarray, the receiver would know to
look for the next IMP_Uint32 giving the length of
the next subarray, and so on.