From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: rm@fabula.de Newsgroups: gmane.lisp.guile.user Subject: Re: My Guile Wishlist Date: Wed, 20 Mar 2002 14:18:01 +0100 Sender: guile-user-admin@gnu.org Message-ID: <20020320131801.GC3905@www> References: <873cyx4j8i.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016666327 17504 127.0.0.1 (20 Mar 2002 23:18:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 20 Mar 2002 23:18:47 +0000 (UTC) Cc: Evan Prodromou , guile-user@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16npLy-0004Y6-00 for ; Thu, 21 Mar 2002 00:18:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16npGL-0007SN-00; Wed, 20 Mar 2002 18:12:57 -0500 Original-Received: from delysid.gnu.org ([158.121.106.20]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16noXz-0008Fu-00 for ; Wed, 20 Mar 2002 17:27:08 -0500 Original-Received: from www.elogos.de ([212.18.192.92]) by delysid.gnu.org with smtp (Exim 3.34 #2) id 16nfxW-0005Lj-00 for ; Wed, 20 Mar 2002 08:16:55 -0500 Original-Received: by www.elogos.de (Postfix, from userid 5001) id 34DB31049A3; Wed, 20 Mar 2002 14:18:01 +0100 (CET) Original-To: Neil Jerram Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:41 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:41 On Tue, Mar 19, 2002 at 08:14:45PM +0000, Neil Jerram wrote: > ... > Take, for example, the module system, obarrays and so on (vcells, > variables, builtin bindings ...). > > On the one hand, these related areas have been dramatically simplified > since 1.4, in pursuit of the goal that there should be one simple, > easy to understand way of doing things. > > On the other hand, this has left us with a problem as regards > documenting what's changed clearly enough for people using the old C > interface. Thanks, this expresses very well my recent feelings about the upcoming changes. Even so i'm lurking on guile-user as well as guile-developer it sometimes took me hours (if not days :-) to adapt existing (C-) code to the CVS guile. I can well imagine that application developers that spent more time on their apps and less on the guile mailing lists will cry out in horror when confronted with these rather dramatic changes. As a test case, try porting SCWM (currently in stable Debian) to the new guile ... A few observations: - many changes are just "cosmetic". Renames of typedefs/functions etc. can be softened by the use of a comaptibility header that gets included in all files. [1] [2] - Given the neccesary information most changes are rather trivial. The sometimes frustrating part is the 'compile-and-see-what-disapeared' cycles. Maybe some authomatic code scanner could help here. I started to use 'rats' (http://www.securesw.com/rats/) for this task, unfortu- nately i currently don't have enough time nore insight to create the full database of changes (rats uses a xml based database file that optionaly can include tips and background information. I'm pretty shure that such a database could be maintained as an online resurce. Thinking of it: i could probably provide the online space and set up a web interface if someone wants to help with the actual content). Ralf Mattes [1] It would be helpfull to include suggestions on how to replace deprecated defines/functions into the NEWS or ChangeLog files. [2] It's rather irritating if newly introduced functions use deprecated symbols (file NEWS, line 981: ** New function: scm_c_read (SCM port, void *buffer, scm_sizet size) > In other words, we have to start from where we are, and the biggest > brake on us trying to reach One Good Way To Do Things is the need to > provide backwards compatibility and to explain changes, and the > limitations of the tools we have available to help us do that. > > Neil > > > _______________________________________________ > Guile-user mailing list > Guile-user@gnu.org > http://mail.gnu.org/mailman/listinfo/guile-user _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user