Re: First look at Guile Std Library available

[Richard Todd]

On Sun, Jan 04, 2004 at 02:49:01AM +0100, Thien-Thi Nguyen wrote:
> i like the idea of providing a framework, but caution you against
> getting stuck on the implementation details.  for slib (for example), if
> the bridging is as easy as another poster has intimated, why preclude
> that from your plans? 

I'm not precluding it--but I'm trying to think through other options,
since I think the coherence of the whole library would suffer.  Maybe
not as much as I worry, but it would have to.  Let's say we take in a
logging framework, and then find some other code that does syslogging.
What are our options:

  1) We could include that code too.  So now there are two logging
mechanisms in the library.  With potentially very different styles of
interfaces, and different naming conventions.  In one all functions
are log:xxx and log:yyy, but in the other all the function names are
write-syslog.

  2) We could make the needed modifications to fit the new syslogging
behavior into the logging framework (leading to bit-rot if the
syslogger is updated and I don't take those changes right away).

The situation can be even more complicated, like if both allow you to
filter the logs by regexp, but use two different regexp libraries with
different capabilities.  Now there's another decision point.

Another example would be slib minimize.scm, which has one method for
minimization in it.  If I find another lib with four more methods in
it, should I combine them into a single, coherent module, or leave two
modules out there (possibly with contrived names so that they are
different)--one with one function and one with four?  Or wrap them in
a third module that re-exports all the methods, and attempt to keep
the two 'base' madules private?

This type of problem will show up time and again.  I have been leaning
towards the option that produces the most coherent product so far, but
like all complicated decisions, there are downsides to it.  


Another option for the project would be to actively avoid things
that are already in SLIB, Guile-core, or wherever else, and just 'fill
in the gaps.'  I'm having trouble taking that road, because it's
asking users to look 5 places for everything they think might be
available, and deal with all the variations and overlap inherent in
it.  And, though people may get tired of me waving the python standard
around, you just don't have this problem with other languages.  Sure,
there are lots of independent libraries out there, but the basics are
covered 'out of the box'.

And this is exactly the kind of discussion I'd like to have and
resolve before I put too much effort into this.  I'd like everyone to
be happy with the outcome, and contribute to a successful project.


> btw, i consider "generic library" high (and deserved) praise for slib.

I'm not knocking it for being generic--I'm saying no major scheme
implementation that I know of just points you to SLIB..  they all have
libraries of their own.


> (define-module (net email sendmail)
>   #:use-module (ttn parse-rfc822)            ; for auto-reply
>   #:use-module (j-r-hacker mail-utils)       ; for compose-mail
>   ...)
> 
> (define (auto-reply ...) ...)
> (define (compose-mail ...) ...)
> 
> and so on.  it could be that people are doing this already, but more
> locally than not (and w/ little fanfare or further distribution).  who
> knows?  who cares?

I care, because building an infrastructure that others can build on is
an important part of making guile useful in the real world.  If lots
of people are out there quietly cobbling together email packages out
of fragments of people's pet projects, then we are not acting in a
very efficient manner.

Richard Todd
richardt at vzavenue dot net

pgpNItmFCrVF5.pgp
Description: PGP signature