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: =?UTF-8?Q?scm=5Fc=5Fcatch=20question?= Date: Wed, 20 Aug 2014 20:02:33 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1408557798 13463 80.91.229.3 (20 Aug 2014 18:03:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Aug 2014 18:03:18 +0000 (UTC) To: guile-devel@gnu.org, ian.a.n.grant@googlemail.com Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Aug 20 20:03:12 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XKADo-0003PF-Pm for guile-devel@m.gmane.org; Wed, 20 Aug 2014 20:02:57 +0200 Original-Received: from localhost ([::1]:56865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKADo-0001e6-E0 for guile-devel@m.gmane.org; Wed, 20 Aug 2014 14:02:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKADd-0001U4-5p for guile-devel@gnu.org; Wed, 20 Aug 2014 14:02:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKADW-0000z3-Dr for guile-devel@gnu.org; Wed, 20 Aug 2014 14:02:45 -0400 Original-Received: from out1.ip07ir2.opaltelecom.net ([62.24.128.243]:10917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKADW-0000y0-8F for guile-devel@gnu.org; Wed, 20 Aug 2014 14:02:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIIAHbh9FNOkR1nPGdsb2JhbABZgw1TV4IsUMlRh1kBgRAXBQEBAQE4NoQDAQEEASMPAQUeKAsEBAMYAgImAgIsDQoUBxqIMgwJrSuVORMEGIEUiDWFcoJ5gVMBBJxEjA6MWzsvAYJOAQEB X-IPAS-Result: AiIIAHbh9FNOkR1nPGdsb2JhbABZgw1TV4IsUMlRh1kBgRAXBQEBAQE4NoQDAQEEASMPAQUeKAsEBAMYAgImAgIsDQoUBxqIMgwJrSuVORMEGIEUiDWFcoJ5gVMBBJxEjA6MWzsvAYJOAQEB X-IronPort-AV: E=Sophos;i="5.01,903,1400022000"; d="scan'208";a="118688612" Original-Received: from host-78-145-29-103.as13285.net (HELO arudy) ([78.145.29.103]) by out1.ip07ir2.opaltelecom.net with ESMTP; 20 Aug 2014 19:02:34 +0100 Original-Received: by arudy (Postfix, from userid 33) id 75E333803C; Wed, 20 Aug 2014 19:02:33 +0100 (BST) X-PHP-Originating-Script: 0:rcmail.php In-Reply-To: X-Sender: neil@ossau.homelinux.net User-Agent: Roundcube Webmail/0.9.5 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 62.24.128.243 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17356 Archived-At: On 2014-08-18 03:14, Ian Grant wrote: > Hi Neil, > > Sorry, I am replying to my message because I'm not on guile-devel, it > seems. I'll join later. > > Thanks for clarifying that. The misleading statement in the manual is > just above the paragraph you quote: on > https://www.gnu.org/software/guile/manual/html_node/Catch.html#Catch > [2] it says > >     Handler is invoked outside the scope of its own catch. If > handler >     again throws to the same key, a new handler from further up the >     call chain is invoked. > > It doesn't mention pre_unwind_handler, which implies that the > statement does _not_ apply to pre_unwind_handler. Yes, I believe it is correct that those statements do not apply to the pre-unwind handler. > So this should be > amended. > > But it would be more useful if there were a way to allow a throw to be > aborted as I was expecting. How hard would that be to implement? If > you think the semantics are in fact different, it could be given a new > name, scm_c_catch_and_rethrow or something. What I want is something > like BSD signals semantics, where the handler is not reset when the > signal occurs. > > You ask "In your code, the pre-unwind handler calls failwith() and > doesn't expect it to return - so where does it jump to?" > > I thought I had explained that, sorry. The call to failwith() does a C > longjmp back into the CAML bytecode interpreter (i.e. back down below > the call stack into caml_main). This is not a non-local exit, as far > as Guile is concerned, because it is just a 'naked' C longjmp. So in > that sense, the second time Guile throws an exception it is being > thrown from within pre_unwind_handler. OK, I think I see now. From Guile's point of view, the dynamic context of the 'catch' remains in effect - as you want - but with a flag to say that the pre-unwind handler is already running (actually implemented by the %running-exception-handlers fluid in boot-9.scm). That explains why the _next_ exception causes the catch's main handler to be called, instead of the pre-unwind handler again. > Is there a way to implement what I want with fluids? I don't think so, no. Basically what you need is to make some call, from the pre-unwind handler code, just before calling failwith(), that says "this pre-unwind handler should now be reactivated" and is implemented by removing itself from %running-exception-handlers. But %running-exception-handlers is hidden inside a lexical environment, so that isn't possible without hacking the boot-9 code. You could try hacking the boot-9 code, though, to see if that idea works, and then propose a patch. Regards, Neil