From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Re-addition of deprecated stuff to 1.7. Date: 01 Jun 2003 20:27:45 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <878yslps9q.fsf@zagadka.ping.de> References: <87iss97ak0.fsf@zagadka.ping.de> <3EC67BA0.2C8FF637@veritas.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1054492331 20098 80.91.224.249 (1 Jun 2003 18:32:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2003 18:32:11 +0000 (UTC) Cc: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jun 01 20:32:09 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19MXcn-0005Do-00 for ; Sun, 01 Jun 2003 20:32:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MXdZ-0002Lj-Di for guile-devel@m.gmane.org; Sun, 01 Jun 2003 14:32:57 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MXdI-0002J6-J7 for guile-devel@gnu.org; Sun, 01 Jun 2003 14:32:40 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MXdG-0002IJ-Sf for guile-devel@gnu.org; Sun, 01 Jun 2003 14:32:39 -0400 Original-Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MXZU-00007v-Sn for guile-devel@gnu.org; Sun, 01 Jun 2003 14:28:45 -0400 Original-Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MXbM-0002ia-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 20:30:40 +0200 Original-Received: (qmail 10934 invoked by uid 1000); 1 Jun 2003 18:27:45 -0000 Original-To: Bruce Korb In-Reply-To: <3EC67BA0.2C8FF637@veritas.com> Original-Lines: 85 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Original-cc: guile-devel@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2462 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2462 Bruce Korb writes: > I'm going to guess here, so please correct me if I am wrong. I > think the client model you are operating with is that someone > develops some code and gets it running on their local system and > then they are happy campers. That is not what I am doing. I am > distributing my stuff to whomever and they will use whatever Guile > happens to be installed on their systems. Some of them are using > libguiles that are quite a few years old. I'd say it is a trade-off between how much pain you are willing to inflict upon your clients and how much pain you are willing to suffer yourself. I think (and hope) it is entirely tolerable to require you clients to install Guile 1.6 when they want to compile your code. They should not need to remove (the run-time parts of) Guile 1.4 for this; thus, software that uses Guile 1.4 will continue to run. Installing Guile 1.6 is no big deal, I hope. The alternative, making sure that your code works with both Guile 1.4 and Guile 1.6, is much more painful and moreover, it wont allow your code to cleanly take advantage of the 'new, improved' features of Guile 1.6. > May I please encourage you to supply configury stuff that is capable > of adapting current interfaces to old Guiles? Too much work for too little gain, I'd say. Instead, we should make it as easy as possible to install Guile 1.6 so that there is no reason not to have it on ones system. > For example, it would be _really_nice_ if it were to define a > scm2newstr_size_t. That way I would not be completely unbuildable > on I32LP64 platforms that still use "int" for the size argument. > Stuff like that would be Really Nice. Yep, that's a bug in Guile 1.6. We haven't been careful enough to keep the public API backwards compatible. For this specific bug, if you really need to work with both API versions, I think it is best to have a configure check in your package that detects what kind of gh_scm2newstr you are compiling against. These configure snippets might be collected in a central place, maybe, when people are willing to maintain such a thing. But given the above, I think it is OK to just fail and require Guile 1.6. > My desire is to use a small stable subset that won't vary very much. > Which is also why I selected the advertized- as-stable gh interface > for as much as possible. *sigh*. There are two reasons (at least) to want stability in an interface: one is that your code works unchanged with multiple versions/implementations of the other side of the API, another is that you don't want to do the work of tracking the changes in an API. In my opinion, the first reason is not very valid for Guile; there should be no reason to require some code to compile _unchanged_ against multiple versions of Guile. When there are such reasons, we should work to remove the reasons, not to make it easier to compile _unchanged_. Not the emphasis on _unchanged_. Not wanting to do much work when tracking API changes is a very good position to take. When changing the Guile API, we should make it in such a way that client code needs to change as little as possible. This often means that it doesn't need to change at all. However, it is not an unbreakable requirement that client code must continue to compile with all new versions of Guile. It is of course good practice to minimize the needed changes, and we probably have botched it a bit in the Guile 1.4 to Guile 1.6 transition. Client code might need to change more than in an ideal transition, but as I said, there should be no strong reasons not to make these changes. > P.S. If _anyone_ can show me how to set the string port file > name and line number, I *sure* would be a happy camper. I'm getting to that in a few minutes... :-) -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel