third_party/llvm-project/llvm/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp1.txt - cobalt - Git at Google

 Date: Thu, 8 Feb 2001 08:42:04 -0600
 From: Vikram S. Adve <vadve@cs.uiuc.edu>
 To: Chris Lattner <sabre@nondot.org>
 Subject: RE: Type notation debate...

 Chris,

 > Okay before you comment, please look at:
 >
 > http://www.research.att.com/~bs/devXinterview.html

 I read this argument.  Even before that, I was already in agreement with you
 and him that the C declarator syntax is difficult and confusing.

 But in fact, if you read the entire answer carefully, he came to the same
 conclusion I do: that you have to go with familiar syntax over logical
 syntax because familiarity is such a strong force:

         "However, familiarity is a strong force. To compare, in English, we
 live
 more or less happily with the absurd rules for "to be" (am, are, is, been,
 was, were, ...) and all attempts to simplify are treated with contempt or
 (preferably) humor. It be a curious world and it always beed."

 > Basically, my argument for this type construction system is that it is
 > VERY simple to use and understand (although it IS different than C, it is
 > very simple and straightforward, which C is NOT).  In fact, I would assert
 > that most programmers TODAY do not understand pointers to member
 > functions, and have to look up an example when they have to write them.

 Again, I don't disagree with this at all.  But to some extent this
 particular problem is inherently difficult.  Your syntax for the above
 example may be easier for you to read because this is the way you have been
 thinking about it.  Honestly, I don't find it much easier than the C syntax.
 In either case, I would have to look up an example to write pointers to
 member functions.

 But pointers to member functions are nowhere near as common as arrays.  And
 the old array syntax:
         type [ int, int, ...]
 is just much more familiar and clear to people than anything new you
 introduce, no matter how logical it is.  Introducing a new syntax that may
 make function pointers easier but makes arrays much more difficult seems
 very risky to me.

 > In my opinion, it is critically important to have clear and concise type
 > specifications, because types are going to be all over the programs.

 I absolutely agree.  But the question is, what is more clear and concise?
 The syntax programmers are used to out of years of experience or a new
 syntax that they have never seen that has a more logical structure.  I think
 the answer is the former.  Sometimes, you have to give up a better idea
 because you can't overcome sociological barriers to it.  Qwerty keyboards
 and Windows are two classic examples of bad technology that are difficult to
 root out.

 P.S.  Also, while I agree that most your syntax is more logical, there is
 one part that isn't:

 Arrays (without and with size):
 type ::= '[' type ']' | '[' INT ',' type ']'.

 The arrays with size lists the dimensions and the type in a single list.
 That is just too confusing:
         [10, 40, int]
 This seems to be a 3-D array where the third dimension is something strange.
 It is too confusing to have a list of 3 things, some of which are dimensions
 and one is a type.  Either of the following would be better:

         array [10, 40] of int
 or
         int [10, 40]

 --Vikram
	Date: Thu, 8 Feb 2001 08:42:04 -0600
	From: Vikram S. Adve <vadve@cs.uiuc.edu>
	To: Chris Lattner <sabre@nondot.org>
	Subject: RE: Type notation debate...

	Chris,

	> Okay before you comment, please look at:
	>
	> http://www.research.att.com/~bs/devXinterview.html

	I read this argument. Even before that, I was already in agreement with you
	and him that the C declarator syntax is difficult and confusing.

	But in fact, if you read the entire answer carefully, he came to the same
	conclusion I do: that you have to go with familiar syntax over logical
	syntax because familiarity is such a strong force:

	"However, familiarity is a strong force. To compare, in English, we
	live
	more or less happily with the absurd rules for "to be" (am, are, is, been,
	was, were, ...) and all attempts to simplify are treated with contempt or
	(preferably) humor. It be a curious world and it always beed."

	> Basically, my argument for this type construction system is that it is
	> VERY simple to use and understand (although it IS different than C, it is
	> very simple and straightforward, which C is NOT). In fact, I would assert
	> that most programmers TODAY do not understand pointers to member
	> functions, and have to look up an example when they have to write them.

	Again, I don't disagree with this at all. But to some extent this
	particular problem is inherently difficult. Your syntax for the above
	example may be easier for you to read because this is the way you have been
	thinking about it. Honestly, I don't find it much easier than the C syntax.
	In either case, I would have to look up an example to write pointers to
	member functions.

	But pointers to member functions are nowhere near as common as arrays. And
	the old array syntax:
	type [ int, int, ...]
	is just much more familiar and clear to people than anything new you
	introduce, no matter how logical it is. Introducing a new syntax that may
	make function pointers easier but makes arrays much more difficult seems
	very risky to me.

	> In my opinion, it is critically important to have clear and concise type
	> specifications, because types are going to be all over the programs.

	I absolutely agree. But the question is, what is more clear and concise?
	The syntax programmers are used to out of years of experience or a new
	syntax that they have never seen that has a more logical structure. I think
	the answer is the former. Sometimes, you have to give up a better idea
	because you can't overcome sociological barriers to it. Qwerty keyboards
	and Windows are two classic examples of bad technology that are difficult to
	root out.

	P.S. Also, while I agree that most your syntax is more logical, there is
	one part that isn't:

	Arrays (without and with size):
	type ::= '[' type ']' \| '[' INT ',' type ']'.

	The arrays with size lists the dimensions and the type in a single list.
	That is just too confusing:
	[10, 40, int]
	This seems to be a 3-D array where the third dimension is something strange.
	It is too confusing to have a list of 3 things, some of which are dimensions
	and one is a type. Either of the following would be better:

	array [10, 40] of int
	or
	int [10, 40]

	--Vikram