From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.user Subject: Re: First look at Guile Std Library available Date: Fri, 16 Jan 2004 22:17:54 +0200 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <20040116201753.GA730@lark> References: <20040102052128.GA16849@Richard-Todds-Computer.local> <87wu89q8pj.fsf@kanga.tapsellferrier.co.uk> <20040103221857.GA518@Richard-Todds-Computer.local> <20040104035022.GA742@Richard-Todds-Computer.local> <3FF88AD5.6010701@vzavenue.net> <3FF8E7FC.20004@vzavenue.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1074778543 26112 80.91.224.253 (22 Jan 2004 13:35:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2004 13:35:43 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Jan 22 14:35:35 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ajeze-0001jm-00 for ; Thu, 22 Jan 2004 14:35:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ajex2-0003T5-49 for guile-user@m.gmane.org; Thu, 22 Jan 2004 08:32:52 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AjegV-0000Zr-EI for guile-user@gnu.org; Thu, 22 Jan 2004 08:15:47 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AjeHG-0005vk-QB for guile-user@gnu.org; Thu, 22 Jan 2004 07:50:14 -0500 Original-Received: from [216.166.232.203] (helo=ambient.2y.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1Aje7A-0003OZ-Ps for guile-user@gnu.org; Thu, 22 Jan 2004 07:39:17 -0500 Original-Received: from localhost (softdnserr [::ffff:196.44.143.222]) (AUTH: LOGIN wingo) by ambient.2y.net with esmtp; Thu, 22 Jan 2004 07:39:00 -0500 Original-Received: from wingo by localhost with local (Exim 3.36 #1 (Debian)) id 1AhaPi-0000CL-00 for ; Fri, 16 Jan 2004 22:17:54 +0200 Original-To: guile-user@gnu.org Mail-Followup-To: guile-user@gnu.org Content-Disposition: inline In-Reply-To: <3FF8E7FC.20004@vzavenue.net> X-Operating-System: Linux lark 2.4.20-1-686 User-Agent: Mutt/1.5.4i X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:2686 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2686 Hi Richard, Sorry I didn't respond when the thread was fresh, I was on holiday... On Sun, 04 Jan 2004, Richard Todd wrote: > Paul Jarc wrote: > >As long as the code exists, I don't think there's much benefit in > >aggregating it. It just has to be easy for users to find. > > Ok, I am definitely starting to feel like a stranger in a strange land, > here. It's weird, no? I too am a newcomer to the scheme world (I'm a GNOME hacker, really) and I'm baffled by the response. It's just so damn easy to make a perl module, pop it up on CPAN, and have it available to anyone with the base CPAN installation. It is one of the key factors in perl's ascendence as a scripting language. I agree that it's desirable for Guile, especially once you start to write apps in Guile itself. And what a waste to write something and have it languish on a forgotten web page. So I share your spirit. I do have a concern about versioning, however. Versioning the whole thing will be unwieldy as the package expands in size. Then we have the problem of guile modules that link to C libraries that may or may not be available, or whose available versions correspond to only one module interface. It becomes clear that a provide/require interface is needed as well, although it might not be implemented by SLIB. [ SLIB's virtue and weakness is that it is a cathedral product. Virtue, because you know it's well designed and stable, but weakness because you or I don't feel attracted to contributing, especially contributing modules whose code is useful but maybe weaker than Jaffer's. ] OK, punt the question about C library-backed guile modules for another day. But for changing interfaces in scheme modules, what is needed is a versioned `use-modules', maybe like (use-modules (math primes 1)). Actually now that I think about it you can play nifty tricks with this. Maybe you have a 1.2 and a 1.1 series of your primes module. So you have (define-module (math primes 1 1)) ... code ... (define-module (math primes 1 2)) ... interface is different ... Then you can have (define-module (math primes 1)) ;; re-export the interface of the latest version in the 1.x series (module-use! (current-module) (resolve-interface '(math primes 1 2))) (define-module (math primes)) ;; The 1.x series is the latest one (module-use! (current-module) (resolve-interface '(math primes 1))) So, use (math primes) while you're developing, but then before you release change the use-modules statement on your code to reflect the version you are using. It's kindof like linking, I guess. Still a PITA though. My concern is that we don't fall in the pit of having to change module names (think (use (gfxlib sdl1.3debian+4)) or something). Maybe my concern is overblown, like this isn't such a big deal in interpreted languages or something. So thoughts about versioning in general, and this method in particular? Regards, wingo. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user