From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Prototype for C++-compatible Guile Exceptions. Date: Fri, 04 Sep 2015 04:06:45 -0400 Message-ID: <87zj12zjze.fsf@netris.org> References: <1436897249-18167-1-git-send-email-ahmed.taahir@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441354069 444 80.91.229.3 (4 Sep 2015 08:07:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Sep 2015 08:07:49 +0000 (UTC) Cc: guile-devel@gnu.org To: Taahir Ahmed Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Sep 04 10:07:47 2015 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 1ZXm2D-0004Wv-ID for guile-devel@m.gmane.org; Fri, 04 Sep 2015 10:07:45 +0200 Original-Received: from localhost ([::1]:56824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXm2E-0001GV-IP for guile-devel@m.gmane.org; Fri, 04 Sep 2015 04:07:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXm2C-0001GN-K2 for guile-devel@gnu.org; Fri, 04 Sep 2015 04:07:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXm29-0005tv-CH for guile-devel@gnu.org; Fri, 04 Sep 2015 04:07:44 -0400 Original-Received: from world.peace.net ([50.252.239.5]:47599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXm29-0005oV-8U for guile-devel@gnu.org; Fri, 04 Sep 2015 04:07:41 -0400 Original-Received: from [10.1.10.32] (helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ZXm1r-0007u6-Ss; Fri, 04 Sep 2015 04:07:23 -0400 In-Reply-To: <1436897249-18167-1-git-send-email-ahmed.taahir@gmail.com> (Taahir Ahmed's message of "Tue, 14 Jul 2015 13:07:26 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 50.252.239.5 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:17819 Archived-At: Taahir Ahmed writes: > Currently, the use of libguile functions from C++ is fraught with > danger. C++ destructors are not triggered by guile exceptions, and the > dynwind mechanism is ill-suited for application to C++ data structures > (in particular, STL structures). I agree that we need to improve this. Thanks for stepping forward to work on it. I apologize for the long delay. > This sequence of patches addresses this shortcoming by using hidden C++ > exceptions to perform the stack unwinding when a guile exception is > thrown, so that the pre-checking demonstrated above is not needed. Your proposal is not unreasonable, but at the present time I feel rather strongly that we should keep C++ and its runtime out of core Guile. For one thing, the C++ runtime, calling conventions, and exception model are poorly suited to Scheme, with its more general control flow, proper tail calls, garbage collection, etc. Also, especially when we have native code generation, I expect it will be highly beneficial to have complete control over our runtime, internal calling conventions, and internal exception handling. These considerations argue for us to move in the direction of _fewer_ marriages to external runtime libraries rather than more. Having said that, of course we must retain good integration with code written in other languages and runtimes such as C and C++. In my opinion, the best approach is to *convert* exceptions at the boundaries between libguile and application code. This opens the door for us to integrate nicely not only with C++, but also with other languages and runtimes. In general, the approach would be to add language-specific wrappers for all public libguile API functions. These would arrange for Guile exceptions thrown within libguile to be converted into whatever type of exception or error handling is desired by the caller. Wrappers would also be needed at the interfaces where libguile calls back to user code. These wrappers would do conversion in the other direction, e.g. by catching C++ exceptions and converting them into Guile exceptions. I'm not sure what is the best approach to creating these wrappers, but I guess it could be done with some combination of the C preprocessor and snarfing tools that scrape our headers and generate code. I guess it will also involve adding an optional C++ library containing code needed by the wrappers. I'm okay with adding C++ code within "#ifdef __cplusplus" in our headers, as long as a C++ compiler is not needed to compile libguile or its C users. Do you think that an approach like this would work for you? Regards, Mark