>>1
Make a front-end that compiles to C or use LLVM, it would probably be the least effort.
>>16
C is C for a reason, it's a low level language and a programmer can easily envision the code that will be (native) generated by the compiler to some degree. Continuations, lambda's (and closures) do complicate the simplicity of a low/mid level language.
If you want them, why not use Haskell, Lisp or Scheme?
Short list and my idea of how hard it would be to implement them:
- Type inferrence cannot be emulated easily, it needs to be build early on in the compiler front-end.
- Lambda's, probably not too hard, it's just a function pointer and an associated environment(when closures are involved). C coders can emulate this to some extent, but it's a lot nastier than it would be if you had native support for it.
- First class functions: you can already pass pointers to functional code, but that doesn't save state/environment, so you'd have to pass the state/environment in some way.
- Continuations: the cost of implementing true continuations in Scheme is great. You need a spaghetti stack for this, or you need to do a lot of stack copying, which is very costly. A C programmer can emulate them by using implementation dependent OS routines and assembly-written routines, however the (memory/time) costs are great and that makes them less practical for common use.
- (Added my own), a true condition system like Common Lisp's: *Nix and Windows both offer more rudimentary ways to implement this, such as signals(*Nix) and SEH(Structured Exception Handling - Windows), both of these rudimentary mechanisms offer enough power to be able to build a real condition system on top of them(An example: in CL, you can signal a condition(think of it as an exception), and define local(or not local) ways to handle the condition, you can decide how and when you want to unwind the stack(if at all), and you can define handling strategies in upper levels, and once the handling is decided, the code can continue running off where it left, with the error fixed. This is better than the C++ exception based system, as you can decide exactly when and how to handle, and don't have to unwind the stack unless you need to.). The only problem with signals and SEH is that most programmers don't always exploit their true strength in such ways, simply because they may not realize it.
- Lexical Scoping: C already has static scoping, but not as powerful as what Lisp and Scheme offer. Lisp has both dynamic and static scoping, while Scheme only has static scoping. Static scoping leads to clean and clear code, and dynamic scoping allows simplifying some code and solving certain important practical problems, I usually try to avoid having many, if at all, global variables in C, but Lisp's "global variables" are much more clean and powerful (and can be safe too, if the usage is right), which convienced me that there are ways to do "global variables" right.
I'd like to be able to use some of these things in C, but at the same time I believe C is C for a reason, and complicating it in such ways would make it no longer be C, but a different language, in which case, why not just go to D or make your own language?