1> But in fact, if you read the entire answer carefully, he came to the same 2> conclusion I do: that you have to go with familiar syntax over logical 3> syntax because familiarity is such a strong force: 4> "However, familiarity is a strong force. To compare, in English, we 5live 6> more or less happily with the absurd rules for "to be" (am, are, is, been, 7> was, were, ...) and all attempts to simplify are treated with contempt or 8> (preferably) humor. It be a curious world and it always beed." 9 10Although you have to remember that his situation was considerably 11different than ours. He was in a position where he was designing a high 12level language that had to be COMPATIBLE with C. Our language is such 13that a new person would have to learn the new, different, syntax 14anyways. Making them learn about the type system does not seem like much 15of a stretch from learning the opcodes and how SSA form works, and how 16everything ties together... 17 18> > Basically, my argument for this type construction system is that it is 19> > VERY simple to use and understand (although it IS different than C, it is 20> > very simple and straightforward, which C is NOT). In fact, I would assert 21> > that most programmers TODAY do not understand pointers to member 22> > functions, and have to look up an example when they have to write them. 23 24> Again, I don't disagree with this at all. But to some extent this 25> particular problem is inherently difficult. Your syntax for the above 26> example may be easier for you to read because this is the way you have been 27> thinking about it. Honestly, I don't find it much easier than the C syntax. 28> In either case, I would have to look up an example to write pointers to 29> member functions. 30 31I would argue that because the lexical structure of the language is self 32consistent, any person who spent a significant amount of time programming 33in LLVM directly would understand how to do it without looking it up in a 34manual. The reason this does not work for C is because you rarely have to 35declare these pointers, and the syntax is inconsistent with the method 36declaration and calling syntax. 37 38> But pointers to member functions are nowhere near as common as arrays. 39 40Very true. If you're implementing an object oriented language, however, 41remember that you have to do all the pointer to member function stuff 42yourself.... so every time you invoke a virtual method one is involved 43(instead of having C++ hide it for you behind "syntactic sugar"). 44 45> And the old array syntax: 46> type [ int, int, ...] 47> is just much more familiar and clear to people than anything new you 48> introduce, no matter how logical it is. 49 50Erm... excuse me but how is this the "old array syntax"? If you are 51arguing for consistency with C, you should be asking for 'type int []', 52which is significantly different than the above (beside the above 53introduces a new operator and duplicates information 54needlessly). Basically what I am suggesting is exactly the above without 55the fluff. So instead of: 56 57 type [ int, int, ...] 58 59you use: 60 61 type [ int ] 62 63> Introducing a new syntax that may 64> make function pointers easier but makes arrays much more difficult seems 65> very risky to me. 66 67This is not about function pointers. This is about consistency in the 68type system, and consistency with the rest of the language. The point 69above does not make arrays any more difficult to use, and makes the 70structure of types much more obvious than the "c way". 71 72> > In my opinion, it is critically important to have clear and concise type 73> > specifications, because types are going to be all over the programs. 74> 75> I absolutely agree. But the question is, what is more clear and concise? 76> The syntax programmers are used to out of years of experience or a new 77> syntax that they have never seen that has a more logical structure. I think 78> the answer is the former. Sometimes, you have to give up a better idea 79> because you can't overcome sociological barriers to it. Qwerty keyboards 80> and Windows are two classic examples of bad technology that are difficult to 81> root out. 82 83Very true, but you seem to be advocating a completely different Type 84system than C has, in addition to it not offering the advantages of clear 85structure that the system I recommended does... so you seem to not have a 86problem with changing this, just with what I change it to. :) 87 88-Chris 89 90