From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: SRFI 34 Date: 07 Mar 2004 18:34:37 +0000 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <85ptboecaq.fsf@ossau.uklinux.net> References: <20030225093608.6a8935f8.dsmith@altustech.com> <87of228kq3.fsf@zagadka.ping.de> <87vfw948g9.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079222981 16599 80.91.224.253 (14 Mar 2004 00:09:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 14 Mar 2004 00:09:41 +0000 (UTC) Cc: djurfeldt@nada.kth.se, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Mar 14 01:09:33 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B2JC8-0002UZ-00 for ; Sun, 14 Mar 2004 01:09:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B1IaP-0000Gz-RF for guile-devel@m.gmane.org; Thu, 11 Mar 2004 00:18:25 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B038v-000763-OF for guile-devel@gnu.org; Sun, 07 Mar 2004 13:36:53 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B038N-0006Yv-GH for guile-devel@gnu.org; Sun, 07 Mar 2004 13:36:51 -0500 Original-Received: from [80.84.72.14] (helo=mail2.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B038J-0006Ta-Qt for guile-devel@gnu.org; Sun, 07 Mar 2004 13:36:15 -0500 Original-Received: from laruns.ossau.uklinux.net (unknown [213.78.70.238]) by mail2.uklinux.net (Postfix) with ESMTP id 5FB54409FE3; Sun, 7 Mar 2004 18:36:10 +0000 (UTC) Original-Received: by laruns.ossau.uklinux.net (Postfix, from userid 1002) id 0439177682; Sun, 7 Mar 2004 18:34:37 +0000 (GMT) Original-To: Marius Vollmer In-Reply-To: <87vfw948g9.fsf@zagadka.ping.de> Original-Lines: 81 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3522 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3522 This is a thread from May 2003 that I never resolved. I've revisited it now because of Andreas Rottman's work on SRFI 35 (conditions), which makes me think that it would be worthwhile finishing this whole area off. Marius Vollmer writes: > 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? Yes. > If so and it is consistent with the docs then we should leave it the > way it is. Maybe the docs need some carification. I believe the docs are already correct on this point. Try `i lazy-catch' in the manual. > > 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. OK. > We can introduce a new function, however. Probably we should just > move SRFI-34 into the core and rewrite 'error' to use it. OK, but we need to be careful to preserve the behavior of existing code that uses `catch' to catch errors. Did you have a specific scheme in mind here? Here's what I think might work: - `error' and libguile errors are rewritten to use `raise' and an appropriate SRFI-35 condition object. - The default SRFI-34 exception handler maps the condition object back to a key + arg list, and calls `throw' with that key and args. > 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'. Agreed. (I glossed over this before, because (i) SRFI-34 doesn't provide any examples that test the difference, and (ii) my implementation was only a quick first attempt.) > 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. OK, but for this I have 2 technical queries. 1. To minimize changes between the official SRFI 34 code and Guile's version, it would be nice to introduce call-with-escape-continuation (implemented using throw and catch) and just replace the call-with-current-continuation's in the SRFI 34 code by call-with-escape-continuation. Is the following a good definition of call-with-escape-continuation? (define (call-with-escape-continuation proc) (let ((tag (make-symbol "call-with-escape-continuation"))) (catch tag (lambda () (proc (lambda (return-value) (throw tag return-value)))) (lambda (key return-value) return-value)))) 2. Are the define-syntax forms in SRFI-34 OK as they are, or should they be translated (for Guile) to macro definitions? Thanks, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel