[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: First look at Guile Std Library available
From: |
Richard Todd |
Subject: |
Re: First look at Guile Std Library available |
Date: |
Fri, 2 Jan 2004 19:03:39 -0600 |
User-agent: |
Mutt/1.5.4i |
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
pgp_JNPPPcKA5.pgp
Description: PGP signature
Re: First look at Guile Std Library available, Thien-Thi Nguyen, 2004/01/03