From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Clinton Ebadi Newsgroups: gmane.lisp.guile.devel Subject: Re: [patch] subordinate SMOBs with GOOPS superclasses Date: Wed, 12 Dec 2007 15:38:03 -0500 Message-ID: <87prxbabtg.fsf@unknownlamer.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=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1197491909 23306 80.91.229.12 (12 Dec 2007 20:38:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Dec 2007 20:38:29 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 12 21:38:39 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 1J2YLl-0008TX-Mn for guile-devel@m.gmane.org; Wed, 12 Dec 2007 21:38:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J2YLT-0003ki-NY for guile-devel@m.gmane.org; Wed, 12 Dec 2007 15:38:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J2YLO-0003hP-Ae for guile-devel@gnu.org; Wed, 12 Dec 2007 15:38:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J2YLM-0003dS-Jt for guile-devel@gnu.org; Wed, 12 Dec 2007 15:38:13 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J2YLL-0003d1-Rk for guile-devel@gnu.org; Wed, 12 Dec 2007 15:38:12 -0500 Original-Received: from deleuze.hcoop.net ([69.90.123.67]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J2YLL-0006Ov-0E for guile-devel@gnu.org; Wed, 12 Dec 2007 15:38:11 -0500 Original-Received: from cpe-071-077-055-135.nc.res.rr.com ([71.77.55.135] helo=localhost.localdomain) by deleuze.hcoop.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J2YLJ-0006an-Dd for guile-devel@gnu.org; Wed, 12 Dec 2007 15:38:09 -0500 In-Reply-To: <87d4tbvhqr.fsf@ossau.uklinux.net> (Neil Jerram's message of "Wed\, 12 Dec 2007 19\:24\:28 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 1) 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:6928 Archived-At: Neil Jerram writes: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Hi Andreas, >> >> Andreas Rottmann writes: >> >>> You should probably also have a look at the Scheme-Level FFI of PLT >>> Scheme[1], and my reimplementation for Scheme 48[2]. >> >> Thanks for the links, that's the kind of think I had in mind. Perhaps >> you'd like to port S42 to Guile as well? :-) > > 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 think doing things at runtime is a better idea--it fits more with the interactive compile-one-expression-at-a-time nature of Lisp.=20 UFFI and CFFI in the Common Lisp world work this way, and generally bindings to C libraries are solid. There may be an increased risk of crashing the system during the initial development stage, but once speced out the data type specifications rarely change. Any strange issues that occur when interfacing with C this way should also be trappable and transformed into a Guile exception that could be caught and not abort the entire system. At least in SBCL it takes a lot of abuse before a C library can crash anything. Perhaps G-Wrap could be modified to work at runtime? A few utilities from it would be of general use--e.g. the sublanguage for specifying the layout of C structs could be used for generating high level interfaces to network protocols without painful manual munging or resorting to C. --=20 Who will tend the garden when the snake swallows the light?=20=20= =20=20=20=20=20=20=20=20 Who will eat the decay when the worms have lost their sight?=20=20= =20=20=20=20=20=20=20=20 Who will rape the weak when there's nothing left to gain?=20=20= =20=20=20=20=20=20=20=20=20 Who will till the soil of these barren black remains?=20=20=20= =20=20=20=20=20=20=20=20=20=20 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel