Hi Rusty,
The proposal was sent to the mpi-external group, with a cc: mpi-io as a
heads-up.
I'd be happy to submit it in LaTeX. I'll try to get it out tomorrow.
Briefly, it's relation to the other proposals published in the 4/22 MPI2
draft:
At the last meeting of the MPI external group ...
Consenses was reached on using Table I as the "exposed" format.
Hopefully with some modifications. (See below)
Consenses was also reached on the MPI_TYPE_ENVELOPE() and
MPI_TYPE_CONTENTS() functions.
Good.
The remaining "datatype" function proposals were withdrawn or
discarded.
Fine.
An effort by Marc Snir in the miscellany group was discussed.
... Table I and the two functions can now go before the full Forum.
I believe my present proposal represents consenses opinion on
functionality, with some of my own ideas added on bindings.
I'm certainly open to more input and discussion.
Regarding the 'Table I' modifications:
I've stated these before, but just so that there is no confusion, let me
restate what changes I'd like to see and why.
. Uxxxx vs Txxxx and temporal uniqueness of sequence numbers
I feel that as specified it too tightly constrains both users and
implementations.
I don't think that temporal uniqueness should be required for Txxxx
sequence numbers; in fact I'll go further, it should explicitly state
that users and implementations must not assume that they are temporally
unique.
Requiring temporal uniqueness for both would be a real problem when
sending data types between processes.
I want the sequence numbers (for at least the Txxxx's) to be unique
within a given string representation but not assumed to be unique
between strings.
. if both Txxxx and Uxxxx exist (and if you totally drop the temporal
uniqueness rather than just drop it for the Txxxx's, then they can be
folded into one), then there needs to be a way to distinguish between
them in the string representations. For example, in the first example
in Table I:
329:(HV:U3291:9:1:40000)3291:(HV:(HV:U3292:9:1:400)3292:(V:R:9:1:2)
the bare 329, 3291, and 3292 are potentially ambiguous. They should all
have an initial 'T' or 'U'.
I would also prefer that the syntax be such that referenced types are
defined upon first use rather than after last use. Decoding the current
syntax requires fix ups of partially defined types. If they were
defined *immediately* after first use, that would not be necessary.
With the above changes, the above example would, I believe, become:
U329(HV:U3291(HV:(HV:U3292(V:R:9:1:2):9:1:400):9:1:40000)
And the other examples given in 'Table I' would become:
U330(X:R:100:1/99,101/98,202/97,...,10000/0)
U331(HV:U3311(V:R:100:1:100):100:1:4)
U333(S:4:i/1/0,d/6/8,c/7/56,UB/1/64)
U334(S:3:i/1/96,d/6/104,c/7/152)
Specifically, in the BNF, change:
<typeDescUser> ::= U<nonNegInt> | T<nonNegInt>
to
<typeDescUser> ::= U<nonNegInt> | U<nonNegInt>(<typeDesc>) |
T<nonNegInt> | T<nonNegInt>(<typeDesc>)
and delete <typeRep> and <createTypeRep> as unnecessary.
Here's the complete modified BNF (assuming I didn't make any errors
converting from yacc/bison syntax):
%start <start>
%%
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<Int> ::= - <digit> | <digit> | <Int><digit>
<nonNegInt> ::= <digit> | <nonNegInt> <digit>
<posDigit> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<posInt> ::= <posDigit> | <posInt> <digit>
<typeDescC> ::= b | p | c | uc | s | us | i | ui | l |
ul | ll | ull | f | d | ld
<typeDescF77> ::= p | I | L | R | D | C | DC | Char |
I2 | I4 | I8 | R4 | R8
<typeDescUser> ::= U<nonNegInt> | U<nonNegInt>(<typeDesc>)
| T<nonNegInt> | T<nonNegInt>(<typeDesc>)
<typeDescBasic> ::= <typeDescC> | <typeDescF77> | <typeDescUser>
<typeDescAdv> ::= UB | LB | <typeDescBasic>
<typeDescVec> ::= V:<typeDescBasic>:<posInt>:<posInt>:<Int>
<typeDescHVec> ::= HV:<typeDescBasic>:<posInt>:<posInt>:<Int>
<typeDescIndex> ::= X:<typeDescBasic>:<posInt>:<posInt>/<Int> |
<typeDescIndex>,<posInt>/<Int>
<typeDescHIndex> ::= HX:<typeDescBasic>:<posInt>:<posInt>/<Int> |
<typeDescHIndex>,<posInt>/<Int>
<typeDescStruct> ::= S:<posInt>:<typeDescAdv>/<posInt>/<Int> |
<typeDescStruct>,<typeDescAdv>/<posInt>/<Int>
<typeDescSimple> ::= <typeDescBasic> | <typeDescVec> |
<typeDescHVec> | <typeDescIndex> |
<typeDescHIndex> | <typeDescStruct>
<typeDesc> ::= <posInt> <typeDescSimple> | <typeDescSimple>
<start> ::= <typeDesc>
%%