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: Tue, 04 May 2004 15:53:23 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083679634 5267 80.91.224.253 (4 May 2004 14:07:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 14:07:14 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue May 04 16:06:52 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BL0ZP-0007lr-00 for ; Tue, 04 May 2004 16:06:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BL0Y7-0004I4-A5 for guile-devel@m.gmane.org; Tue, 04 May 2004 10:05:31 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BL0XK-000401-NX for guile-devel@gnu.org; Tue, 04 May 2004 10:04:42 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BL0Wl-0003jk-NO for guile-devel@gnu.org; Tue, 04 May 2004 10:04:38 -0400 Original-Received: from [129.217.163.1] (helo=mail.dt.e-technik.uni-dortmund.de) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BL0Mc-0000oH-Pn for guile-devel@gnu.org; Tue, 04 May 2004 09:53:39 -0400 Original-Received: from troy.dt.e-technik.uni-dortmund.de (troy.dt.e-technik.uni-dortmund.de [129.217.163.17]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 2EA392AE53 for ; Tue, 4 May 2004 15:53:25 +0200 (CEST) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id 59E93B982; Tue, 4 May 2004 15:53:23 +0200 (CEST) Original-To: guile-devel@gnu.org In-Reply-To: (Marius Vollmer's message of "Mon, 03 May 2004 17:06:20 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.4 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:3667 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3667 Marius Vollmer writes: > Hi, > > I just got confused about our two 'fundamental' types, SCM and > scm_t_bits. [More random thoughts follow...] Right now, the documented distinction between scm_t_bits and SCM is that... A variable of type `SCM' is guaranteed to hold a valid Scheme object. A variable of type `scm_t_bits', on the other hand, may hold a representation of a `SCM' value as a C integral type, but may also hold any C value, even if it does not correspond to a valid Scheme object. This is a useful distinction, no doubt. However, it creates the situation where user variables have a different type as the cell slots in the heap. Now, the distinction between scm_t_bits and SCM is only then practical when converting between them has zero cost. SCM_PACK and SCM_UNPACK can really only be casts that reinterpret the bits. If this would not be the case, we would have to remove the distinction to get performance back. Thus, scm_t_bits and SCM can be pretty much identical and we can allow the casting of pointers to them, too. Better yet, we provide some markup that does the casting for the user. That is, I now propose to _add_ SCM_CELL_OBJECT_LOC and to _keep_ SCM_CELL_WORD_LOC. That way, we take over responsibility for getting the casting right. Still, I'd want to change the type of fields in the heap from scm_t_bits to SCM, just so that pointers to SCM are guaranteed to work across the heap and user variables. Pointers to scm_t_bits might still fail on strange platforms and we might then consider removing SCM_CELL_WORD_LOC on those platforms. Of course, this whole tedious ponderings can be avoided, as Paul points out, by just disallowing pointers to SCM or to scm_t_bits entirely. But we would need a very good reason for this: using pointers the way delete_some does is completely reasonable right now. One reason to disallow pointers would be that a precise garbage collector that moves objects around can not easily deal with random pointers into the middle of objects. However, that's only a theoretical reason, I don't see getting there any time soon, if at all. So, unless a very good reason comes up, I want to allow pointers to SCM. > For example, consider a list that is pointed to by a global variable > and some fairly standard way of dealing with singly-linked lists in C: > > SCM head; > > void > delete_some () > { > SCM *node_ptr = &head; > if (should_delete (*node_ptr)) > *node_ptr = SCM_CDR (*node_ptr); > else > node_ptr = SCM_CDRLOC (*node_ptr); > } [There should be a loop in that function of course. ] _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel