Yes! Subroutine call is a) allocation of activation record b) switching context c) returning that combines de-alloc and switch.
while coroutines have all of these concepts separated. Why not start with a powerful and general concept and optimize for that one?
> Why not start with a powerful and general concept and optimize for that one?
As with basically everything, there are tradeoffs involved. Sometimes restrictions can be helpful for keeping things understandable, which can in turn make optimizations easier to implement. As a rather hamfisted example: completely unrestricted goto. Very general, debatably powerful, but relatively easy to use in a way that makes comprehension difficult. That same generality can also make it difficult to verify that optimizations don't change observable program semantics compared to something more restricted.
Because you can allocate the activation record on the heap, provide a way to reify continuations, and presto! now you have call/cc (and trivially implemented, no less)!
Price paid: a) you need a GC (ok, whatever, sure, you have one), b) well, the performance hit of having to GC activation records (you don't care; others do), c) whoops, thread-safety got much harder and maybe you can't even have threads (imagine two threads executing in the same activation record at the same time!).
