llvm/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp2.txt

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