Re: First look at Guile Std Library available

[Richard Todd]

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