Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Richard Todd <address@hidden>
   Date: Sat, 3 Jan 2004 16:18:57 -0600

   I wonder why
   no one has suggested that I just contribute it all to ice-9?

probably because the most important thing about a project where you plan
to harvest contributions from fellow programmers is its methodology and
how comfortably that sits w/ those programmers.  next-most important is
the structure and vision of your project (x and dx, respectively, if you
consider methodology the dx2).  ice-9 has no dx and guile maintenance
behavior demonstrates little to encourage dx2, so the end result is x
remains static (or circles the drain slowly, depending on your poetic
mood :-).  for this reason i don't suggest you to direct energy towards
ice-9, but others may have their own reasons.

   [...] a large hierarchy that's
   calling out to be filled in.  It's built from the start to be huge.
   Furthermore, it's not some bridge to a generic library with some
   single-namespace'd 'require' mechanism...it's written in guile, for
   guile users.

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?  the bridge is still guile scheme (it has to be),
and the beneficiaries are still guile users (who are all programmers,
btw, and presumably appreciative of the value of not relying on possibly
out-of-date bits of rewritten slib).  IMHO, the interesting problem to
be solved in this case is not in the code per se, but in its management.

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

   Just as people don't buy books to fill other people's
   bookshelves, it seems to me that people aren't writing much guile
   code to enhance SLIB.

hmmm, i'm stretching my brain to understand this sentence... ok.

   I hope they will want to get new code into a
   guile standard library.  Especially if it is organized and
   documented.

if you write the docs first (taking the definition of an "interface" to
include proc signatures, docs, error behavior, etc.), it will be easy
for people to see if the code they may have sitting around already fits
into the organization, and if not, to write or adapt it so that it does.

   Who can tell their boss with conviction that they
   need to build important systems tied together with ttn's personal
   scheme library?

well, ttn can, to his boss...

excuse this smarmy blurb, it's for the ignorant: ttn-pers-scheme is
released under the GNU GPL, which stipulates for its users certain
freedoms related to its source code.  germaine to this discussion is the
freedom to locally modify the source for whatever reason necessary, even
for "internal marketing/sales" purposes such as...

   The basis for this project is that it should just be:
   (use-modules (net email sendmail))

... something like:

(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?

anyway, to sum up my pov: a nice GPLed user-supported standard library
for guile would be very welcome, and most welcome would be a standard
set of well-organized interfaces, responsibly maintained.  otherwise,
no matter the name, it will simply be another *-pers-scheme package in
spirit (nothing wrong w/ that, of course ;-).

thi