It should be noted that call/cc captures (and restores, when invoked)
the _whole_ evaluation context (informally, all of the `stack'). OTH,
shift captures only the part of the context; the invocation of
shift-captured continuation _prepends_ the captured part to the
existing
context rather than _replaces_ the existing context. The dynamic
environment (at least conceptually) can be thought of as pieces of
information associated with some places in context. It is clear then
call/cc and shift differ in a fundamental way: shift is capable of
combining two pieces of dynamic environment together whereas call/cc
cannot do that. For some examples of dynamic environment (e.g.,
exceptions) it is possible to emulate this splicing, in a round-about
kind of way. In general, if the language offers no way to cut a part
of and then combine parts of the dynamic environment, then shift is
not
implementable via call/cc. This issue is discussed in detail in

        Delimited Dynamic Binding
        http://okmij.org/ftp/Computation/dynamic-binding.html#DDBinding

which gives several example of the surprising behavior of the familiar
implementations of shift/reset.

One should also note that the simple way of expressing shift via
call/cc (in the absence of dynamic environment) leaks memory, because
call/cc captures more of the context than strictly
necessary. Therefore, garbage referenced in that extra captured
context cannot be collected. One has to do trampolining.

Granted, call/cc is attractive theoretically because it `gives' us
classical logic. Other than that, it's hard to make any case for
call/cc. It seems undelimited continuations hardly ever occur in
practice. Furthermore, most of the patterns of using call/cc in
practice involve a mutable cell -- thus these patterns embody
(perhaps, poor) implementation of shift or other delimited control
operator. It seems most (if not all) code using call/cc would have
been simpler, more insightful and more efficient if a delimited
control
operator were used instead.