From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Steve Tell Newsgroups: gmane.lisp.guile.user Subject: Re: 1.5.6: (bound? ) missing from optargs.scm Date: Fri, 29 Mar 2002 21:26:45 -0500 (EST) Sender: guile-user-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1017455283 18740 127.0.0.1 (30 Mar 2002 02:28:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 30 Mar 2002 02:28:03 +0000 (UTC) Cc: 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 16r8b4-0004s9-00 for ; Sat, 30 Mar 2002 03:28:03 +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 16r8aA-0003NT-00; Fri, 29 Mar 2002 21:27:06 -0500 Original-Received: from dsl092-218-026.nyc1.dsl.speakeasy.net ([66.92.218.26] helo=telltronics.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16r8Zz-0003KO-00 for ; Fri, 29 Mar 2002 21:26:56 -0500 Original-Received: from localhost (tell@localhost) by telltronics.org (8.9.3/8.9.3) with ESMTP id VAA18803; Fri, 29 Mar 2002 21:26:46 -0500 X-Sender: tell@ariel.lan.telltronics.org Original-To: ttn@glug.org In-Reply-To: Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.8 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:76 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:76 On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote: > using some other out-of-band object is possible. (we can bring `bound?' > back. we just need to finish this iso-API change in the right way, or > justify in NEWS the new API.) So, might it be back for 1.6? I've got some other code that uses optargs and bound. Maybe I'll just leave that on 1.4 and wait and see. OTOH, I'd like to be able to play with goops. > wrt other woes, when i took guile-snarf off of noinst_ i did not take > advantage of the dist-hook to modify already-distributed guile-snarf to > emit warnings when run, even though i thought about it. my bad. I'm glad you didn't - that would be rather antisocial (cf. discussion on peaceful coexistance of multiple versions) > the story is that what we discussed and i implemented, mvo munged so > that SCM_MAGIC_SNARFER is now exposed/required/forgotten/fubared and > documented. from no design to bad design, IMO. Curious, what would you do differently if redesigning? Now that its official that every application has to implement its own snarfing system (or go back to manual construction of the init functions), there's plenty of room for experimentation with alternate mechanisms. It actually didn't take very much effort to disentangle my code from its mismash of snarfing macros (a mix of 1.4 and stuff borrowed from the late scwm), so I'm not annoyed. I would like to get back to coding new stuff of my own and off of compatibility-testing though. > some upgrade policies have proven difficult to foresee by guile > maintainers. maybe someone will fork guile and merge it w/ chicken. > (this is how you trick distributors into upgrading. ;-) I get the sense that one only gets to break binary compatibility every few years, so there's a strong need to make it count when it does become necessary. Some day soon, one supposes that for example RedHat will decide whether its 1.4[.1] or 1.6 that goes into their 8.x series. Presumably other distributor make the same call on their own schedules. I hope I'm helping make 1.6 more likely to be what gets widespread distribution for two years after that by porting to and testing the 1.5.x ones and asking all these questions. Steve _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user