From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Matthias Koeppe Newsgroups: gmane.lisp.guile.devel Subject: Re: What replaces scm_register_module_xxx (Doc update?) Date: Fri, 09 Aug 2002 10:47:50 +0200 Sender: guile-devel-admin@gnu.org Message-ID: References: <20020808134824.GB23831@www> <20020808102103.021cdc0c.dsmith@altustech.com> <874re5mnfs.fsf@raven.i.defaultvalue.org> <20020808161958.GA24162@www> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1028882854 26885 127.0.0.1 (9 Aug 2002 08:47:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 9 Aug 2002 08:47:34 +0000 (UTC) Cc: Rob Browning , "Dale P. Smith" , guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17d5Qi-0006zU-00 for ; Fri, 09 Aug 2002 10:47:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17d5RS-0005z0-00; Fri, 09 Aug 2002 04:48:18 -0400 Original-Received: from saturn.math.uni-magdeburg.de ([141.44.75.38]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17d5R9-0005va-00 for ; Fri, 09 Aug 2002 04:47:59 -0400 Original-Received: from beta.math.uni-magdeburg.de (beta [141.44.75.78]) by saturn.math.uni-magdeburg.de (8.11.6/8.11.6) with ESMTP id g798lpX07730; Fri, 9 Aug 2002 10:47:51 +0200 (MET DST) Original-Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.10.2+Sun/8.10.2) id g798lo700124; Fri, 9 Aug 2002 10:47:50 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f Original-To: rm@fabula.de In-Reply-To: <20020808161958.GA24162@www> (rm@fabula.de's message of "Thu, 8 Aug 2002 18:19:58 +0200") Original-Lines: 73 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1.80 (sparc-sun-solaris2.7) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1039 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1039 rm@fabula.de writes: > On Thu, Aug 08, 2002 at 09:31:51AM -0500, Rob Browning wrote: >> "Dale P. Smith" writes: >>=20 >> > The new method is to use a .scm file that defines the module, >> > dynamically loads the compiled code, and then exports whatever you >> > need. >>=20 >> Right. >>=20 >> (define-module (foo bar)) >> (load-extension "libguile-foo-bar-v-1" "init_guile_foo_bar-v-1") >> (export foo-1) >> (export foo-2) >> (export bar-1) >> ... > > I think there's a misunderstanding/misconception here (or, better: > in guile's current C api). The 'load-c-functions-through-scheme'=20 > aproach might be fine and all that's needed as long as we only want > to extend _guile_ (the application) with external libs. But guile > is inteded to be an embedded srcipting language as well (at least that's > what the documentation says). If i want my users to be able to script > some of my applications functionality there's no library i can load > with 'load-extension' -- of course i could put the tiny scm_* wrapper > functions into a dll and have _that_ loaded, but i wouldn't call this=20 > good design practise (oh, i could 'load-extension' my own application > instead, but that's not really portable ...). Having to provide (and > deploy!) scm file(s) just to be able to put my functions into different > modules feels clumsy.=20 Indeed. I just want to point out that there was a similar discussion back in May 2001 ("On the deprecated auto-loading of compiled-code modules"). See http://mail.gnu.org/pipermail/guile-devel/2001-May/thread.html#1922 Back then, I had complained that I could no longer do module business from C after scm_register_module_xxx became deprecated.=20=20 After some discussion, Marius wrote (http://mail.gnu.org/pipermail/guile-devel/2001-May/002171.html): # Ok. It's "Drastic Measures Time". [Thinking as I type...] People # should be able to handle modules from C, in a way mostly similar to # how they do it from Scheme. We don't want to guarantee the lower # level module operations to be stable, but the higher level ones should # be OK for quite some time (even when we get a totally new module # system, I hope that we can find a way to integrate the higher level # features in a backward compatible way). He proposed and implemented a C API for defining modules and exporting symbols, see http://mail.gnu.org/pipermail/guile-devel/2001-May/002171.html I use this API in the Guile back-end of SWIG (http://www.swig.org). The functions are also mentioned in the NEWS file of Guile (changes after release 1.4). The API is also used in examples/box-module/box.c. I believe it's only an accident that the functions are not documented (except for the NEWS blurb). I think documentation should be added; the changes should also go into the 1.6 release. Preliminary documentation can be found in the above message by Marius. Regards, --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel