From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.lisp.guile.devel Subject: Re: The relationship between SCM and scm_t_bits. Date: Tue, 04 May 2004 14:35:57 -0400 Organization: What did you have in mind? A short, blunt, human pyramid? 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 1083696315 17726 80.91.224.253 (4 May 2004 18:45:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 18:45:15 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue May 04 20:45:04 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 1BL4ue-0005pn-00 for ; Tue, 04 May 2004 20:45:04 +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 1BL4sM-0004KK-Mb for guile-devel@m.gmane.org; Tue, 04 May 2004 14:42:42 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BL4p3-00027R-OE for guile-devel@gnu.org; Tue, 04 May 2004 14:39:17 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BL4mm-0008VJ-Nv for guile-devel@gnu.org; Tue, 04 May 2004 14:37:27 -0400 Original-Received: from [129.22.104.46] (helo=mirapoint1.tis.cwru.edu) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1BL4m2-0007jm-Nb for guile-devel@gnu.org; Tue, 04 May 2004 14:36:10 -0400 Original-Received: from multivac.cwru.edu (multivac.ITS.CWRU.Edu [129.22.114.26]) by mirapoint1.tis.cwru.edu (MOS 3.4.3-CR) with SMTP id BJW76724; Tue, 4 May 2004 14:35:58 -0400 (EDT) Original-Received: (qmail 16032 invoked by uid 500); 4 May 2004 18:36:20 -0000 Original-To: Marius Vollmer In-Reply-To: (Marius Vollmer's message of "Tue, 04 May 2004 19:49:46 +0200") Mail-Copies-To: nobody Mail-Followup-To: Marius Vollmer , guile-devel@gnu.org Original-Lines: 58 User-Agent: Gnus/5.110002 (No Gnus v0.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:3670 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3670 Marius Vollmer wrote: > SCM_DEBUG_TYPING_STRICTNESS == 2 is not meant for production code (I > have to review it anyway, there has been a bug report about it not > working at all, I think), so when compiling with that setting, the > performance argument doesn't count. What I'm saying is that (ISTM) we might be able to get maximum type-safety and still have zero run-time conversion cost. Isn't that the ideal? But actually, SCM_DEBUG_TYPING_STRICTNESS == 1 looks like it's just as safe as 2 anyway. (I think it would be nice to have SCM_UNPACK type-check its argument as SCM_PACK does; let the caller explicitly cast to scm_t_bits to silence the warning.) > A given location is always only accessed as one type. If that's true, then a union containing SCM and scm_t_bits would give us standard-conformance. > We already aim to be -fstrict-aliasing safe Ok, good. >> What do we gain here over your previous use-SCM-everywhere >> suggestion? > > We would have to remove SCM_CELL_WORD_LOC from the API. Is there much code outside of Guile itself using that? I guess Guile itself will always need something like scm_t_bits to check type tags, but I wonder how useful WORD_LOC is for other code. > When we can only have one type of pointer (either SCM* and > scm_t_bits*), I would want to have pointers to SCM since SCM is the > type that the users works with. That would mean that heap words are > of type SCM. I agree. > That then also means that SCM_PACK would be used to store 'invalid' > values into a SCM and can no longer be used to mark places where only > valid SCM values should appear. Maybe we should have a new > SCM_PACK_BITS for this, or maybe not. SCM_MAKINUM? :) Or do we need the full range? More precisely, do we need the full range and zero-cost conversion simultaneously? Even more precisely, do we need that in the API, for code outside of Guile itself? > My instincts tell me to just remove scm_t_bits from the public API > completely, but that is rather drastic, maybe for 1.10... Yes, if it's to be done, there should certinaly be a significant deprecation period to give people time to adapt. paul _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel