You seem to use whatever version of C suits you argument. K&R C and standard Cs do not have integration of machine code. Therefore languages like GNU C must implement them as a hack extention. This is not what I call clean integration. colorForth allows machine language integration by design. This is the whole purpose of the colorForth macros.
On compactness, fine let us choose a implementation then compare. I choose colorForth, I await you choice of C implementation.
On interactive development, I didn't state that colorForth has a debugger. Interactivety is achieved through a extremely tight edit/compile/test cycle, and entry points to every word.
Where did I seperate a computer language from it's implmentation? Look at ObjectiveCaml for a typeded infix language which is much cleaner than C, and even beats C on occasion in performace.
Please show me the abuguity in the colorForth specification. Are you comparing this to C? Many paragraphs of the C specification say the handling of a certain construct is implementation defined, how much more ambiguous can you get?
I have some advice for you tk, try implementing a parser for the C language. You said this was "quite tractable", lets see it. I think if you did this, you might actually understand how bogus the design of the C language is. You might also understand my abhorrence for it.
For me, I try to avoid design disasters where I can. I try to avoid projects which have such a great inertia. I like software that is small, fast, and nimble; changable. Software should be built to last, but not built to stay. Free software has many examples of software built to stay. Mozilla, gcc, Linux, Gnome, KDE, are all built to stay, if they last it is not because of design elegance but because they are unmovable.
My quote of the Tao:
In pursuit of knowledge,
every day something is added.
In the practice of the Tao,
every day something is dropped.
Less and less do you need to force things,
until finally you arrive at non-action.
When nothing is done,
nothing is left undone.