From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: SRFI 34 Date: 17 May 2003 22:36:06 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87vfw948g9.fsf@zagadka.ping.de> References: <20030225093608.6a8935f8.dsmith@altustech.com> <87of228kq3.fsf@zagadka.ping.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1053203757 30336 80.91.224.249 (17 May 2003 20:35:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 17 May 2003 20:35:57 +0000 (UTC) Cc: djurfeldt@nada.kth.se Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 17 22:35:54 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19H8PK-0007ss-00 for ; Sat, 17 May 2003 22:35:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19H8Qo-0002Em-08 for guile-devel@m.gmane.org; Sat, 17 May 2003 16:37:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19H8QR-0001sX-00 for guile-devel@gnu.org; Sat, 17 May 2003 16:37:03 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19H8QA-0001Cp-00 for guile-devel@gnu.org; Sat, 17 May 2003 16:36:47 -0400 Original-Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19H8Q3-0000jM-00 for guile-devel@gnu.org; Sat, 17 May 2003 16:36:39 -0400 Original-Received: from dialin.speedway42.dip31.dokom.de ([195.138.42.31] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19H8Rf-0000NC-00 for guile-devel@gnu.org; Sat, 17 May 2003 22:38:19 +0200 Original-Received: (qmail 30762 invoked by uid 1000); 17 May 2003 20:36:06 -0000 Original-To: Neil Jerram In-Reply-To: Original-Lines: 43 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Original-cc: guile-devel@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2398 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2398 Neil Jerram writes: > Our lazy-catch implementation specifically unwinds dynamic context so > that we see (handler #f) here rather than (handler 12). Effectively > the only thing that lazy-catch doesn't unwind is the stack. Ahh, I see. The lazy-catch was introduced so that one can get at the call stack via 'make-stack', right? If so and it is consistent with the docs then we should leave it the way it is. Maybe the docs need some carification. > Unwinding the fluid context is contrary to my intuition, though, and > it appears to yours also. Yes, but I don't think we should change such a fundamental thing about lazy-catch just so. We can introduce a new function, however. Probably we should just move SRFI-34 into the core and rewrite 'error' to use it. But given the semantics of lazy-catch, I think your implementation of SRFI-34 is wrong. I does _not_ run the handler in the dynamic context of the call to 'raise' since lazy-catch winds back to the dynamic context of 'with-exception-handler'. Can we use the sample implementation, and just change it to use a fluid for the list of exception handlers. Also, maybe we can replace some call/cc with 'catch', but that would just be for performance. > One option then would be to have separate wind lists > for separate kinds of dynamic context, and only unwind the list with > the catches in it. But I wonder if there are strong theoretical > reasons why having separate wind lists would be a bad thing? That would be quite unclean, I think. If we want to change lazy-catch to not unwind the dynamic context (which I think we should not), then we only need to modify scm_ithrow a bit to not call scm_dowinds for a lazy catch and to not reset the dynwinds list. It would just look into the dynwind list for the matching catch, and if it is a lazy catch, we just call the handler and do not change anything about the dynwind list. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel