From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jeff M." Newsgroups: gmane.emacs.help Subject: Re: The fundamental concept of continuations Date: Tue, 09 Oct 2007 19:27:10 -0000 Organization: http://groups.google.com Message-ID: <1191958030.300166.209950__39170.7524461255$1192017387$gmane$org@57g2000hsv.googlegroups.com> References: <1191906949.179197.217470@57g2000hsv.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: sea.gmane.org 1192017382 25766 80.91.229.12 (10 Oct 2007 11:56:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 10 Oct 2007 11:56:22 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Oct 10 13:56:20 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IfaAi-0005Qf-DM for geh-help-gnu-emacs@m.gmane.org; Wed, 10 Oct 2007 13:56:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IfaAc-0002CO-QM for geh-help-gnu-emacs@m.gmane.org; Wed, 10 Oct 2007 07:56:10 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!57g2000hsv.googlegroups.com!not-for-mail Original-Newsgroups: comp.lang.scheme, comp.lang.lisp, comp.lang.functional, gnu.emacs.help, comp.lang.python Original-Lines: 63 Original-NNTP-Posting-Host: 65.116.35.251 Original-X-Trace: posting.google.com 1191958032 32279 127.0.0.1 (9 Oct 2007 19:27:12 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Tue, 9 Oct 2007 19:27:12 +0000 (UTC) In-Reply-To: <1191906949.179197.217470@57g2000hsv.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: 57g2000hsv.googlegroups.com; posting-host=65.116.35.251; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Original-Xref: shelby.stanford.edu comp.lang.scheme:74412 comp.lang.lisp:230830 comp.lang.functional:62607 gnu.emacs.help:152771 comp.lang.python:515598 X-Mailman-Approved-At: Wed, 10 Oct 2007 07:53:27 -0400 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:48296 Archived-At: > (6) any good readable references that explain it lucidly ? This was something that has been very interesting to me for a while now, and I'm actually still having a difficult time wrapping my head around it completely. The best written explanation that I've come across was in "The Scheme Programming Language" (http://mitpress.mit.edu/catalog/item/ default.asp?ttype=2&tid=9946). But perhaps others have better references. I'll attempt my own little explanation of call/cc. I'll butcher some of it, I'm sure, but hopefully those more knowledgeable will politely correct me. I will start with a loose analogy and point out a couple examples I came across that did make a lot of sense. First, the bad analogy I have (if you are coming from C programming like me) is setjmp and longjmp. This is a bad analogy in that you're talking about hardware and stack states as opposed to functions, but a good analogy in that it saves the current state of execution, and returns to that same state at a later time with a piece of data attached to it. My first example of using this would be to create a return function in Scheme. I hope I don't get this wrong, but the example would be something like this: (define (my-test x) (call/cc (lambda (return) (return x)))) Now, here's my understanding of what is happening under-the-hood: 1. call/cc stores the current execution state and creates a function to restore to that state. 2. call/cc then calls its own argument with the function it created. The key here is that "return" is a function (created by call/cc) taking 1 argument, and it restores execution at the same state it was when the call/cc began (or immediately after it?). This line: (return x) is really just calling the function created by call/cc, which will restore the execution state to what it was just prior to the call/cc, along with a parameter (in this case, the value of x). My next example I don't follow 100%, and I won't attempt to reproduce it here, but it generates a continuation that modifies itself (bad?) to define a list iterator. http://blog.plt-scheme.org/2007/07/callcc-and-self-modifying-code.html I recommend putting that code into a Scheme interpreter and running it. You'll get it. Hope this helps, and I look forward to better explanations than mine that will help me along as well. :) Jeff M.