From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.user Subject: Re: guile-lib things Date: Tue, 29 Jun 2004 18:43:51 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <1088531031.1484.94.camel@localhost> References: <1088100238.1855.207.camel@localhost> <87isdfpjzy.fsf@trouble.defaultvalue.org> <20040627214307.GT3998@backlot.linas.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1088587663 32465 80.91.224.253 (30 Jun 2004 09:27:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 30 Jun 2004 09:27:43 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jun 30 11:27:37 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BfbNQ-0002sN-00 for ; Wed, 30 Jun 2004 11:27:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BfbP8-0001Gd-Hv for guile-user@m.gmane.org; Wed, 30 Jun 2004 05:29:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BfbP4-0001GY-CA for guile-user@gnu.org; Wed, 30 Jun 2004 05:29:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BfbP3-0001GM-Kl for guile-user@gnu.org; Wed, 30 Jun 2004 05:29:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BfbP3-0001GJ-ES for guile-user@gnu.org; Wed, 30 Jun 2004 05:29:17 -0400 Original-Received: from [216.166.232.203] (helo=johnson-resources.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BfbNJ-00039h-Ns for guile-user@gnu.org; Wed, 30 Jun 2004 05:27:30 -0400 Original-Received: from localhost (mantis.schoolnet.na [::ffff:196.44.140.238]) (AUTH: LOGIN wingo) by johnson-resources.com with esmtp; Wed, 30 Jun 2004 05:22:23 -0400 Original-Received: from wingo by localhost with local (Exim 3.36 #1 (Debian)) id 1BfMeI-0007DM-00 for ; Tue, 29 Jun 2004 18:44:02 +0100 Original-To: Guile Users In-Reply-To: <20040627214307.GT3998@backlot.linas.org> X-Mailer: Ximian Evolution 1.5.7 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.4 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:3295 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:3295 Hey folks, Ya'll have made me nearly reverse my position, FBOFW :P On Sun, 2004-06-27 at 16:43 -0500, Linas Vepstas wrote: > On Fri, Jun 25, 2004 at 01:31:29PM -0500, Rob Browning was heard to remark: > > Andy Wingo writes: > > > > > [0] At one point, I wanted strictly taxonomic names for the > > > modules. > > > > That said, I tend to prefer flatter namespaces for modules when > > there's a choice. For example, modules like (text regexp pcre), (db > > relational sql postgresql), or even (graphics opengl) seem > > unnecessary and even potentially confusing to me. > > Yes! Deep taxonomies also hinder authors who are working on > new stuff, which tends to cross boundaries: if it could be easily > classified, it would be a whole lot more boring, and maybe not > worth doing .... For example, suppose you had to classify a blog > tool, say 5 years ago. What category would you have put it then? > Is slashdot a blog or a news agregator? Who knows? This strikes me two ways: One, that the examples you give are examples of applications, not of library routines. Modules == library routines, syntax, hooks, etc. Most larger applications will have modules, of course, but that's separate -- those modules would be part of the app, not part of a library. The second way this strikes me is that many guile programmers want flat hierarchies. Your statement has been echoed quite a bit in the past. At the risk of resurrecting horses only to beat them yet again, I'd make some assertions: 1) There is a place for hierarchy in modules. I take as evidence: (a) Packages can have pieces. In my case, I built a texinfo processing framework. There's a parser, an html transformer, a plain-text transformer, etc etc etc. (texinfo-parse), (texinfo-to-html), etc are manifestly stupid names, and moreover hierarchy is encoded in their names already. (b) Routines might be small enough that they don't have a package identity. Most things in ice-9 are that way. Modules in ice-9 would benefit from some kind of classification. (Is this true?) 2) Deep taxonomic hierarchies are too rigid. Evidence again: (a) Hierarchy doesn't appear in python or perl modules, except in the case that all modules are part of the same package, or extend a common package. Same in C (flat library namespace), same in Debian (flat package namespace). If packages are classified, it's only for presentation and not in ways that matter. Corollary: taxonomic hierarchies in guile-lib as it stands indicate that it considers itself to be the package, and is thus not, in its current form, a suitable distribution mechanism for third-party code. (b) Classifications change. So, if guile-lib wants to be a distribution point (through a centralized mechanism or otherwise), it should adopt a flat module hierarchy. If, on the other hand, it views itself as a single package, then the answer is less clear. This case is closer to slib, whose documentation is ordered taxonomically, but whose require namespace is flat. I guess this really comes down to the question, "What is guile-lib?" Is it a distribution point, or is it an slib? (Although slib suffers a similar dilemma: a debugger, for example, surely has an identity as a package, not just some routines.) What is the virtue of another slib? Should guile-lib take things from slib, just because it's easier for guile (think modules, insulation against slib changes)? If it is in fact an slib, should it have a (lib ...) prefix, as would be suggested by the guile-lib name? Is it just another ice-9, but perhaps one whose development hasn't calcified? I've been a bit schitzophrenic about the answer to that question lately. In the end, guile-lib is what people make it, so input from all is welcome to make it a resource of maximum utility. I'm still ruminating my answer to that, perhaps more later in the week. Cheers, -- Andy Wingo _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user