Probably because this newsgroup isn't really about "fixing the
language".
agreed.
I personally see little problem with the syntax in-general, except in a
few cases.
If you wanted to add a new declaration syntax to C, it would have to
*completely* coexist with the existing syntax. Breaking existing code
is not an option. (Yes, each new C standard has broken *some* existing
code, at least theoretically, but breaking every declaration more
complex than "int i;" would not be acceptable.)
And while I agree that a better syntax for a hypothetical new language
(the "C's replacement" we're discussing in this thread) would be great,
I'm not sure that a C-like language supporting both the existing syntax
and a new syntax would be better than one that just supports the
existing syntax.
my own language (BGBScript) has an issue similar to this.
given its ECMAScript heritage, it has ECMAScript-style declarations.
given other reasons (mostly related to inter-language copy/paste), it
also has a more Java/C# style declaration syntax.
it is kind of annoying, as there is an issue as to which syntax is more
canonical.
I am mostly leaning more towards the ES-style being more canonical, more
because the language is technically an ES variant (it is largely
ECMA-262 conformant), and so it makes more sense if the language uses as
its canonical syntax, the one defined in the standard on which it is based.
example:
var x;
var i:int;
var a:int[];
var pv:*void;
vs:
variant x; //(1)
int i;
int[] a;
*void pv; //(2)
1: this syntax is longer and not strictly equivalent to "var x;",
however "var x;" is technically the other syntax given that var is a
declaration keyword. "variant x" is technically equivalent to "var
x:variant;". there is currently little functional difference though.
note that, given how the declaration parser works, it is also
technically possible to create double-typed variables, as in:
"int x:long, y:double;"
however, these currently have little practical use, and should be
considered an error (as-is, the later types will override the base type).
function declaration syntax is also partly redundant:
function foo(x:int):void { ... }
vs:
void foo(int x) { ... }
as-is, closures can only be declared with an ES-like form (sort of),
given that there are syntax problems otherwise.
function(x) { ... }
function(i:int):void { ... }
however:
function(int i) { ... }
function(int i):void { ... }
will probably work...
things like getters/setters, ... also have redundant syntax.
function get x():int { ... }
vs:
int get x() { ... }
....
2: "*type" was used instead of "type*" in my language due to there being
several cases in which the later would be syntactically ambiguous.
although declaring pointers this way may look strange, as-is it is a
fairly trivial change, and doesn't particularly hinder converting C code
to BGBScript, or at least not nearly as much as the differences in the
cast syntax.
a recent set of (fairly fundamental) changes in my interpreter has made
many of these types more canonical, as now declaring a variable as "int"
will actually store the variable as a 32-bit integer internally, rather
than, say, as a fixnum.
these changes have introduced a lot of bugs, so it is still an ongoing
transition.
I was also recently thinking and considering if my interpreter would be
fast enough to allow porting Quake to my Script VM. if some recent
benchmarks are representative, my interpreter is performing comparably
to the sorts of hardware Quake 1 and 2 were developed for, and so should
be sufficiently fast to run these games (even without a JIT).
granted, I would likely need a C front-end for this VM (sadly, doesn't
currently exist, 3), as it would probably be too much effort to port the
entire Quake 1 or Quake 2 engine to BGBScript.
not sure yet if I will actually attempt a thing, since as-is, this would
still be a fairly big project given the present state of the VM.
3: my existing C compiler targeted a different back-end, which is no
longer in operation. I would either need to modify this front-end to
target the current Script VM, or very possibly create a new C front-end,
or possibly a combination (keeping the existing parser, but write a new
AST->bytecode stage).
But something that might be interesting, not as a language change but as
a development tool, would be integrating something like cdecl into the
build process. You could write code in a C-like dialect, with
declarations written in your new syntax, and your build tool would
automatically generate syntactically correct C. Another tool could
translate C declarations into your syntax. It would let you use your
preferred syntax while still being able to share C code with others who
don't have your tools.
it is possible...
I presume you mean requiring plain "char" to be unsigned (we already
have "unsigned char"). I tend to agree; permitting plain char to be
signed causes a lot of conceptual problems. I wonder what kind of
performance problems it might introduce, though; char expressions are
frequently promoted to int, and that promotion might be more expensive
on some systems if plain char is signed. (I presume that's why so many
compilers make plain char signed, when making it unsigned would be
perfectly legal.)
in my language, I split them up, so these types are more like:
byte: 8-bit unsigned byte;
sbyte: 8-bit signed byte;
short: 16-bit signed short;
ushort: 16-bit unsigned short;
char8: 8-bit unsigned char;
char/char16: 16-bit unsigned char.
char is not strictly equivalent to ushort, as they will have slightly
different semantics.
