From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.user Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: Sat, 13 Apr 2002 19:58:31 -0500 Sender: guile-user-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018746063 13668 127.0.0.1 (14 Apr 2002 01:01:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 14 Apr 2002 01:01:03 +0000 (UTC) Cc: ttn@glug.org, guile-devel@gnu.org, guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16wYO6-0003YG-00 for ; Sun, 14 Apr 2002 03:01:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16wYNC-0004cr-00; Sat, 13 Apr 2002 21:00:06 -0400 Original-Received: from dsl-209-87-109-2.constant.com ([209.87.109.2] helo=defaultvalue.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16wYLg-0004Ym-00; Sat, 13 Apr 2002 20:58:33 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id F2C011B0B; Sat, 13 Apr 2002 19:58:31 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 41FAB2D86; Sat, 13 Apr 2002 19:58:31 -0500 (CDT) Original-To: Neil Jerram In-Reply-To: (Neil Jerram's message of "13 Apr 2002 09:50:22 +0100") Original-Lines: 88 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:168 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:168 Neil Jerram writes: > The description you gave of the Emacs patch glossed over one detail - > what's the name of the function that gets called to initialize the > dynamically loaded module? I think it would be acceptable to derive > it algorithmically from the module name (and obviously impose this as > a requirement on the module coder). Some of the higher level abstractions and flexibility sound good, but I'm a little concerned about automatically generating the init function from the module name -- this makes it hard (as I mentioned before) to create modules that share the same C lib or modules that require multiple C libs. It may also make it difficult to easily wrap up existing libs without having to create unnecessary "dummy stub" libs, and feels a little like overspecification. Of course this would only be a problem if it was the *only* interface. If we also provided a flexible enough low-level interface for loading shared libs, then having a more automagic, optional higher-level interface might be fine. > If we can agree this, it would be good to do it in 1.6, for > continuity. (Of interface, I mean; module coding would change > slightly, as just stated.) My current plan is for 1.8 to have versioned scheme level modules (i.e. use-modules modules), and some workaround that allows for versioned dynamic-link'ing (in part to avoid libtool problems with installations of multiple guile versions), so I don't think there's much chance for seamless continuity between 1.6 and 1.8 anyway. Given that, I don't think it's worth holding up 1.6 for this, and in truth, my personal feeling (given my experiences with the module system and shared libraries while working on gnucash, g-wrap, mainstream guile, and other projects) is that the current 1.6 system is a lot easier to follow. In the normal case, by looking at one .scm file, you know exactly what's going on, and what's part of a module's interface. (define-module (foo bar)) (dynamic-call "my_init_func" (dynamic-link "libmylib")) (export func1) (export func2) ... (load-extension might also (should?) be used here). To me this code is *really* clear, but other people's mileage may vary :> > More generally, looking back through mailing list history, it's > actually astonishing how much support for various stuff that Guile > has _lost_ along the way. My overall impression is that we > (collectively) have been too glib about this. I guess I'd have to disagree here too. Most of the stuff that I can think of that we've "lost" actually makes guile cleaner and less confusing to me, and the stuff that we've added (or are adding) makes guile much more useful. As examples of things we've done or planned since 1.4: drop gh_* -> less confusing add documentation for scm_* -> more useful. add goops -> *much* more useful adding GMP -> (for bignums -- on the way to rationals?) more useful fixing libtool versioning issues -> more useful (more packagable) planning to drop certain macro "flexibility" so we can support a clear evaluation model and perhaps eventually support compilation -> more useful. etc., but do you have particular things you think we've dropped that have actually hurt substantially? Overall I think guile may have (had?) a bit of excess baggage, and I've felt like there's likely to be a decent amount of pruning, pruning which should make guile stronger, before it becomes the extension languge (and perhaps often scheme implementation) of choice if it *is* going to. I guess rightly or wrongly I've been considering 1.6 and 1.8 to be fairly serious "housecleaning" releases... Of course - IMO, etc. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user