"I was in fact thinking of such common uses as the loop macro."
Smalltalk has always done iteration this way with blocks (closures), and because of the syntax it works and looks nice.
Of course this needs the "sufficiently smart compiler" to be efficient. But there's no way to program domain-specific knowledge into the compiler like you can with macros. For example Gerald Sussman has done a lot of work in optimizing numerical code symbolically (http://repository.readscheme.org/ftp/papers/berlinsurati-pep...), I think _On Lisp_ has a chapter about doing partial evaluation on Bezier curves, and there's some regex-specific tricks in CL-PPCRE that I don't think can be matched by generic partial evaluation.
But there's no way to program domain-specific knowledge into the compiler like you can with macros.
You can. It just won't be as syntactically elegant. Use expression trees and code emission the language exposes. The optimization happens at run-time, rather than compile time. But you'll actually, in most cases, get more optimization opportunity.
I loved the flexibility they allowed when I first used them, but these days they often feel to me like going down a level in that more needs to be expressed. Yeah, if your tools can't efficiently handle your current case, that escape hatch is incredibly valuable.
Smalltalk has always done iteration this way with blocks (closures), and because of the syntax it works and looks nice.
Of course this needs the "sufficiently smart compiler" to be efficient. But there's no way to program domain-specific knowledge into the compiler like you can with macros. For example Gerald Sussman has done a lot of work in optimizing numerical code symbolically (http://repository.readscheme.org/ftp/papers/berlinsurati-pep...), I think _On Lisp_ has a chapter about doing partial evaluation on Bezier curves, and there's some regex-specific tricks in CL-PPCRE that I don't think can be matched by generic partial evaluation.