Hm, none of the first three objections apply in my world:

  - It's hard to understand call/cc itself.

That depends on who explains it to you.

  - It's hard to understand programs that use call/cc.  I still have a
    hard time reasoning about programs that use it in any but the most
    constrained ways.

Most people learn programming by analogy and that's the reason we see so
many Fortran programs that use Java syntax. Relabel yourself to save your
career, Szyperski said during a talk here last Tuesday. [I am not saying
this about you, but that's just the way the world is.]

That's why I work on explaining programming as a rational process.

    For example, certain transformations that I expect to preserve
    meaning (perhaps because I have habits of thought learned from other
    languages) don't in the presence of call/cc.  I still don't really
    understand why call/cc needs special consideration in static type
    inference.  And so on.

Many things carry over, but some don't. It actually isn't that difficult to
set up a logic that explains these things.

A static type discipline for call/cc has problems only when you include
uniform (parametric) polymorphism and then it has the **exact same problems
that references pose** (I discovered this the hard way in my paper on type
soundness for such things).

  - It imposes a lot of weird global constraints on implementations,
    making them harder to maintain.  (Maybe this is the same as the last
    point, if you blur the line between an implementation and the
    programs you run on it.)

Now there we go. Every time I think about co-mingeling some language like C
and Scheme, on the same stcak, I get the feeling that call/cc causes havoc.

But my real observation is this. I conjectured during my "Author years" :-)
that large systems would contain small "kernels of intense control" and
that programmers should have powerful tools available to build such
kernels. (I built Icon's stuff in an evening. I went to UofA, the Icon
school, and Indiana, the Scheme school. Sorry, but Indiana builds UofA in a
day.) But the more I hear about large systems, building these kernels of
control isn't done with call/cc -- even though in theory it would be
better. And what's worse, the real problem is not building these small
things but controlling the interdependencies between program components in
a dynamic and extensible world.

Perhaps the real question is: will throwing out call/cc make our life as
implementors so much easier to off-set the language deficit? Or will it
even enable things that we need for "real" things and don't get at the
moment? (Such as simple collaboration with C?)

-- Matthias