From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Todd Newsgroups: gmane.lisp.guile.user Subject: Re: First look at Guile Std Library available Date: Fri, 2 Jan 2004 19:03:39 -0600 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <20040103010339.GA2501@pazuzu> References: <20040102052128.GA16849@Richard-Todds-Computer.local> <16373.14841.524453.369087@l.a> Reply-To: Richard Todd NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1128220746==" X-Trace: sea.gmane.org 1073092527 31137 80.91.224.253 (3 Jan 2004 01:15:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Jan 2004 01:15:27 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Jan 03 02:15:24 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 1AcaNw-0001uf-00 for ; Sat, 03 Jan 2004 02:15:24 +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 1AcbL2-0007lt-RD for guile-user@m.gmane.org; Fri, 02 Jan 2004 21:16:28 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AcbGa-00070V-Dw for guile-user@gnu.org; Fri, 02 Jan 2004 21:11:52 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AcbBN-0005hv-OT for guile-user@gnu.org; Fri, 02 Jan 2004 21:07:01 -0500 Original-Received: from [66.171.59.140] (helo=smtp.vzavenue.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AcbBL-0005gw-Js for guile-user@gnu.org; Fri, 02 Jan 2004 21:06:27 -0500 Original-Received: from demon.pazuzu.hrn (177.158.171.66.subscriber.vzavenue.net [66.171.158.177]) by smtp.vzavenue.net (Mirapoint Messaging Server MOS 3.2.4-GA) with SMTP id BCC33428; Fri, 2 Jan 2004 20:04:51 -0500 (EST) Original-Received: by demon.pazuzu.hrn (sSMTP sendmail emulation); Fri, 2 Jan 2004 19:03:39 -0600 Original-To: Dale Mellor In-Reply-To: <16373.14841.524453.369087@l.a> 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:2499 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2499 --===============1128220746== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thanks for the comments--I'll try to elaborate on my goals here, although that may make you even more sure that I'm going in the wrong direction! :) Please let me know. On Fri, Jan 02, 2004 at 10:29:29AM +0100, Dale Mellor wrote: > The collection of modules seems to be something of a hodge-podge of utility > libraries (just because PERL and Python do it this way doesn't mean we have to), > and overlaps with other stuff we already have (notably ice-9 and slib). I think > that we should move towards developing some 'standard' libraries as separate, > community-managed projects. I'm open to all suggestions on ways we can improve on the perl/python approach. (Note that other scheme implementations have libs like this, also). I've started there because: 1) It is an existing, successful, and popular approach 2) I can leverage the design of their modules to get farther, faster 3) Guile currently doesn't have _any_ approach, as far as I can tell As for the overlap, one of the problems I'm trying to address is that ice-9 and SLIB are hodge-podges themselves, in my view. SLIB overlaps guile-core and ice-9, and doesn't use guile's native module system either. I want to incorporate a lot of both of them (several of the parts I have so far are in fact derived from SLIB), but put them in a framework of modules that are cohesive and documented. I want to produce _the_ basic set of guile modules, that allow development to start with a largish base of stable, documented functionality supporting it. The hodge-podginess of what I've put out there so far is readily apparent because it's so preliminary--there's just not much there yet. Of course, you might be saying that once we've filled it out that it'll just be a much more comprehensive hodge-podge :) > - a low-level wrapper around libc (simple procedure definitions which reflect > those in libc, much of which is already in ice-9, and a lot of the rest is > hardwired in Guile anyway - it just needs documenting in one place) Although it's a topic for much later, I don't think that all that stuff _should_ be hard-wired in guile itself. And even when it's not, a single flat (ice-9 xxx) namespace for modules leaves something to be desired (though my C++/Perl/Python/etc background my be shaping an opinion other guile folks don't share..let me know). Then, as you say, there's that pesky documentation issue. > - a library which provides UNIX functionality presented in a lispish programming > paradigm (this should be Guile's workhorse UNIX interface, and is > essentially a wrapper around the above library). Maybe add in here such > things as string completion, ANSI colours, soundex... Do you have any further ideas on what this would look like? Does it already exist somewhere? > - a library of lispish containers, iterators and algorithms (akin to the C++ > STL; much of which is slib) > - a library of mathematical algorithms (akin to the good ol' NAG routines; these > will probably be better written in C and exposed to Guile through a thin > wrapper) I have places (container xxxx), (math xxxx) in my hierarchy waiting to be filled in with these. In addition to the list you gave, I think things like the ability to parse/manipulate stadard data formats (emails, PNG files, AU files, MID files, etc) would be a good fit. I also would like to see a database interface get in, which allows for plugins to various DB products. Yes, perl did that already (so did bigloo), but I don't see why that makes it wrong for guile. Missing modules of this type are what keep pulling me away from guile when it comes time to do 'real' work. I can only marvel at tail-recursion and closures for so long... :) Richard Todd richardt at vzavenue dot net --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/9hTra9lhNGIqsRIRAv2EAJ9muChDG6xCcWVeEpISAfpBKMEAUACfZEHs JSbId+EjoOE7MCnXTQOmj5Y= =q4nj -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- --===============1128220746== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user --===============1128220746==--