From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dale Mellor Newsgroups: gmane.lisp.guile.user Subject: Re: First look at Guile Std Library available Date: Sat, 3 Jan 2004 15:36:08 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <16374.54104.736663.130429@l.a> References: <20040102052128.GA16849@Richard-Todds-Computer.local> <16373.14841.524453.369087@l.a> <20040103010339.GA2501@pazuzu> 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 1073141044 27140 80.91.224.253 (3 Jan 2004 14:44:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Jan 2004 14:44:04 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Jan 03 15:44:00 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 1Acn0S-00057B-00 for ; Sat, 03 Jan 2004 15:44:00 +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 1Acntu-0003DF-Vw for guile-user@m.gmane.org; Sat, 03 Jan 2004 10:41:18 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Acns8-0002uL-4Y for guile-user@gnu.org; Sat, 03 Jan 2004 10:39:28 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AcnqP-00026d-2L for guile-user@gnu.org; Sat, 03 Jan 2004 10:38:12 -0500 Original-Received: from [213.73.176.162] (helo=ldm.a) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AcnqN-000266-SK for guile-user@gnu.org; Sat, 03 Jan 2004 10:37:40 -0500 Original-Received: from ldm.a (localhost.0.0.127.in-addr.arpa [127.0.0.1] (may be forged)) by ldm.a (8.12.5/8.12.5) with ESMTP id i03EaAdQ009315; Sat, 3 Jan 2004 15:36:11 +0100 Original-Received: (from hydro23@localhost) by ldm.a (8.12.5/8.12.5/Submit) id i03Ea9MX009312; Sat, 3 Jan 2004 15:36:09 +0100 X-Authentication-Warning: ldm.a: hydro23 set sender to Dale Mellor using -f Original-To: Richard Todd In-Reply-To: <20040103010339.GA2501@pazuzu> X-Mailer: VM 7.14 under Emacs 21.3.1 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:2501 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2501 >>>>> "RT" == Richard Todd writes: RT> 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. RT> I'm open to all suggestions on ways we can improve on the perl/python RT> approach. (Note that other scheme implementations have libs like this, RT> also). I've started there because: 1) It is an existing, successful, RT> and popular approach 2) I can leverage the design of their modules to RT> get farther, faster 3) Guile currently doesn't have _any_ approach, as RT> far as I can tell That's all good. I guess I was arguing that Guile should have an approach, and as that's what you're creating, I'm all in favour. RT> As for the overlap, one of the problems I'm trying to address is that RT> ice-9 and SLIB are hodge-podges themselves, in my view. SLIB overlaps RT> guile-core and ice-9, and doesn't use guile's native module system RT> either. I want to incorporate a lot of both of them (several of the RT> parts I have so far are in fact derived from SLIB), but put them in a RT> framework of modules that are cohesive and documented. I want to RT> produce _the_ basic set of guile modules, that allow development to RT> start with a largish base of stable, documented functionality supporting RT> it. RT> The hodge-podginess of what I've put out there so far is readily RT> apparent because it's so preliminary--there's just not much there yet. RT> Of course, you might be saying that once we've filled it out that it'll RT> just be a much more comprehensive hodge-podge :) Point taken. >> - 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) RT> Although it's a topic for much later, I don't think that all that stuff RT> _should_ be hard-wired in guile itself. And even when it's not, a RT> single flat (ice-9 xxx) namespace for modules leaves something to be RT> desired (though my C++/Perl/Python/etc background my be shaping an RT> opinion other guile folks don't share..let me know). Then, as you say, RT> there's that pesky documentation issue. We agree there. >> - 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... RT> Do you have any further ideas on what this would look like? Does it RT> already exist somewhere? Some examples off the top of my head (I'm in knee-jerk mode again ;-) ): In the low-level library may be functions like (fork), (exec string). In a higher lispish library we might have (fork-with-pipe parent-proc child-proc), where parent-proc and child-proc are procedures which take no arguments and have their inputs and outputs set to talk to each other down a pipe or socket. Another one might be (fork-child parent-proc child-proc) where parent-proc is a procedure which takes one argument and this is passed the PID of the child, and child-proc is a procedure of no arguments (or maybe one which gets the PID of the parent). As far as I know it does not already exist, it just occurs to me that whenever I use Guile's (primitive-fork) and such like, I find myself forced into a more procedural programming paradigm, with lots of (let ..)'s and (set! ..)'s. On the other hand, imagine a world where a web server can spawn child helpers when the load gets high just by recursion... Maybe the threads stuff could also get a similar interface, thus abstracting the whole concept of sub-jobs. Another example is logging. The low-level library should contain (openlog ..) (syslog ..) and (closelog ..), but a higher-level library should provide in addition something like (with-output-to-syslog facility priority proc). I guess in the long run we need an approach which allows people to contribute facilities like these as they become needed, rather than trying to design the whole high-level library up front. For my part, I am in need of a syslog interface for my mcron project, and if I write it like I mentioned above, I'll let you have the source so you can decide whether or not you want to incorporate it into your library (I still haven't got round to actually looking at your own efforts, yet). >> - 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) RT> I have places (container xxxx), (math xxxx) in my hierarchy waiting to RT> be filled in with these. RT> In addition to the list you gave, I think things like the ability to RT> parse/manipulate stadard data formats (emails, PNG files, AU files, MID RT> files, etc) would be a good fit. I also would like to see a database RT> interface get in, which allows for plugins to various DB products. Yes, RT> perl did that already (so did bigloo), but I don't see why that makes it RT> wrong for guile. Missing modules of this type are what keep pulling me RT> away from guile when it comes time to do 'real' work. I can only marvel RT> at tail-recursion and closures for so long... :) I was not arguing against Perl or Python's approach, just making the point that we don't have to be constrained by it. I am in agreement with all you say above. Keep up the good work and hopefully the community will pull together behind you on this. Reading the above passage gave me another knee-jerk reaction, though. Rather than calling your modules (container xxxx) and (math xxxx), I think I would prefer (std container xxxx) and (std math xxxx). Dale http://rdmp.org:20202 --------------------------------------------------------------------- Despite the brusque/curmudgeonly/terse nature of my e-mails I am really a nice guy and wish you well. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user