That's the same curiosity that led me here: how much of higher-order functional programming could be implemented as zero-overhead abstractions over a C-like language, and what restrictions on language semantics would be the tradeoff?
I wonder what is a zero overhead abstraction. For instance closures are expensive (they malloc), but to what extent can we consider closures to be malloc'd structs; then potentially do away with the concept of structs -- because they've become a subset of the functionality provided by closures. At that point can we not consider closures as zero cost; because malloc of structs is essential to c, and with optimization we need be no more expensive
And to what extent does that hold true for every other feature? In some sense it is maybe always true
[0] http://www.mlton.org/guide/20130715/References.attachments/C... ("Flow-Directed Closure Conversion for Typed Languages")
One way to go is compilation to combinators, which are functions that don't have a runtime representation of a lexical environment, aka functions that can be serialised as C without change in semantics. Basically add arguments to represent closed over data and rewrite call sites.
On reflection I think continuation capture is a candidate for inherent overhead that cannot be eliminated - at least I can't currently see how to eliminate it - but then C can't do that. There's also the question of runtime cost of error detection, out of bounds etc, which C also doesn't do.
You probably need whole program compilation to desugar everything. And I'm essentially claiming a sufficiently smart compiler can make functional languages as fast as imperative, which has dubious empirical support. Stuff like hash tables are hard to express without mutation or overhead. Still, mlton and stalin (r4rs scheme) take a reasonable stab at it.
Probably fair to say that with today's compiler tech I'm wrong, but not in a fundamentally unsolvable tomorrow sort of way.