From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Taahir Ahmed Newsgroups: gmane.lisp.guile.devel Subject: Re: Prototype for C++-compatible Guile Exceptions. Date: Sun, 06 Sep 2015 18:01:40 -0500 Message-ID: <87d1xv871x.fsf@gmail.com> References: <1436897249-18167-1-git-send-email-ahmed.taahir@gmail.com> <87zj12zjze.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1441581942 32129 80.91.229.3 (6 Sep 2015 23:25:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Sep 2015 23:25:42 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Sep 07 01:25:37 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 1ZYjJY-0000rv-7n for guile-devel@m.gmane.org; Mon, 07 Sep 2015 01:25:36 +0200 Original-Received: from localhost ([::1]:51286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYjJX-0000E9-VA for guile-devel@m.gmane.org; Sun, 06 Sep 2015 19:25:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYjJR-0000BV-13 for guile-devel@gnu.org; Sun, 06 Sep 2015 19:25:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYjJN-0000Fp-Sz for guile-devel@gnu.org; Sun, 06 Sep 2015 19:25:29 -0400 Original-Received: from mail-ob0-x22e.google.com ([2607:f8b0:4003:c01::22e]:35387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYjJN-0000FQ-Nb for guile-devel@gnu.org; Sun, 06 Sep 2015 19:25:25 -0400 Original-Received: by obuk4 with SMTP id k4so51334889obu.2 for ; Sun, 06 Sep 2015 16:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:to:cc:subject:date:in-reply-to:message-id :mime-version:content-type; bh=BVHcmCtU42djVT7f84pGXNnzp4GgyWeeeFUm9Fd8/lE=; b=gcnlnUCZgU53qZXCRde/g28DTjek1QSZdjBBaX2S7DVYon4ujLXo6a4p9EMNsuQJnN c+0smQU7YDsgrWRyqitoC3uZFd4a60EFi8kcUz3wXpbqTqSMtAfNzOl0jbIg+cc4QXEk VTDrcMkvE3F3CNtF2ICQH0plBpS3x581dmECM4OMkxD63cj9f4PqGTY8UrN0jKIh6qex GQ41uP0Hvt9Z4MkqEqTXFjHohs/2TybHNnDrCnKRiE0xruPSqeZICEMKmF6ElgOgBag6 2Vfw4hP7K2WrMrr/Gcsei+jG/mJdPJ6QTdzc4iK4Hjusn2Qn9iLGvoSfbgt9j36nDs4C FfVQ== X-Received: by 10.182.96.168 with SMTP id dt8mr12338722obb.36.1441581924872; Sun, 06 Sep 2015 16:25:24 -0700 (PDT) Original-Received: from basis.gmail.com (50-24-3-101.bcstcmtk01.res.dyn.suddenlink.net. [50.24.3.101]) by smtp.gmail.com with ESMTPSA id t207sm3041493oie.13.2015.09.06.16.25.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Sep 2015 16:25:24 -0700 (PDT) In-reply-to: <87zj12zjze.fsf@netris.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::22e 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:17822 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Mark H Weaver writes: > 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. >=20 > 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. I'm certainly not wedded to this strategy --- I just figured that it would be better to have something concrete rather than just getting on the list and complaining. > 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. > > ... > > Do you think that an approach like this would work for you? That does sound interesting, and it seems like something I would be interested to work on in my spare time. I'm sure that there will be many pain points, but there is no point in trying to predict them ahead of time. Taahir --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJV7MtOAAoJEP0dGB2mOaLGQsEH/A1ypk/KVnmF50y+VzdrqiXk 2PJRZBHVCWFDUk/UVbO9ssgJLx2JxvnH2mFEBxUjsv0KCZFQ/jsaXaoncglkAy5b vyyuN+NpnkjQ1nczv+CLyozL+IDRaQqCGF+OkUb0kN0ka4LFkvWEr34mF5ZB/tOB CPrckjl2gGm1ZpqodpQR//y1Qnh2WlaPjykG29lx81TFczN6zEQcmS6ILeqW/3oR LZGFo/3q88VPMuN4VIrrXEkutxfIIi7c2vl0IpwT6TURHj7jKvEaC7HEXJZOJvIv idN8pq/uHUxGu9aM2+eLUX+BqO4jX5ikKL1DwzVUCTbWbKAEzQV8DPSgBYOGCAI= =D8P/ -----END PGP SIGNATURE----- --=-=-=--