From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Bruce Korb Newsgroups: gmane.lisp.guile.user Subject: Re: SCM_LENGTH ??? Date: Mon, 10 Jan 2005 10:03:10 -0800 Organization: Veritas Software Message-ID: <200501101003.10523.bkorb@veritas.com> References: <41DED481.AEF0CABB@veritas.com> Reply-To: bkorb@veritas.com NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1105380597 10420 80.91.229.6 (10 Jan 2005 18:09:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 10 Jan 2005 18:09:57 +0000 (UTC) Cc: guile-user@gnu.org, mckelvey@users.sourceforge.net Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jan 10 19:09:49 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Co3wX-0003Ur-00 for ; Mon, 10 Jan 2005 19:07:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Co482-0001vG-RU for guile-user@m.gmane.org; Mon, 10 Jan 2005 13:18:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Co47h-0001nT-GW for guile-user@gnu.org; Mon, 10 Jan 2005 13:18:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Co47f-0001mp-Fn for guile-user@gnu.org; Mon, 10 Jan 2005 13:18:35 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Co47f-0001m7-BB for guile-user@gnu.org; Mon, 10 Jan 2005 13:18:35 -0500 Original-Received: from [143.127.3.10] (helo=MTVMIME03.enterprise.veritas.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Co3sr-0005E6-12 for guile-user@gnu.org; Mon, 10 Jan 2005 13:03:17 -0500 Original-Received: from megami.veritas.com (unverified) by MTVMIME03.enterprise.veritas.com (Content Technologies SMTPRS 4.3.12) with SMTP id ; Mon, 10 Jan 2005 10:03:16 -0800 Original-Received: from [172.22.12.213]([172.22.12.213]) (4727 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Mon, 10 Jan 2005 10:03:11 -0800 (PST) (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30) Original-To: Marius Vollmer User-Agent: KMail/1.6.2 In-Reply-To: Content-Disposition: inline X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:4037 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4037 On Monday 10 January 2005 09:26 am, Marius Vollmer wrote: > The recommended way to check for deprecated features is to compile a > version of Guile with --disable-deprecated and compile/link/test > against that. That's a cute idea. I like it! I confess, I don't remember it from the last time I went through the Guile docs. When was that? '99 or '98? Have the docs changed much since then? ;-) > > I cannot control my clients. They will use whatever is installed. > > Which is not always going to work, period. Programs do have > reqirements that must be honored by the clients of these programs. > The less requirements there are, the better, but it is unrealistic to > aim for zero requirements. Requiring Guile 1.6 is very reasonable in > my view, especially since it is still maintained. Well, 1.4 is old enough that requiring something newer isn't a problem for me. > > They could (and do) still use 1.4. Are these scm_c_*_length functions > > available in 1.6 (let alone 1.4)? > > No. However, it is a bit premature to use scm_c_*_length functions since 1.7.x is a test release series and 1.8 is not available. :) Thank you for restoring the compatibility stuff! > >> This version is guaranteed to contain serious bugs, and the publically > >> visible interfaces will almost certainly change before 1.8 is > >> released. The 1.7 releases might be termed "selected snapshots". > > > > A disappearing interface is certainly a bug. > > No, if the interface itself is buggy, I'd say removing it is a > feature. :-) OK. A feature then. Whether a feature or a bug, it breaks my released software. :-( > > It is not possible to migrate released software. > > You are not supposed to. Just use 1.6 for the old releases and > require 1.8 for the new ones, if you see a benefit. 1.4 is adequate for my needs (though I agree it is old enough to not worry about anymore). So, I want to build to an interface that works for either 1.6 *or* 1.8 and I would really hope for binary compatibility between them as well. Once 1.6.x has been dormant for a couple of years, *then* one can stop fretting over clients still using the thing. > > Please ensure that *ALL* legacy interfaces are maintained. > > Unfortunately, the legacy interfaces of Guile are problematic. > Traditionally, Guile has exposed lots of its internal implementation > details (such as the fact that strings, symbols, and vectors stored > their length in the same way), and because of the lack of clean > alternatives and also lack of proper documentation, people have made > use of these internals in their programs. We try to slowly fix this > situation. To me, this still feels like grubbing around in internals and I do wish you all were willing to supply something that approximates it. I loathe having this in my code: SCM ag_scm_c_eval_string_from_file_line( const char* pzExpr, const char* pzFile, int line ) { SCM port; { static const char zEx[] = "eval-string-from-file-line"; SCM expr = scm_makfrom0str( pzExpr ); port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx ); } { SCM file = scm_makfrom0str( pzFile ); scm_t_port* pt = SCM_PTAB_ENTRY(port); pt->line_number = line - 1; pt->file_name = file; } { SCM ans = SCM_UNSPECIFIED; /* Read expressions from that port; ignore the values. */ for (;;) { SCM form = scm_read( port ); if (SCM_EOF_OBJECT_P( form )) break; ans = scm_primitive_eval_x( form ); } return ans; } } > So, SCM_LENGTH is definitely deprecated and you need to stop using it > eventually. The alternatives are hopefully much better and will stay > around much longer. Excellent. Thank you. Regards, Bruce _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user