mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-09-14 04:57:33 +00:00
009505452b
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@2 91177308-0d34-0410-b5e6-96231b3b80d8
76 lines
3.1 KiB
Plaintext
76 lines
3.1 KiB
Plaintext
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
|
|
|