From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [patch] subordinate SMOBs with GOOPS superclasses Date: Thu, 13 Dec 2007 13:14:03 +0100 Message-ID: <87lk7yg5bo.fsf@chbouib.org> References: <8763zc3htd.fsf@pobox.com> <87prxfzsb2.fsf@chbouib.org> <873aubbtlz.fsf@gkar.rotty.yi.org> <87odcxnuk2.fsf@chbouib.org> <87d4tbvhqr.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1197548126 15756 80.91.229.12 (13 Dec 2007 12:15:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Dec 2007 12:15:26 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Dec 13 13:15:28 2007 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J2myL-0000Ix-21 for guile-devel@m.gmane.org; Thu, 13 Dec 2007 13:15:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J2my2-0000wt-Kw for guile-devel@m.gmane.org; Thu, 13 Dec 2007 07:15:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J2mxx-0000rY-3F for guile-devel@gnu.org; Thu, 13 Dec 2007 07:15:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J2mxv-0000oF-11 for guile-devel@gnu.org; Thu, 13 Dec 2007 07:15:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J2mxu-0000o1-Jw for guile-devel@gnu.org; Thu, 13 Dec 2007 07:14:58 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J2mxu-0000qG-GF for guile-devel@gnu.org; Thu, 13 Dec 2007 07:14:58 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J2mxp-0005Di-6s for guile-devel@gnu.org; Thu, 13 Dec 2007 12:14:53 +0000 Original-Received: from adh419.fdn.fr ([80.67.176.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Dec 2007 12:14:53 +0000 Original-Received: from ludo by adh419.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Dec 2007 12:14:53 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 36 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: adh419.fdn.fr X-URL: http://www.laas.fr/~lcourtes/ X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i486-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:xBBqnNI0K1wlb0s+qw/XhpPu4Vo= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6931 Archived-At: Hi, Neil Jerram writes: > From a _very_ quick look, my impression is that the PLT FFI is about > equivalent in complexity and function to what the code generation side > of G-Wrap provides. > > If that's correct, then the key practical difference is that G-Wrap > does everything at build/compile time, where PLT FFI does everything > at runtime -- in which case, surely G-Wrap is the better option? I don't know about the complexity of PLT's FFI, but I do know about that of G-Wrap. ;-) First, code generation in G-Wrap is complex (spread over a number of places, each of which as to be somewhat aware of what the others do) and fragile too. Second, to accommodate different use cases, such as different memory management schemes, G-Wrap has to build in a lot of tricks: the `caller-owned', `callee-owned' and `aggregated' typespecs, not to mention `out' arguments. All these contribute to the code generation complexity. With a Scheme-level FFI, you could implement these semantics (and possibly others) in Scheme. For example, `caller-owned' and `callee-owned' are easily handled by calling libc's `strdup' et al. or whatever it takes to do the right thing. The `aggregated' typespec can be achieved using guardians, for instance. The FFI could simply provide a "C pointer" SMOB; typing can then be done by the bindings themselves, e.g., by wrapping C pointers into structs of whatever. This way, the FFI would only provide basic mechanisms, on top of which a variety of bindings can be implemented in Scheme. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel