From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.devel Subject: Re: Adding stuff to the core distro (was Re: Infix syntax) Date: Fri, 18 Oct 2002 02:24:40 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02101802244004.07034@locke.free-expression.org> References: <87u1jub4lh.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035014510 432 80.91.224.249 (19 Oct 2002 08:01:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 19 Oct 2002 08:01:50 +0000 (UTC) Cc: Neil Jerram , guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 182oYO-00006a-01 for ; Sat, 19 Oct 2002 10:01:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 182oYM-0007St-00; Sat, 19 Oct 2002 04:01:46 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 182oXT-0007DO-00 for guile-devel@gnu.org; Sat, 19 Oct 2002 04:00:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 182oXL-0007Bh-00 for guile-devel@gnu.org; Sat, 19 Oct 2002 04:00:46 -0400 Original-Received: from gnudist.gnu.org ([199.232.41.7]) by monty-python.gnu.org with esmtp (Exim 4.10) id 182a2V-0001ta-01 for guile-devel@gnu.org; Fri, 18 Oct 2002 12:31:55 -0400 Original-Received: from plounts.uits.indiana.edu ([129.79.1.73]) by gnudist.gnu.org with esmtp (Exim 4.10) id 182RiD-0007AJ-00 for guile-devel@gnu.org; Fri, 18 Oct 2002 03:38:25 -0400 Original-Received: from logchain.uits.indiana.edu (logchain.uits.indiana.edu [129.79.1.77]) by plounts.uits.indiana.edu (8.12.1/8.12.1/IUPO) with ESMTP id g9I7UEL8007148; Fri, 18 Oct 2002 02:30:15 -0500 (EST) Original-Received: from locke.free-expression.org (dial-122-54.dial.indiana.edu [156.56.122.54]) by logchain.uits.indiana.edu (8.12.1/8.12.1/IUPO) with SMTP id g9I7U8W6005997; Fri, 18 Oct 2002 02:30:09 -0500 (EST) Original-To: Daniel Skarda <0rfelyus@ucw.cz>, Rob Browning X-Mailer: KMail [version 1.2] In-Reply-To: Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1567 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1567 On Wednesday 16 October 2002 19:10, Daniel Skarda wrote: > Lynn Winebarger writes: > > Keeping the trees separate is a proactive measure for preventing code incest. > > (I had to read this sentence few times before I fully understood it :-) I blame ttn for that. I believe he's infected me with some sort of language virus. ;-) It also has the virtue of being both true and funny to say. > srfi-1 is very good example - it is really large module and it sometimes makes > me thinking: "I want to use only function `every' (or fold-left) - why I have to > include so BIG list library?" I think this misposes the question. I should be able to have all the functions in srfi-1 _presented_ in one large module, but the module system should not require that they are all defined in one big file, or even that I need to actually import them all. Why can't I define a bunch of little modules (possible with dependencies) and then load those into srfi-1 which then exports all those names as one big group? [ Or just load the subset I actually want/need ] Not being able to do that is a deficiency in a module system IMO. > What does it mean "keeping the trees separate is a proactive measure for > preventing code incest"? If it means that every guile developer has to reinvent > the wheel again and again (because of holy grail of small set of dependencies), > than it is bad measure. The goal is not a small set of dependencies (per se). It's just cleaner to keep code from having more knowledge about other code than it should. SE101. I think it's a little easier to enforce this minimalism of code knowledge if you actually keep code in separate directories. If anything, I'd probably advocate separating what's in the libguile directory now into smaller, mostly independent directories, where a developer could be reasonably certain that to understand a piece of code in a file they probably would only need to look at other files in that subdirectory, or possibly in some header files (or possibly other subdirectories closer to the real core code, i.e. eval.c). As I said, I think the eventual dependencies of distributions are the job of the vendor, not of Guile hackers (per se). Rob, of course, does both, but they are separate roles and the one shouldn't unduly influence the other. Making it easy to reduce dependencies is probably a good idea, but because it comes from the same basic SE101 principles I mentioned above rather than just in and of itself. Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel