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: The relationship between SCM and scm_t_bits. Date: Mon, 09 Aug 2004 23:09:01 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87zn54yq6q.fsf@zagadka.ping.de> References: <40A6307C.9050809@dirk-herrmanns-seiten.de> <871xliq2p0.fsf@zagadka.ping.de> <40AE5A80.9050809@dirk-herrmanns-seiten.de> <40AEF7B3.2020707@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1092085834 22214 80.91.224.253 (9 Aug 2004 21:10:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 9 Aug 2004 21:10:34 +0000 (UTC) Cc: Paul Jarc , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Aug 09 23:10:19 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BuHPP-0006FB-00 for ; Mon, 09 Aug 2004 23:10:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BuHTA-0002LB-67 for guile-devel@m.gmane.org; Mon, 09 Aug 2004 17:14:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BuHSe-0002AI-AG for guile-devel@gnu.org; Mon, 09 Aug 2004 17:13:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BuHSc-00029P-8J for guile-devel@gnu.org; Mon, 09 Aug 2004 17:13:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BuHSc-00028n-2Y for guile-devel@gnu.org; Mon, 09 Aug 2004 17:13:38 -0400 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BuHOE-00036u-Uq for guile-devel@gnu.org; Mon, 09 Aug 2004 17:09:07 -0400 Original-Received: from [195.138.45.200] (helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 4.34) id 1BuHOD-0001qo-RB for guile-devel@gnu.org; Mon, 09 Aug 2004 23:09:06 +0200 Original-Received: (qmail 6783 invoked by uid 1000); 9 Aug 2004 21:09:01 -0000 Original-To: Dirk Herrmann In-Reply-To: <40AEF7B3.2020707@dirk-herrmanns-seiten.de> (Dirk Herrmann's message of "Sat, 22 May 2004 08:48:19 +0200") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3925 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3925 Dirk Herrmann writes: > Certainly, the way we convert between scm_t_bits and SCM is > implementation dependent. However, the definitions for scm_t_bits > and SCM are IMO a very good way to provide an abstraction of some of > this uncleanlyness. And, with today's definitions of scm_t_bits and > SCM, the heap _must_ hold scm_t_bits variables. Please explain, why > you think that it is cleaner to say it only holds scheme objects if > in fact it does not. The reason is that there exits code that does essentially this: scm_t_bits heap_field; SCM value = whatever (); SCM *ptr = (SCM *)&heap_field; *ptr = value; This is quite unclean. This variant is cleaner and standards conformant: SCM heap_field; SCM value = whatever (); SCM *ptr = &heap_field; *ptr = value; > What is the reason to change a paradigm, which has for several years > worked quite nicely, is easily understood, and has helped to find > and probably also to avoid a bunch of errors? I don't think that the paradigm has changed fundamentally. It has been strengthened, if you will. The distinction between scm_t_bits and SCM is still there. We don't just cast between SCM and scm_t_bits, we use SCM_PACK and SCM_UNPACK. Except sometimes a scm_t_bits variable is stored into via a SCM* pointer, totally ruining the care PACk/UNPACK abstraction. That exception has now been removed. I see that as an unconditional improvement, don't you? -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel