First, some mechanical items:
. The language neutral prototype has two arguments, the C prototype has
3, the FORTRAN prototype has 4. Either the C and FORTRAN prototypes
should be modified (eliminate one argument) to bring them in line with
the language neutral version, or (more likely) the language neutral
version should have one argument added: charDataTypeLen.
. THe C prototype has:
char charDataType
presumably this should be:
char *charDataType
Non mechanical:
. I don't like the fact that there is no way to find out how long a string
is needed to hold the ASCII encoding of the datatype nor anyway to ask
the implementation to allocate the string for you.
I'd prefer the C version to allocate the string for the user; failing
that, I'd like it to be an error which is guaranteed non-fatal
. In the proposal a datatype used locally is defined only after its last
use; I would prefer it to be defined immediately after its first use.
. I don't see the need for temporal uniqueness of the sequence numbers
-- and without it, we can get rid of the 'T' vs 'U' business. I would
prefer that sequence numbers be unique *within* the string (i.e., if a
sequence number is repeated within a string, it represents the same
datatype), but with no guarantee of uniqueness between strings.
Question: Is it being proposed that the sequence numbers for the 'T'
types be temporally unique? I hope not -- I, in fact, would have a big
problem with any uniqueness for 'T' types that extended beyond the end
of the string encoding.
. I never had a MPI_Get_type_seq_num function in my proposal. Perhaps
this was in someone else's proposal?
Using my grammar, which I'll present in a moment, here's how the
examples given in the current proposal would look:
U329(HV:U3291(HV:U3292(V:R:9:1:2):9:1:400):9:1:40000)
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)
Because I define the datatype immediately after its first use, I can do
a simple left to right scan of the datatype and do not need to go back
and do fix ups or the like. Nor do I need the baseTypeRep, typeRep, or
createTypeRep rules.
Here's the grammar that I implemented:
%start start
%%
posDigit : '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ;
digit : '0' | posDigit;
nonNegInt : digit
| nonNegInt digit
;
Int : '-' nonNegInt
| nonNegInt
;
posInt : posDigit
| posInt digit
;
typeDescC : 'b'
| 'p'
| 'c'
| 'u' 'c'
| 's'
| 'u' 's'
| 'i'
| 'u' 'i'
| 'l'
| 'u' 'l'
| 'l' 'l'
/*
| 'u' 'l' 'l'
*/
| 'f'
| 'd'
| 'l' 'd'
;
typeDescF77 : 'I'
| 'R'
| 'D'
| 'C'
| 'D' 'C'
| 'L'
/*
| 'C' 'h' 'a' 'r'
*/
;
typeDescUser : 'U' nonNegInt
| 'U' nonNegInt '(' typeDesc ')'
;
typeDescBasic : typeDescC
| typeDescF77
| typeDescUser
;
typeDescAdv : 'U' 'B'
| 'L' 'B'
| typeDescBasic
;
typeDescVec : 'V' ':' typeDescBasic ':' posInt ':' posInt ':' Int
;
typeDescHVec : 'H' 'V' ':' typeDescBasic ':' posInt ':' posInt ':' Int
;
typeDescIndex : 'X' ':' typeDescBasic ':' posInt ':' posInt '/' Int
| typeDescIndex ',' posInt '/' Int
;
typeDescHIndex : 'H' 'X' ':' 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
;
%%