]>
Commit | Line | Data |
---|---|---|
223e47cc LB |
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 |