From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2 Date: Tue, 1 Sep 2009 02:26:36 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1251786439 25662 80.91.229.12 (1 Sep 2009 06:27:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2009 06:27:19 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Sep 01 08:27:12 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MiMpg-0007u2-Uh for guile-devel@m.gmane.org; Tue, 01 Sep 2009 08:27:09 +0200 Original-Received: from localhost ([127.0.0.1]:57414 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiMpg-0008Mj-Al for guile-devel@m.gmane.org; Tue, 01 Sep 2009 02:27:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiMpN-0008Dy-ST for guile-devel@gnu.org; Tue, 01 Sep 2009 02:26:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiMpJ-0008BU-E5 for guile-devel@gnu.org; Tue, 01 Sep 2009 02:26:49 -0400 Original-Received: from [199.232.76.173] (port=55349 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiMpJ-0008BO-5X for guile-devel@gnu.org; Tue, 01 Sep 2009 02:26:45 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:64967 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MiMpB-0004Rb-99 for guile-devel@gnu.org; Tue, 01 Sep 2009 02:26:45 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n816Qaw6006352; Tue, 1 Sep 2009 02:26:36 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9230 Archived-At: On Sep 1, 2009, at 02:23, Ken Raeburn wrote: > I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as > needed, change == to scm_is_eq. The initializers make it slightly > less trivial, and I can imagine different courses of action. Okay, not quite so trivial as I blithely asserted. It looks like the eval code is going to be annoying too -- lots of case labels that are constructed by making SCM values and then extracting bits from them with ISYMNUM, which won't work with a union. I'm thinking, maybe an enum or list of macros to define the basic set of integers, and then apply SCM_MAKISYM to the enumerator values, and then we can refer to the values symbolically without extracting bits out of constructed SCM values? The smob creation macros play fast and loose with types, and accept anything that can be cast to scm_t_bits... which doesn't include union types like SCM in this mode; extracting values is similarly messy. I'm not sure that can be cleaned up without changing the API. There are also bits that I suspect won't build cleanly if SCM is an integer (STRICTNESS=0), too. Ken