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

   1 Date: Thu, 8 Feb 2001 08:42:04 -0600
   2 From: Vikram S. Adve <vadve@cs.uiuc.edu>
   3 To: Chris Lattner <sabre@nondot.org>
   4 Subject: RE: Type notation debate...
   5
   6 Chris,
   7
   8 > Okay before you comment, please look at:
   9 >
  10 > http://www.research.att.com/~bs/devXinterview.html
  11
  12 I read this argument.  Even before that, I was already in agreement with you
  13 and him that the C declarator syntax is difficult and confusing.
  14
  15 But in fact, if you read the entire answer carefully, he came to the same
  16 conclusion I do: that you have to go with familiar syntax over logical
  17 syntax because familiarity is such a strong force:
  18
  19         "However, familiarity is a strong force. To compare, in English, we
  20 live
  21 more or less happily with the absurd rules for "to be" (am, are, is, been,
  22 was, were, ...) and all attempts to simplify are treated with contempt or
  23 (preferably) humor. It be a curious world and it always beed."
  24
  25 > Basically, my argument for this type construction system is that it is
  26 > VERY simple to use and understand (although it IS different than C, it is
  27 > very simple and straightforward, which C is NOT).  In fact, I would assert
  28 > that most programmers TODAY do not understand pointers to member
  29 > functions, and have to look up an example when they have to write them.
  30
  31 Again, I don't disagree with this at all.  But to some extent this
  32 particular problem is inherently difficult.  Your syntax for the above
  33 example may be easier for you to read because this is the way you have been
  34 thinking about it.  Honestly, I don't find it much easier than the C syntax.
  35 In either case, I would have to look up an example to write pointers to
  36 member functions.
  37
  38 But pointers to member functions are nowhere near as common as arrays.  And
  39 the old array syntax:
  40         type [ int, int, ...]
  41 is just much more familiar and clear to people than anything new you
  42 introduce, no matter how logical it is.  Introducing a new syntax that may
  43 make function pointers easier but makes arrays much more difficult seems
  44 very risky to me.
  45
  46 > In my opinion, it is critically important to have clear and concise type
  47 > specifications, because types are going to be all over the programs.
  48
  49 I absolutely agree.  But the question is, what is more clear and concise?
  50 The syntax programmers are used to out of years of experience or a new
  51 syntax that they have never seen that has a more logical structure.  I think
  52 the answer is the former.  Sometimes, you have to give up a better idea
  53 because you can't overcome sociological barriers to it.  Qwerty keyboards
  54 and Windows are two classic examples of bad technology that are difficult to
  55 root out.
  56
  57 P.S.  Also, while I agree that most your syntax is more logical, there is
  58 one part that isn't:
  59
  60 Arrays (without and with size):
  61 type ::= '[' type ']' | '[' INT ',' type ']'.
  62
  63 The arrays with size lists the dimensions and the type in a single list.
  64 That is just too confusing:
  65         [10, 40, int]
  66 This seems to be a 3-D array where the third dimension is something strange.
  67 It is too confusing to have a list of 3 things, some of which are dimensions
  68 and one is a type.  Either of the following would be better:
  69
  70         array [10, 40] of int
  71 or
  72         int [10, 40]
  73
  74 --Vikram
  75