1*06f32e7eSjoergDate: Thu, 8 Feb 2001 14:31:05 -0600 (CST) 2*06f32e7eSjoergFrom: Chris Lattner <sabre@nondot.org> 3*06f32e7eSjoergTo: Vikram S. Adve <vadve@cs.uiuc.edu> 4*06f32e7eSjoergSubject: RE: Type notation debate... 5*06f32e7eSjoerg 6*06f32e7eSjoerg> Arrays (without and with size): 7*06f32e7eSjoerg> type ::= '[' type ']' | '[' INT ',' type ']'. 8*06f32e7eSjoerg> 9*06f32e7eSjoerg> The arrays with size lists the dimensions and the type in a single list. 10*06f32e7eSjoerg> That is just too confusing: 11*06f32e7eSjoerg 12*06f32e7eSjoerg> [10, 40, int] 13*06f32e7eSjoerg> This seems to be a 3-D array where the third dimension is something strange. 14*06f32e7eSjoerg> It is too confusing to have a list of 3 things, some of which are dimensions 15*06f32e7eSjoerg> and one is a type. 16*06f32e7eSjoerg 17*06f32e7eSjoergThe above grammar indicates that there is only one integer parameter, ie 18*06f32e7eSjoergthe upper bound. The lower bound is always implied to be zero, for 19*06f32e7eSjoergseveral reasons: 20*06f32e7eSjoerg 21*06f32e7eSjoerg* As a low level VM, we want to expose addressing computations 22*06f32e7eSjoerg explicitly. Since the lower bound must always be known in a high level 23*06f32e7eSjoerg language statically, the language front end can do the translation 24*06f32e7eSjoerg automatically. 25*06f32e7eSjoerg* This fits more closely with what Java needs, ie what we need in the 26*06f32e7eSjoerg short term. Java arrays are always zero based. 27*06f32e7eSjoerg 28*06f32e7eSjoergIf a two element list is too confusing, I would recommend an alternate 29*06f32e7eSjoergsyntax of: 30*06f32e7eSjoerg 31*06f32e7eSjoergtype ::= '[' type ']' | '[' INT 'x' type ']'. 32*06f32e7eSjoerg 33*06f32e7eSjoergFor example: 34*06f32e7eSjoerg [12 x int] 35*06f32e7eSjoerg [12x int] 36*06f32e7eSjoerg [ 12 x [ 4x int ]] 37*06f32e7eSjoerg 38*06f32e7eSjoergWhich is syntactically nicer, and more explicit. 39*06f32e7eSjoerg 40*06f32e7eSjoerg> Either of the following would be better: 41*06f32e7eSjoerg> array [10, 40] of int 42*06f32e7eSjoerg 43*06f32e7eSjoergI considered this approach for arrays in general (ie array of int/ array 44*06f32e7eSjoergof 12 int), but found that it made declarations WAY too long. Remember 45*06f32e7eSjoergthat because of the nature of llvm, you get a lot of types strewn all over 46*06f32e7eSjoergthe program, and using the 'typedef' like facility is not a wonderful 47*06f32e7eSjoergoption, because then types aren't explicit anymore. 48*06f32e7eSjoerg 49*06f32e7eSjoergI find this email interesting, because you contradict the previous email 50*06f32e7eSjoergyou sent, where you recommend that we stick to C syntax.... 51*06f32e7eSjoerg 52*06f32e7eSjoerg-Chris 53*06f32e7eSjoerg 54