From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user Subject: Re: 1.5.6: (bound? ) missing from optargs.scm Date: 01 Apr 2002 00:46:56 +0200 Sender: guile-user-admin@gnu.org Message-ID: <87g02gpd7j.fsf@zagadka.ping.de> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1017615700 7626 127.0.0.1 (31 Mar 2002 23:01:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 31 Mar 2002 23:01:40 +0000 (UTC) Cc: ttn@glug.org, 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 16roKR-0001yt-00 for ; Mon, 01 Apr 2002 01:01:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16ro4a-0007HG-00; Sun, 31 Mar 2002 17:45:16 -0500 Original-Received: from dialin.speedway42.dip227.dokom.de ([195.138.42.227] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16ro3b-00076Z-00 for ; Sun, 31 Mar 2002 17:44:15 -0500 Original-Received: (qmail 10200 invoked by uid 1000); 31 Mar 2002 22:46:56 -0000 Original-To: Steve Tell In-Reply-To: Original-Lines: 75 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 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:90 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:90 Steve Tell writes: > 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? Hmm, yes. I removed 'bound?' and related code in 'let-o-k-template' since we can not reveal the SCM_UNDEFINED value to Scheme code. This was a bug and needed to be solved. The 'bound?' functionality itself is not problematic (although not really critical as one can emulate it easily with default-values, as you point out) and we can bring it back. Thien-Thi is right that the removing was done without much planning or work on the real fix, i.e. a 'bound?' that doesn't use the magic SCM_UNDEFINED value. 'bound?' would switch from being a macro to being a function. Would that cause any problems? I have recorded this issue as bug 'optargs-bound-gone'. (Please also see the upcoming announcement of the newish bug data base.) > > 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) You can't have two versions of Guile on your system _for_compiling_programs_with_ anyway. You can run programs that are linked to different versions of libguile (with the same installation prefix), but you can't install two sets of header files (with the same installation prefix). Leaving a guile-snarf around that does not correspond to the installed header files will only cover up bugs. I think you figured this out yourself, right? > [...] Now that its official that every application has to implement > its own snarfing system guile-snarf will be back for 1.6. > (or go back to manual construction of the init functions), there's > plenty of room for experimentation with alternate mechanisms. This room is still there, unless I'm missing something. You are not forced to use guile-snarf. If you find it inadequate, feel free to experiment with something else. > 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. In my happy ignorance of real world issues, I don't see why binary compatibility is a big deal. It's an annoying artifact of the usual implementations of the C programming language, but Unix systems seem to deal pretty well with it, anyway, wither by using static linking or versioned shared libraries. It has to catch up a bit when linking dynamically (i.e. via dlopen), but it is manageable. Source compatibility is much more important. Is there more to it? (Likely.) > 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. Thanks, that's really appreciated! _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user