On 11/14/2015 12:06 AM, Ola Fosheim Grøstad wrote:
I'm not sure if it reasonable to set aside the preprocessor,
If your new language doesn't have the C preprocessor in it, then you must set it aside. If it does have a C preprocessor in it, then it really isn't a new language at all, it's just a C permutation.
but it depends on what you mean by interop: 1. portability - A language like Nim obviously has a better portability future since that is the one of the primary goal of having portable C source code.
That's all very fine until the that C compiler evaluates expressions in a different way than the one you debugged it with, and your language fails on your customer's machine with your customer's C compiler, and fails in weird ways.
You can't just dismiss the points I made and say "It's C, so it's portable." It isn't. If you're anxious to learn the hard way, feel free :-) It's one thing to read the C standard and pontificate about it, it's quite another to actually be in the trenches and deal with it.
BTW, although C compilers exist for all kinds of weird machines, the weirder the machine is, the worse (i.e. more limited and buggier) the C compiler is for it (as a general rule).
Good luck porting your language to a C compiler that has 10 bit bytes in it, or one with 32 bit bytes. Yes, those compilers exist. Yes, those are C standard conforming variations. Nope, none of your "portable" C code will work on it.
Compile time does not have to be a big issue,
It always is once your project exceeds trivial size. Remember, my experience is a factor of 4x slower. And you cannot fix it.
