While I react negatively to the oft-required use of C/C++, I can't help but notice that your claims against C are largely in error.
Every operator in C can be thought of as a lambda expression of finite arity. Indeed, the output of a C compiler's parser is an abstract syntax tree -- expressed usually as a list of lists, just like Lisp code. Well-factored C code is largely identical in semantics to similarly factored Lisp code. OK, the syntax sucks, and you have to type more, but the same information is present in both systems.
Moreover, I do have some experience with commercial Forth compilers which produces very optimized code, comparable to C, even though C is significantly "higher level" than Forth is, at least out of the box. Don't knock data-flow analysis, continuation-passing style, and static single-assignment intermediate representations. With these, you can also perform dead-code elimination, just like Haskell does. In fact, with CPS, you can even perform return optimizations (e.g., if you notice that a function return value is used immediately by a switch/case-like construct, then you can just compile the function so that it jumps directly into the relevant cases -- this is an optimization which Haskell performs, but is in no way limited to just Haskell, nor is it dependent on Haskell's purity).
I believe the GHC Haskell compiler provides a framework that lets you define and manage your own optimizations. I've never used it myself, so I don't know the full details, but I have seen other programs which defined "hints" to the compiler that, basically, allows you to say, "Whenever you see X, it is equivalent to Y". Then there is template Haskell, which if I recall correctly, extends this concept even further, including support for macros (which is a crude form of what you're looking for anyway).
But, I shy away from all these automatic systems, because there is no one-to-one correspondence with what I write, and what the computer executes. I've been burned by this more times than I can remember. No, I prefer instead to write simple code, with a simple compiler, producing simple binaries. I don't care how long they run, at least at first. If, and only if, performance becomes an issue, then I'll look at profiling and optimizations. (You do profile first, right?)
Finally, what you're describing cannot solve the largest problem of all -- the recognition that you're writing a simple linked list implementation when you meant a B-tree. But, then again, what kind of B-tree? Would a skip-list be sufficient? You want real 2-3-4 trees, or are you happy with an AVL-tree implementation?
I vote no to automatic anything. The computer is stupid, able to recognize, and optimize based on, only the most basic of arithmetic truths. There are a number of them, for sure; but, what you're calling for above makes no economic sense. Why write one implementation of something, when you write rules on how to replace said something with something else. You might as well just delete and re-write the relevant code into "something else" from the start. You'll save time, money, energy, frustration, nerves, and electricity.
Unnecessarily harsh
While I react negatively to the oft-required use of C/C++, I can't help but notice that your claims against C are largely in error.
Every operator in C can be thought of as a lambda expression of finite arity. Indeed, the output of a C compiler's parser is an abstract syntax tree -- expressed usually as a list of lists, just like Lisp code. Well-factored C code is largely identical in semantics to similarly factored Lisp code. OK, the syntax sucks, and you have to type more, but the same information is present in both systems.
Moreover, I do have some experience with commercial Forth compilers which produces very optimized code, comparable to C, even though C is significantly "higher level" than Forth is, at least out of the box. Don't knock data-flow analysis, continuation-passing style, and static single-assignment intermediate representations. With these, you can also perform dead-code elimination, just like Haskell does. In fact, with CPS, you can even perform return optimizations (e.g., if you notice that a function return value is used immediately by a switch/case-like construct, then you can just compile the function so that it jumps directly into the relevant cases -- this is an optimization which Haskell performs, but is in no way limited to just Haskell, nor is it dependent on Haskell's purity).
I believe the GHC Haskell compiler provides a framework that lets you define and manage your own optimizations. I've never used it myself, so I don't know the full details, but I have seen other programs which defined "hints" to the compiler that, basically, allows you to say, "Whenever you see X, it is equivalent to Y". Then there is template Haskell, which if I recall correctly, extends this concept even further, including support for macros (which is a crude form of what you're looking for anyway).
But, I shy away from all these automatic systems, because there is no one-to-one correspondence with what I write, and what the computer executes. I've been burned by this more times than I can remember. No, I prefer instead to write simple code, with a simple compiler, producing simple binaries. I don't care how long they run, at least at first. If, and only if, performance becomes an issue, then I'll look at profiling and optimizations. (You do profile first, right?)
Finally, what you're describing cannot solve the largest problem of all -- the recognition that you're writing a simple linked list implementation when you meant a B-tree. But, then again, what kind of B-tree? Would a skip-list be sufficient? You want real 2-3-4 trees, or are you happy with an AVL-tree implementation?
I vote no to automatic anything. The computer is stupid, able to recognize, and optimize based on, only the most basic of arithmetic truths. There are a number of them, for sure; but, what you're calling for above makes no economic sense. Why write one implementation of something, when you write rules on how to replace said something with something else. You might as well just delete and re-write the relevant code into "something else" from the start. You'll save time, money, energy, frustration, nerves, and electricity.