From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dale Mellor Newsgroups: gmane.lisp.guile.user Subject: Re: First look at Guile Std Library available Date: Mon, 5 Jan 2004 11:08:21 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <16377.14229.639335.624191@l.a> 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> <3FF88AD5.6010701@vzavenue.net> <87isjr1bkb.fsf@alice.rotty.yi.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1073298047 32354 80.91.224.253 (5 Jan 2004 10:20:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2004 10:20:47 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jan 05 11:20:44 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 1AdRql-0003kF-00 for ; Mon, 05 Jan 2004 11:20:43 +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 1AdSic-00053r-R6 for guile-user@m.gmane.org; Mon, 05 Jan 2004 06:16:22 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AdSfO-0003Hr-0O for guile-user@gnu.org; Mon, 05 Jan 2004 06:13:02 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AdSeY-0001zL-8M for guile-user@gnu.org; Mon, 05 Jan 2004 06:12:44 -0500 Original-Received: from [213.73.176.162] (helo=ldm.a) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AdScN-0008GY-F8 for guile-user@gnu.org; Mon, 05 Jan 2004 06:09:55 -0500 Original-Received: from ldm.a (localhost.0.0.127.in-addr.arpa [127.0.0.1] (may be forged)) by ldm.a (8.12.5/8.12.5) with ESMTP id i05A8MdQ013248 for ; Mon, 5 Jan 2004 11:08:22 +0100 Original-Received: (from hydro23@localhost) by ldm.a (8.12.5/8.12.5/Submit) id i05A8Mom013245; Mon, 5 Jan 2004 11:08:22 +0100 X-Authentication-Warning: ldm.a: hydro23 set sender to Dale Mellor using -f Original-To: guile-user@gnu.org In-Reply-To: <87isjr1bkb.fsf@alice.rotty.yi.org> X-Mailer: VM 7.14 under Emacs 21.3.1 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:2526 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2526 >>>>> "Andreas" == Andreas Rottmann writes: Andreas> Richard Todd writes: >> What do you think of (std ...) => (std2 ...) as a means of letting older >> code run forever? I've read c++ is considering this approach. I don't >> think it should happen but every 5 years or so, and only then if >> backwards compatibility has become a burden. >> Andreas> Hmm, I always kind of disliked that approach. Andreas> 1) It's probably very hard for a standard library (which presumably Andreas> consists of lots of modules) to stay API-compatible over an longer Andreas> period of time. Consider the GNOME project -- they have the concept Andreas> of the "GNOME developer platform", which will, given a constant Andreas> *minor* release number stay API compatible, but may (and mostly Andreas> will) break API every minor release number change, which happens Andreas> about every six months. There is a big difference between the Guile stdlib and GNOME. GNOME is a tight-knit community of advanced developers (for the most part, anyway), whereas the Guile lib has to appeal to and be used by complete novices (people who only pick the language up because it is used in the configuration of another program, for example). The Guile lib is much more like C++ STL than libgnome. It has to set the standard for people to use, and keep it. You cannot expect every developer of a Guile script to keep step with API changes. Breaking API every six months is, simply, not acceptable for the Guile lib. Andreas> 2) Presumed the need for API-breaking changes are needed, in turn Andreas> not to hinder development of the library itself, in intervals quite Andreas> smaller than 5 years, it would be more of a annoyance to developers Andreas> regularly adapting to the API changes (which indeed should only be Andreas> "major" in the sense that they require a lot of adaption to Andreas> existing code accross major version changes) to require changing Andreas> all their code to use stdY instead of stdX. They don't have to change all of their code to stdY if stdX remains available. >> I'm a little disappointed that all the response I've gotten has been >> about the library concept, and no one has yet appeared to be interested >> in the code I've put out there to date. Do you like it? Hate it? Don't >> care about it? Can it be that only Java/Python/Perl/Ruby need logging >> services, and scheme does not? >> Andreas> I just skimmed a bit over your code, and it seems quite OK. A few Andreas> bits I've noticed: I'm sorry I'm making blind comments without yet having looked at your code. I keep meaning to do it but am having difficulty making the space. However, I think the question of the approach to design is much more important right now than the implementation details. Dale _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user