From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: thoughts on top-level and cross-module inlining Date: Thu, 14 Apr 2016 15:49:43 +0200 Message-ID: <87lh4gb8qw.fsf@gnu.org> References: <87pouvl83z.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1460641829 4607 80.91.229.3 (14 Apr 2016 13:50:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 13:50:29 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Apr 14 15:50:24 2016 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aqhf5-0007hx-Pa for guile-devel@m.gmane.org; Thu, 14 Apr 2016 15:50:23 +0200 Original-Received: from localhost ([::1]:39719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqhf4-0005TB-RX for guile-devel@m.gmane.org; Thu, 14 Apr 2016 09:50:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqheZ-0004XG-2Y for guile-devel@gnu.org; Thu, 14 Apr 2016 09:49:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqheU-00040Z-A5 for guile-devel@gnu.org; Thu, 14 Apr 2016 09:49:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqheU-00040V-6c; Thu, 14 Apr 2016 09:49:46 -0400 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:59944 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aqheT-0001vN-L7; Thu, 14 Apr 2016 09:49:45 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 26 Germinal an 224 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x3D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87pouvl83z.fsf@pobox.com> (Andy Wingo's message of "Tue, 15 Mar 2016 22:54:56 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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 Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18283 Archived-At: Hello! :-) Andy Wingo skribis: > So, we have two questions, then: firstly, what semantic change can we > make to the language to permit top-level and cross-module inlining? > Secondly, how do we implement it? As I view it, the first step would be to allow intra-module inlining (inlining of unassigned private top-level bindings within the module.) It seems to me that this would have little impact on semantics; there is still the occasional, but not so rare, uses of @@ to bypass module boundaries that we want to allow, though. IMO a guiding principle should be that top-level inlining can always be disabled. This =E2=80=9Cbackdoor=E2=80=9D as you write is important for ma= ny current uses (Geiser, monkey-patching of third-party modules, etc.) > On the semantic side, I propose to add a field in modules indicating > whether the module permits its top-level references to be inlined. That sounds like a good idea for cross-module inlining! I wonder if a separate way to annotate candidates to intra-module (but not necessarily cross-module) inlining would be needed. Maybe something like the =E2=80=98declare=E2=80=99 forms found in CL and in some Schemes? > Let us assume that assigned bindings are not available for inlining, but > that declarative bindings can be inlined. Then, a program with inlining > will be the same as a program without inlining if declarative bindings > are never assigned from outside their compilation unit. That is what is > meant by "used conventionally", and I think it reflects standard Guile > usage, especially where modules are mostly compiled entirely within one > compilation unit. > > (We should make an enhancement to the compiler to emit a warning when a > declarative binding is used unconventionally. Perhaps we should emit a > warning whenever an imported binding is "set!", perhaps with a view > towards enforcing conventional usage; but I don't know, we always want > to have a back-door I think to allow Guile hackers to heal broken > programs while they are running.) I think we want to preserve the ability to =E2=80=98set!=E2=80=99 third-par= ty bindings, indeed, in those cases where that is considered more important than inlining. But I agree that being able to flag such unconventional usage with compiler warnings would be helpful. My 2=C2=A2, Ludo=E2=80=99.