[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: continuations and threads

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.

>  How many of you use call/cc and continuation objects 
>  (rather than mimicing continuations with lambda's)
>  in large programs? Do "we" really use it to implement 
>  coroutines and backtracking and threads and whatever? 

The last time I did backtracking, I built my success and failure
continuations explicitly with lambda.  I didn't use call/cc.

I've been toying with the idea of implementing a debugger (the
ordinary Unix kind, for debugging C and C++ programs) with Scheme as
an extension language.  Michael Golan invented a very elegant notation
for traversing arrays, linked lists, trees, and so on, for use in a
debugger; he named it "Duel".  His notation is modeled after Icon's
generators, which are a backtracking / coroutine kind of idea.

At first I thought: wow, a natural real-life application for call/cc.
But then I realized that I'd really rather implement Duel using
explicit continuation procedures.  In these situations, you always use
continuations in some constrained, stylized way; writing them out
actually makes that style more apparent.  And multiple value return is
more graceful when you've written out your continuation procedures.

I think call/cc has a lot of disadvantages.

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

- 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.

  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.

- 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.)

I often suspect that the Authors simply have a fascination with the
symmetry between calls and returns.  Thus all these papers about CPS.
In that light, call/cc and multiple value returns make sense.  But I
don't think that's the best way to choose features for inclusion in a
language meant to be used, not just reasoned about.