From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.user Subject: Re: 1.5.6: (bound? ) missing from optargs.scm Date: Fri, 29 Mar 2002 20:42:10 -0800 Sender: guile-user-admin@gnu.org Message-ID: References: Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1017463559 23471 127.0.0.1 (30 Mar 2002 04:45:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 30 Mar 2002 04:45:59 +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 16rAkZ-00066S-00 for ; Sat, 30 Mar 2002 05:45:59 +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 16rAjj-00039r-00; Fri, 29 Mar 2002 23:45:07 -0500 Original-Received: from ca-crlsbd-u4-c4c-174.crlsca.adelphia.net ([68.66.186.174] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16rAjI-00037K-00 for ; Fri, 29 Mar 2002 23:44:40 -0500 Original-Received: from ttn by giblet with local (Exim 3.33 #1 (Debian)) id 16rAgs-0001zA-00; Fri, 29 Mar 2002 20:42:10 -0800 Original-To: tell@telltronics.org 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:77 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:77 From: Steve Tell Date: Fri, 29 Mar 2002 21:26:45 -0500 (EST) 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. if it is to come back it has to be for 1.6 in order to sustain the illusion of not leaving in the first place. the alternative is to justify the API change and then possibly justify its re-addition later, all in addition to retooling client code, which is more messy. currently i'm looking at 1.4.1 issues (getting closer), and i suppose this could fall under the broader question of how/when/why to remove things. somewhat related, my impression is that guile maintainers found a toy (deprecation) and went a little crazy w/ it (because virtualizing interfaces is fun, admittedly). unfortunately, the implication of deprecation is removal at some point, and this requires planning that was not done. dropping `bound?' evokes the same disturbing feeling. so yeah, it's likely i will spot-fix this (maybe this weekend) in the process of getting a handle on 1.4 - 1.6 API changes generally. since this particular fix is small, a patch would be most gratefully received and likely immediately applied (proabably no paperwork required). Curious, what would you do differently if redesigning? well, i would hide SCM_MAGIC_SNARFER and require output file to be specified, omitting guile-snarf writing to stdout in favor of it being able to manage zonking the output file should the cpp fail in some way (model after "gcc -o"). indeed, this is what i did before the work was clobbered by foolish consistency w/ the mal-published past. the macros and what not are fine, IMHO. i'm just grousing because i find it unpleasant to work w/ coding cowboys (yes mvo that's you) who break things gratuitously and leave the pieces for others to clean up, all the while wondering what the big deal is all about. the big deal is all about time and how precious it, wasted by thoughtlessness like this. gak, i'm so worked up right now. 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. you mean like comment snarfing (a la doxygen and javadoc)? this is a pretty well trodden path it seems. 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. you and me both! 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 suppose we should do some research to see what kind of criteria they use to determine upgrade yes/no. in the ideal scenario this wouldn't be far from our own plans. 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. this is very helpful; thanks! (and mvo still has a place in my heart.) brookes' mythical man month points out that coherent vision is necessary for a project's success. for collaborative free software efforts, such a vision must necessarily be shared between both users and programmers, and the only way this happens is w/ incisive questions back and forth. as for longevity of 1.6, i'm still trying to figure that out. if 1.6 is released like 1.4, we can expect more pain. (or maybe someone will fork guile and merge it w/ chicken, any takers? :-) thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user