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, 17 May 2004 20:09:32 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87n047orhf.fsf@zagadka.ping.de> References: <40A5C768.5030603@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 1084826733 17735 80.91.224.253 (17 May 2004 20:45:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 May 2004 20:45:33 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 17 22:45:23 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 1BPozD-0004rM-00 for ; Mon, 17 May 2004 22:45:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPokv-00021U-Gd for guile-devel@m.gmane.org; Mon, 17 May 2004 16:30:37 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BPoUr-0007HR-GV for guile-devel@gnu.org; Mon, 17 May 2004 16:14:01 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BPnJC-0001va-RI for guile-devel@gnu.org; Mon, 17 May 2004 14:58:26 -0400 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPmYU-0001b0-W4 for guile-devel@gnu.org; Mon, 17 May 2004 14:09:39 -0400 Original-Received: from dialin.speedway45.dip121.dokom.de ([195.138.45.121] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1BPmbC-0004aR-00 for guile-devel@gnu.org; Mon, 17 May 2004 20:12:26 +0200 Original-Received: (qmail 7147 invoked by uid 1000); 17 May 2004 18:09:32 -0000 Original-To: Dirk Herrmann In-Reply-To: <40A5C768.5030603@dirk-herrmanns-seiten.de> (Dirk Herrmann's message of "Sat, 15 May 2004 09:31:52 +0200") User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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:3729 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3729 Dirk Herrmann writes: > Marius Vollmer wrote: > >>Hi, >> >>I just got confused about our two 'fundamental' types, SCM and >>scm_t_bits. >> > The two types were introduced in order to create a level of > abstraction between code, that operates on the encoding of scheme > types, and code that only requires on API elements to do so. > [...] Yep, thanks for reinforcing this. The purpose of scm_t_bits as it is currenly documented in the manual is different, however: it is the type that can hold arbitrary words, not just valid SCM values. The first word of a smob would be a scm_t_bits since it is not a valid SCM value, for example. I was confused by these two distinctions between the two types. >>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); >> } >> > Such code should be avoided. [...] Yes, probably. But we currently support this style and Guile uses it itself. However, the way we were casting pointers around did not properly respect the disctinction between SCM and scm_t_bits: we didn't make the guarantee that you could meaningfully cast a scm_t_bits* to a SCM*, yet we would rely on it. Instead of disallowing working with SCM* pointers, I have fixed the type confusion. This was the smaller change by far. But of course, this does not mean that we can not at one time disallow the use of SCM* pointers. But that would be a much bigger decision than I would want to make now, while (slowly) zooming in on 1.8. > By modifying SCM values through SCM pointers you skip the write > barrier. When switching to generational GC, such code would have to > be fixed, either to avoid using the pointer access, or to add some > operations that perform, what the write barrier would have > done. Thus, in order to keep the number of places small which > require such fixing later, I try to avoid using SCM_CDRLOC etc. Yes, I fully agree here. -- 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