Hacker News Reader

Comment by agumonkey | Hacker News Reader

Do people use conts in day jobs ?

It seemed to me that beside niche fp or implementation of async, kanren,etc people rarely used them.

Not criticizing the concept just trying to assess the real world usage.

From a high level, iterators are basically just generators (which themselves are just simple continuations). Rust is a good example since pretty much all looping is done via iterators, and most implementations of the Iterator[0] trait look similar to the examples in the article. If you squint hard, calling `iter.next()` in Rust is just like the Scheme example, where you're continuously calling the generator function to get the next value. So, the people who use Rust at their day job definitely use (a form of) continuations at their day jobs.

[0]: https://doc.rust-lang.org/std/iter/trait.Iterator.html

Well one could argue that any strucured process with more than one thing/node will embed a continuation to connect the two parts.

They show up often in writing interpreters. If you find yourself writing a parser / interpreter for a domain specific language, a good way to approach it is often to build the chain of commands to evaluate as a hierarchy of continuations.

Otherwise, you may find yourself having to implement break, continue, and return using the exception system in your implementing language, and that can end up being either aesthetically unpleasing or downright messy (I painted myself into a corner once writing an evaluation engine in Go and, to meet a deadline, implemented break using panic and recover!).

I'm using them with SimPy, a discrete event simulation library. It took me some time to understand how it works (not an expert) but I finally managed to simulate several operations of an assembly process. It really made think of concurrency and shared state. I think it's cool to know about this stuff, and I'll probably recognize when to use it in future situations.

Exception handlers are continuations.

I don't think they are, unless you are talking about the few implementations of resumable exceptions. The most obvious counter-example I can think of is C++, where the stack from where the exception was thrown is unwound to the handler, i.e. it's destroyed (doubly so if the exception handler puts anything on the stack). That's also why you can't get a stacktrace from an exception in C++ unless you specifically arranged for the thrower to include that information in the exception object.

In continuation passing style, a compiler technique, exceptions show up quite naturally as a second continuation. The whole thing is called "Double barrelled continuation passing style".

I believe exceptions are equivalent to a limited form of continuations called escape continuations where control flow can only go upwards (which is the stack unwinding). Note that this is also true of break and continue, actually, both of which can be implemented with either exceptions or escape continuations.

You can get the stack trace by breaking in "throw". Maybe you meant something else.

Breakpoints on throw are triggered before unwinding (you are effectively setting a breakpoint on the function called to unwind).

You simply cannot create a stack trace from within a C++ exception handler because that state is gone. Hence my argument that exceptions are not a continuation, there is nothing to continue.

All true. But also a bit of a diversion, because the information you wanted "from within" the exception handler is available at the throw site. Ergo, if you're trying to get it from within the handler, you're just trying to get it from the wrong place.

Even resumable exceptions are/can be much more bounded than continuations. Exceptions always respect the scope structure of the code (even though they can jump between scope levels), whereas continuations can break this arbitrarily.

In particular, in Common Lisp, restarts are only valid in the dynamic environment where they were created by restart-bind. In contrast, call/cc captures this dynamic environment and makes it available later. You can't store restarts and invoke them later the way you can with call/cc.

I'm guessing you're trying to equate

  try{
    foo()
  }catch(Exception e){
    bar(e)
  }
  
  void foo() {
    throw new exception();
  }

with

  (bar (call/cc foo))

  (defun foo (cont)
    (cont (make-exception))

However, this ignores most details of the problem. In fact, (re-entrant) continuations and exceptions can't be mixed in the same language: Common Lisp has not adopted `call/cc` for one because it's impossible or at least much harder to implement `unwind-protect` (`finally`) in the presence of `call/cc` [0].

The major difference is that continuations allow you to do this:

  (defparam *global*)
  (defparam *shadow-list* (list))
  (defun foo (cont)
    (setf *global* cont))
  (with-open-file (f "~/file.log")
    (loop
      for line = (read-line stream nil 'eof)
      until (eq line 'eof)
      collect (cons line (call/cc foo)))

  (*global* *shadow-list*)
  (*global* *shadow-list*) ;; what is the state of the file here? what if there was an exception reading from the file?

[0] https://groups.google.com/g/comp.lang.lisp/c/1Ggl_BUi3Yg/m/V...

Naw, it's not impossible; you just use dynamic-wind. But to me this has a bit of the spirit of "Now, you have two problems..."

Well, dynamic-wind itself does not do what unwind-protect does. You have to manually "save/resume" the dynamic environment with the after/before clauses of dynamic-wind.

To be fair, it's probably relatively easy to use dynamic-wind to raise some runtime error when trying to resume the continuation after the original context "ended".

It doesn't, no, but yes, that was my thought: write a version of with-open-file implemented in terms of dynamic-wind that raises a runtime error if you try to reenter. Better hope people are using call/cc for exception handling and not threading though...

Pitman's comments on this are in http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuat..., Sitaram's response is at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.79.3..., and Pitman's final response is at http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuat....

I have seen exceptions implemented with setjmp/longjmp, and I have seen continuations implemented with setjmp/longjmp/memcpy. So they are definitely related, but equivalent? Or are you saying something else?

Go coroutines (and any implementation of stackfull coroutines) are equivalent to one-shot continuations.

Go doesn't have coroutines-the-flow-control-construct. It has goroutines, which are lightweight preemptively scheduled threads. You can, on top of this thing, arrange for a bunch of goroutines only one of which is not blocked at a time, which is a bit like having coroutines, but probably involves more synchronization code than a typical implementation of coroutines-the-flow-control-construct.

Well channels do randez-vous, conceptually similar yield. Having only one coroutine running at any time is really not required.

Disclaimer: I have never written a line of Go in my life.

If lower levels of the stack used them then more people would use them.

https://www.cs.cornell.edu/people/egs/papers/trickles-tocs.p... https://thelackthereof.org/docs/library/cs/continuations.pdf

Reply on news.ycombinator.com