[MUD-Dev] Languages
Chris Gray
cg at ami-cg.GraySage.Edmonton.AB.CA
Thu May 15 22:17:41 CEST 1997
[Dan R:]
:Actually, if you don't get into C++ (which is indeed evil and overly
:complex) and don't consider the preprocessor (which is entirely
:outside the realm of the language), the syntax is quite small, and
:actually quite clean. The only problem is that as an expression-based
:(as opposed to statement based, stack based, or message based) one
:does have to worry about precedence in operators, which can be
:eliminated by judicious use of parenthesis and whitespace.
I was trying to avoid muttering on about why I don't like C, but I'm
getting tickled the wrong way, so you folks have to either skip or
put up with the resulting output. :-)
Things wrong with C: (mostly syntax)
- the dereference operator should be postfix. That way you don't
need the extra parens in messy cases, and you can do away with
'->' altogether, and just use "*." .
- array bounds should have been part of the type stuff, not tacked
on to the identifier being declared:
[20] char a, b, c; not char a[20], b[20], c[20];
C can't really be blamed for this - many of its predecessors
did it too. The notion of 'type' was still a bit hazy back then.
- declarations should not look like expressions (this was a neat
thing to try, but it didn't work out as well as hoped, I'd say).
Instead, the order of things in a declaration should be the
reverse of that in an expression:
*[20]char p; not char (*p)[20];
... ...
p*[i] := 'a'; not (*p)[i] = 'a';
Thus, the type in the declaration can be read as "pointer to
array of 20 pointers to char". Just read left-to-right. (I
started with another level of pointer in example, but the
C just got too icky!) (My parens above may not be needed - I
can never keep it straight!)
- prototypes should have used the same syntax as declarations. This
minor wart likely came about from trying to mix K&R decls with
ANSI decls:
f(int a, b; char c) not f(int a, int b, char c)
- use '=' for comparison, and something else, e.g. ':=' for
assignment. People from many non-C-programming areas (math,
logic, other languages) do not automatically see
if (a = 6)
as an error, leading to frustration with the language. New
compilers are finally helping with this.
- get rid of the goofy extra parens, and make each construct have
its own block keywords. (second half of problem inherited from
many languages, e.g. Pascal, Algol; first half invented by C):
if a = 6 and b < 7 then
do;
stuff;
else
other;
stuff;
fi; /* or 'endif' or ... */
not
if (a == 6 && b < 7) {
do;
stuff;
} else {
other;
stuff;
}
Doing this allows for *much* better error recovery on the part
of compilers. Everything being so much the same in C, coupled
with its "expression language" nature, leads to far too many
situations where an extra or missing punctuation mark leads to
a total collapse of the compiler's parse.
- the default in a switch should *never* have been to fall-through
to the next case. You should have to explicitly ask for that.
Lord knows how many bugs that has caused.
There. I did warn you! There are likely more, but those are off the top
of my head.
--
Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
More information about the mud-dev-archive
mailing list