From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Todd Newsgroups: gmane.lisp.guile.user Subject: Re: First look at Guile Std Library available Date: Sat, 3 Jan 2004 21:50:22 -0600 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <20040104035022.GA742@Richard-Todds-Computer.local> References: <20040102052128.GA16849@Richard-Todds-Computer.local> <87wu89q8pj.fsf@kanga.tapsellferrier.co.uk> <20040103221857.GA518@Richard-Todds-Computer.local> Reply-To: Richard Todd NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0113142179==" X-Trace: sea.gmane.org 1073189260 19974 80.91.224.253 (4 Jan 2004 04:07:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Jan 2004 04:07:40 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jan 04 05:07:37 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AczY8-0000DK-00 for ; Sun, 04 Jan 2004 05:07:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ad0Uc-0004Ih-84 for guile-user@m.gmane.org; Sun, 04 Jan 2004 00:08:02 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ad0OF-0001Gn-Ah for guile-user@gnu.org; Sun, 04 Jan 2004 00:01:27 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ad0NF-0000gv-Um for guile-user@gnu.org; Sun, 04 Jan 2004 00:00:57 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1Ad0Mc-0000SC-NO for guile-user@gnu.org; Sat, 03 Jan 2004 23:59:46 -0500 Original-Received: from [66.171.158.242] (helo=Richard-Todds-Computer.local) by mx20.gnu.org with esmtp (Exim 4.24) id 1AczLn-00030z-Gq for guile-user@gnu.org; Sat, 03 Jan 2004 22:54:51 -0500 Original-Received: by Richard-Todds-Computer.local (Postfix, from userid 501) id 76AA4724E5; Sat, 3 Jan 2004 21:50:22 -0600 (CST) Original-To: ttn@glug.org In-Reply-To: User-Agent: Mutt/1.4i X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:2513 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2513 --===============0113142179== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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?=20 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. =20 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 > ...) >=20 > (define (auto-reply ...) ...) > (define (compose-mail ...) ...) >=20 > 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 --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/941+a9lhNGIqsRIRAqgrAKCtfckmpONZivRkY8N00VTnAVqYXQCfVLLx Y4uhdrTSDpd8SUpkaw8bhoo= =Qh02 -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- --===============0113142179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user --===============0113142179==--