From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: [BDW-GC] Static allocation of subrs Date: Tue, 03 Feb 2009 20:13:36 +0000 Message-ID: <87k587jn2n.fsf@arudy.ossau.uklinux.net> References: <87vdrv179q.fsf@gnu.org> <87wsc8jys1.fsf@arudy.ossau.uklinux.net> <87iqnsbeao.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1233693357 6866 80.91.229.12 (3 Feb 2009 20:35:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Feb 2009 20:35:57 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 03 21:37: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 1LUS0v-0002gA-5p for guile-devel@m.gmane.org; Tue, 03 Feb 2009 21:36:57 +0100 Original-Received: from localhost ([127.0.0.1]:39774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LURzb-0002nv-UI for guile-devel@m.gmane.org; Tue, 03 Feb 2009 15:35:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUReR-0001My-Cf for guile-devel@gnu.org; Tue, 03 Feb 2009 15:13:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUReQ-0001Lj-7U for guile-devel@gnu.org; Tue, 03 Feb 2009 15:13:42 -0500 Original-Received: from [199.232.76.173] (port=50158 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUReP-0001LS-Rn for guile-devel@gnu.org; Tue, 03 Feb 2009 15:13:41 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]:50249) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUReN-0000JR-2P; Tue, 03 Feb 2009 15:13:39 -0500 Original-Received: from arudy (host86-157-180-39.range86-157.btcentralplus.com [86.157.180.39]) by mail3.uklinux.net (Postfix) with ESMTP id BD29D1F6A36; Tue, 3 Feb 2009 20:13:37 +0000 (GMT) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id E8DE238012; Tue, 3 Feb 2009 20:13:36 +0000 (GMT) In-Reply-To: <87iqnsbeao.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Tue\, 03 Feb 2009 00\:38\:07 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:8123 Archived-At: ludo@gnu.org (Ludovic Court=E8s) writes: >> Presumably that is in practice almost all of the primitives, though? > > That's 200 gsubrs, vs. 873 "simple" subrs. Thanks, interesting. That's more gsubrs than I expected. >> Not so bad, IMO. > > It breaks cases like primitive procedures with more than 16 arguments > (because I arbitrarily decided that `snarf-gsubr.h' would contain > definitions up to 16 req/opt args), and situations like: > > SCM_DEFINE (scm_foo, "foo", 0001, 0002, 0003, ...) > > This is probably acceptable in practice. Agreed. (In future maybe we might stop relying only on the C preprocessor for snarfing.) >> This part is quite dirty, as you say. I'm not sure what's the >> advantage of the generation at make time. Wouldn't it be simpler, and >> have the same function, just to hardcode all these definitions >> directly in snarf.h? > > Given the size of `snarf-gsubr.h' (there are 16 * 16 * 2 =3D 512 > combinations), I'd rather keep it separated. The makefile rule is an > efficient way to compress it. ;-) OK. In that case, can you add a comment in the Makefile.am to say this? Simply to avoid someone wondering in future if there is some other reason why the code is auto-generated. >> I see there's no NEWS in the commit; is that because there's no impact >> on the API? Even if so, I imagine it might merit a line in the 2.0 >> release notes. If you agree, I'd encourage you to write the NEWS now, >> rather than adding it later. > > Right. It's just that I have not maintained any NEWS file for > BDW-GC-related changes, initially. I guess it's OK to add the NEWS later when this is merged; probably your memory is better than mine! >> Why does the macro code sometimes use scm_i_paste, and sometimes ## >> directly? > > The `scm_i_paste ()' macro is needed so that macro-expansion of > definitions like those of `srfi-4.i.c' work as expected. There are a > few cases where it isn't used (e.g., in `SCM_IMMUTABLE_DOUBLE_CELL ()'), > but I guess it didn't cause any problem because `scm_i_paste ()' was > properly used by callers. We could unify that but `scm_i_paste ()' has > the drawback of having a long name. Ah, OK. Thanks for explaining. >> Finally SCM_SUBR_ARITY_TO_TYPE... The implementation feels a bit >> messy, but I don't have any alternative to suggest, so I guess that's >> OK. > > The problem is that this information is shared among 3 places: > `SCM_SUBR_ARITY_TO_TYPE ()', `create_gsubr ()', and > `SCM_DEFINE_SUBR_reqX_optY_rstZ ()'. Ideally, all 3 would be generated > from a single source. > > Besides, I think we need to review the use of subr/gsubr tag in detail > to see whether we can make better use of them. OK. Nothing more needed straightaway, then. >> But what about the fact that it's added to the libguile API? I >> realize that this is necessary to some extent so that snarf.h can be >> used by application code - but can we somehow restrict >> SCM_SUBR_ARITY_TO_TYPE to being used in that context, so that it >> doesn't become on ongoing constraint for us? > > I share your concern, but I have no idea of how to avoid it. We could > add `_I_' in its name, perhaps. Hopefully, it's too low-level for > anyone to try it. I don't have an idea either. I think having _I_ would be good, though. Regards, Neil