From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: catch, throw, prompt, control, fluids, garbage collection Date: Sun, 28 Feb 2010 22:16:24 +0000 Message-ID: <87k4tx80qv.fsf@ossau.uklinux.net> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1267395459 21750 80.91.229.12 (28 Feb 2010 22:17:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 28 Feb 2010 22:17:39 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Feb 28 23:17:35 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NlrSA-000421-K4 for guile-devel@m.gmane.org; Sun, 28 Feb 2010 23:17:34 +0100 Original-Received: from localhost ([127.0.0.1]:59162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlrSA-000504-2C for guile-devel@m.gmane.org; Sun, 28 Feb 2010 17:17:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlrS0-0004yS-S5 for guile-devel@gnu.org; Sun, 28 Feb 2010 17:17:24 -0500 Original-Received: from [140.186.70.92] (port=42377 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlrS0-0004yI-2A for guile-devel@gnu.org; Sun, 28 Feb 2010 17:17:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NlrRy-0007Qp-MJ for guile-devel@gnu.org; Sun, 28 Feb 2010 17:17:23 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]:45908) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NlrRy-0007NR-Ep for guile-devel@gnu.org; Sun, 28 Feb 2010 17:17:22 -0500 Original-Received: from arudy (host86-182-154-126.range86-182.btcentralplus.com [86.182.154.126]) by mail3.uklinux.net (Postfix) with ESMTP id D19CC1F6B37; Sun, 28 Feb 2010 22:16:44 +0000 (GMT) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 6C4923801F; Sun, 28 Feb 2010 22:16:24 +0000 (GMT) In-Reply-To: (Andy Wingo's message of "Fri, 26 Feb 2010 13:27:12 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10000 Archived-At: Andy Wingo writes: >>> Efficient with-fluids: check! So on to figuring out the prompt and >>> abort implementations... >> >> Prompt and abort: check! Now to finally implement catch, throw, and >> all that in terms of delimited continuations... (Do I foresee a future >> reply from myself?) > > Catch and throw in terms of prompt and abort: check! And passing the > test suites, of course. Give master a pull! Sorry for breaking the reply pattern... :-) This all sounds like great stuff to me. I haven't understood every detail, but it all feels very right. One particular application that I don't think you've mentioned: it was recently suggested to me that when a Guile program is running under a debugger, and hits some kind of error, the debugger could offer a menu of places in the program to jump back to. I think that would align exactly with the set of prompt tags. Two specific questions: 1. Right at the start of the yak, you introduced the need for the "running" flag to be a fluid, because of the possibility of multiple threads simultaneously using the same set of handlers. I haven't checked how dynwinds may have changed in 1.9, but in 1.8 I'm fairly sure that your suggestion is impossible, because each new thread would be created with a clean dynamic context (including dynwinds), and not inherit the context of its creator thread. And, it feels to me like this is quite natural, not just a limitation of the 1.8 implementation. So, are you sure that elements of the wind list can be shared across thread, and hence that "running" really needs to be a fluid? 2. Does SRFI-34 (and the R6RS equivalent) fit into your plan at all? I appreciated the discussion about only being able to implement catch and throw using call/cc, if the application doesn't also use call/cc - because I think the problems with implementing SRFI-34 in terms of catch/throw, or vice versa, are very similar. Neil