Ah, nice to know you're alive out there! We got both "you're stupid" and "well, how about this too..." responses, which is good.
Badger says: By saying pointers are a design flaw of the language, you just killed the whole language C. How are you gonna be able to fiddle low-level without pointers? Set them once you say. I say you're not real.
Well you've convinced me! ;] No, seriously, I don't want to do away with pointers altogether, I just want them to point unambigously. Remember, I said that you can still tinker with what is pointed to by a pointer. You just can't re-point it once set. Someone said that this will make pointers little better than non-dynamic variables. I agree with this criticism somewhat. It's unfortunate that functionality has to be taken away, but I feel that the overly flexible nature of pointers in stock C has been a loaded hand-gun in the palm of a 4 year old. That said, I think you have some valid criticisms here. And I'm not a language bigot, really. (t's more like, I hate them all in different ways and love them all in different ways as well. I love Perl to death, even if I can never read anyone else's.) Oh, and I concur that practically nothing is ever perfect.
As for using C in embedded systems, yes, C is definitely useful there for obvious reasons, and I know it. One of my hobbies at the moment is futzing around with microcontrollers. I've taught myself PIC assembley, written bit-bang serial for the 12C508 (I was quite amazed when it worked), and I'm currently tinkering with AVR 90S2313's. Great little chips, those. But you know what? I write all my code there in assembley. I think C is inappropriate when you're that low-level. As I said, anyone doing realtime criticial systems shouldn't be using my little toy proposed language here anyway. When I included garbage collection as a feature the ability to perform as quickly as necessary and get into as small a space as necessary for real-time systems went out the window.
The namespace idea that graydon came up with is particularly insightful, IMO. I was just thinking about that last night as I was falling asleep. I think I like the C idea of having everything in a file be part of one namespace. In other words, each file is a module. The twist I'd like to put on that is that if you wish the code in a file to be accessable from other modules, you have to give it a name. Then things in that module are referred to by a "moduleName.funcNam" syntax. This is more or less blatantly stolen from Java. (Which, despite all its flaws, did get a few things right.)
Data types are another interesting dilemma. I was considering what data types would be good for a simple, minimal language. I came up with three: Integers, Floating point numbers and Strings. I think these three are the crucial ones - maybe add a "large" modifier to the integer and float types that will double their storage capacity. These days I think we can handle having a default integer type that's four bytes long. This is a nice range. If your loop has to execute more than 4 billion times, you should probably consider a better algorithm... or a code redesign. If you _really_ need large numbers, then a "large integer" would be . Hopefully having default numeric quantities this large would obviate the need for the "unsigned" type modifier. A normal float would be the IEEE 64-bit floating point standard, and a large float would be the IEEE 128-bit standard. (I think the 128-bit one has been standardized by now?) Additional types might be bytes or bits for low-level work, and fixed-point numbers for those who crave speed over accuracy.
mobius's point about the standard keyboard being terribly laid out is one I heartily agree with. Unfortunatly I'm too cynical to think it'll ever change. (Be thrown away when voice recog comes in, maybe. But changed? No way. Too entrenched.)
Lastly, I also wanted to say that jbuck had a really good point that these days, a language should be made for the primary purpose of being easy to read and maintain, not necessarily to write, and definitely not to be easy to compile. Cycles are cheap, brains are expensive.
Lastly, let me emphasize that I'm thinking about a simplified variant of C for fun. I'm not trying to dethrone any existing language here. I'm trying to make something I can practice writing a compiler for. This is something I'm doing in my off time because I never did take a compiler construction class in college, and I wanted to. And I figure, while I'm doing it, heck, might as well toss in a few experimental ideas.
Thanks for the feedback and ideas so far. It's been very eye-opening. More! More! <G>