This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
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