> 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."

Although you have to remember that his situation was considerably
different than ours.  He was in a position where he was designing a high
level language that had to be COMPATIBLE with C.  Our language is such
that a new person would have to learn the new, different, syntax
anyways.  Making them learn about the type system does not seem like much
of a stretch from learning the opcodes and how SSA form works, and how
everything ties together...

> > 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.

I would argue that because the lexical structure of the language is self
consistent, any person who spent a significant amount of time programming
in LLVM directly would understand how to do it without looking it up in a
manual.  The reason this does not work for C is because you rarely have to
declare these pointers, and the syntax is inconsistent with the method
declaration and calling syntax.

> But pointers to member functions are nowhere near as common as arrays.

Very true.  If you're implementing an object oriented language, however,
remember that you have to do all the pointer to member function stuff
yourself.... so every time you invoke a virtual method one is involved
(instead of having C++ hide it for you behind "syntactic sugar").

> 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.  

Erm... excuse me but how is this the "old array syntax"?  If you are
arguing for consistency with C, you should be asking for 'type int []',
which is significantly different than the above (beside the above
introduces a new operator and duplicates information
needlessly).  Basically what I am suggesting is exactly the above without
the fluff.  So instead of:

       type [ int, int, ...]

you use:

       type [ int ]

> Introducing a new syntax that may
> make function pointers easier but makes arrays much more difficult seems
> very risky to me.

This is not about function pointers.  This is about consistency in the
type system, and consistency with the rest of the language.  The point
above does not make arrays any more difficult to use, and makes the
structure of types much more obvious than the "c way".

> > 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.

Very true, but you seem to be advocating a completely different Type
system than C has, in addition to it not offering the advantages of clear
structure that the system I recommended does... so you seem to not have a
problem with changing this, just with what I change it to.  :)

-Chris