Re: First look at Guile Std Library available

[Dale Mellor]

>>>>> "RT" == Richard Todd <address@hidden> 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.