From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.user Subject: Re: First look at Guile Std Library available Date: Sun, 04 Jan 2004 13:59:31 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: References: <20040102052128.GA16849@Richard-Todds-Computer.local> <87wu89q8pj.fsf@kanga.tapsellferrier.co.uk> <20040103221857.GA518@Richard-Todds-Computer.local> <20040104035022.GA742@Richard-Todds-Computer.local> Reply-To: ttn@glug.org NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1073220925 26521 80.91.224.253 (4 Jan 2004 12:55:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Jan 2004 12:55:25 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jan 04 13:55:22 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 1Ad7mr-0003gh-00 for ; Sun, 04 Jan 2004 13:55:21 +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 1Ad8hz-0004gF-3e for guile-user@m.gmane.org; Sun, 04 Jan 2004 08:54:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ad8gF-000416-Gs for guile-user@gnu.org; Sun, 04 Jan 2004 08:52:35 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ad8fa-0003E2-88 for guile-user@gnu.org; Sun, 04 Jan 2004 08:52:25 -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 1Ad8fZ-0002Zo-B6 for guile-user@gnu.org; Sun, 04 Jan 2004 08:51:53 -0500 Original-Received: from [151.37.58.81] (helo=surf.glug.org) by mx20.gnu.org with esmtp (Exim 4.24) id 1Ad7hl-0002u3-1t for guile-user@gnu.org; Sun, 04 Jan 2004 07:50:05 -0500 Original-Received: from ttn by surf.glug.org with local (Exim 3.35 #1 (Debian)) id 1Ad7qt-0000hj-00 for ; Sun, 04 Jan 2004 13:59:31 +0100 Original-To: guile-user@gnu.org In-reply-to: <20040104035022.GA742@Richard-Todds-Computer.local> (message from Richard Todd on Sat, 3 Jan 2004 21:50:22 -0600) 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:2516 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2516 From: Richard Todd Date: Sat, 3 Jan 2004 21:50:22 -0600 I'm trying to think through other options, since I think the coherence of the whole library would suffer. from lurking on the emacs-devel mailing list, i've come to understand the word "coherence" in an application context (app == emacs) to be definition 1b from webster's[1], the operative word being "integration". in a library context, what kind of integration are we talking about? if integration is actually not what you mean, could you explain how would "coherence of the whole library" be measured? 1) We could include that code too. [...] 2) We could make the needed modifications [...] 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. here are two decisions you can make early on: (a) what is the policy re proliferation of work-alike (but not exactly identical) interfaces? one-size-fits-all vs pluralistic-menu. for the latter, you would probably want to specify "adapter" modules to reduce interface complexity from NxM to N+M. for the former, the proliferation problem is defined away but the immediate usefulness of the library is reduced for some users, who would be forced to do the adaptation outside the library (probably in isolation, without further distribution) -- same boat as the *-pers-scheme approach, basically. (b) what is the policy for changing an interface wrt backwards compatibility? if you allow backward-incompatible changes, users will learn to not trust the library (or at least allocate trust to those elements that have changed in this way very begrudgingly). if you disallow backward-incompatible changes, you need to be supremely careful when defining interfaces for one-size-fits-all approach, slightly less careful for pluralistic-menu. figure out (a) and (b) and a maintenance strategy will probably present itself naturally. Another example would be slib minimize.scm [...] Or wrap them in a third module that re-exports all the methods, and attempt to keep the two 'base' madules private? perhaps figuring out the maintenance axioms can help answer this. certainly, separating the design of the interface from that of the implementation allows you some flexibility. 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'. i think it would be a mistake to willfully ignore what is out there, but that doesn't mean you can't provide a valuable bundling service. much depends on how you feel about not being the only such service. 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. IME as a "user" of programming languages, tools, and employees, useful trumps standard trumps efficient. in practice, efficiency is such a fuzzy concept, it is often measured in terms of usefulness! thi ______________________________ [1] M-x dict sez: Main Entry: co·her·ence # # Pronunciation: kO-'hir-&n(t)s, -'her- Function: noun Date: 1580 1 : the quality or state of cohering : as a : systematic or logical connection or consistency b : integration of diverse elements, relationships, or values 2 : the property of being coherent _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user