Fine by me. Considering the lateness of the hour, I don't think we should
change anything that doesn't have universal support. But I'll try to answer the
points you raise anyway...
> First, Eric argues that array_sizes are harder for the implemenation to
> return because they are not input argument.
What I said was that it is awkward for applications to derive the count from
the array sizes and the combiner. It's pretty trivial to implement either way,
actually. Slightly more work to return the sizes, but my primary objection is
just the ugliness of the user interface.
> If they are not returned by GET_ENVELOPE then the user must do the
> calculation. There was concern that errors in doing this would lead
> to mistakes in array sizes passed to GET_CONTENTS.
True. But this still does not free the application writer from having to get
things right, because they must correctly index into the arrays returned by
GET_CONTENTS in order to use that information. So we're not really saving them
all that much work.
> Second, the issue of generality was real. As David pointed out, you needed
> two counts for one of the new datatypes. If we return a single count and then
> add a constructor in the future (did I say that, really, aahhh!) it
> may mean changing these calls too.
Sounds like a solid argument for going with the count! :-)
I really don't see generality as an issue. Fundamentally, I think it makes
perfect sense to view datatypes as some sort of combiner plus some number of
things to combine. Anything fancier than that could easily be folded into
GET_CONTENTS should the need arise.
> Third, not all calls have a count or it is called something else. For
> example, DUP would return count=0 I assume?
For DARRAY and SUBARRAY, I'm assuming that we would pass back ndims. For DUP we
could choose 0, 1 (my own preference), or even MPI_UNDEFINED. Pick your
favorite poison.
> Fourth, the user can get the count from the combiner and other array sizes
> returned if they need it without calling GET_CONTENTS
But not easily. At the moment, the code to do that would look something like
this:
GET_ENVELOPE()
switch (combiner) {
case CONTIGUOUS:
count = f1(numi, numa, numd);
break;
case VECTOR:
count = f2(numi, numa, numd);
break;
...
}
So yeah, it's possible, but it's ugly.
> (and needing it is less likely then the array sizes in my opinion).
Well, I did suggest passing back both in my minimal-change proposal. I think
that count is important regardless of whether the array sizes are also
important, and I think that logically it makes more sense in the envelope
information than in the contents. But that's just personal taste, I suppose.
> Finally, one gets the count as the first returned value in the integer
> array from GET_CONTENTS so not giving it in GET_ENVELOPE does not seem
> a big deal to me.
Not always! For DARRAY, it is the third integer in the array, not the first. So
you'll still need the switch() statement.
-- Eric Salo Silicon Graphics salo@sgi.com