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