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