From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: Prevent inlining Date: Thu, 13 Feb 2020 08:36:04 +0100 Message-ID: References: <941ae97e-169a-4ab2-991f-f9ecf97e8845@www.fastmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001586c1059e70251c" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="118618"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Guile User , guile-devel To: =?UTF-8?Q?Linus_Bj=C3=B6rnstam?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Thu Feb 13 08:36:43 2020 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j293D-000UmG-Fg for guile-devel@m.gmane-mx.org; Thu, 13 Feb 2020 08:36:43 +0100 Original-Received: from localhost ([::1]:48308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j293C-0001Rg-2O for guile-devel@m.gmane-mx.org; Thu, 13 Feb 2020 02:36:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56366) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j292s-0001RX-BV for guile-devel@gnu.org; Thu, 13 Feb 2020 02:36:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j292q-0004z3-RF for guile-devel@gnu.org; Thu, 13 Feb 2020 02:36:22 -0500 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:45513) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j292q-0004yp-Ka; Thu, 13 Feb 2020 02:36:20 -0500 Original-Received: by mail-wr1-x42a.google.com with SMTP id g3so5336698wrs.12; Wed, 12 Feb 2020 23:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PKgUwRp6HCmIVcnq7v8RDmB35p5SWCiiyIEpvZO6pvI=; b=GsodxrjZSrF/xO4dKAl6n23xn4TgkE8iJ/5ApIQENErLLHqquAQA9TRMNKmRLTGI+c upTJAwkZ6SG1Fz0AkyGpiSj74MBLyfCL95iw7l1iEObicT/M3R/vDZ5lRWrJtX0erayE gNqFvWinQqInDPSBzI1zoBpAsUobVxNuDC1MSd8x4msgTJuN0PvQEmL81kbNjmecYogM 0YgOrJUpVFelyP4EVQNSlz+B+21K6KNVJAA5HJUSaz0COvOp7kF+Tr0WG/Mw99wYgSRz e0J6HUCnjvurOvkasanUTXU5ZbiGfDzOZ0+E1V4w9HB4GRvvTKIajb1+C28d+T9e//h/ Clpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PKgUwRp6HCmIVcnq7v8RDmB35p5SWCiiyIEpvZO6pvI=; b=dD/J7GB19a2s3cz+4Hs/x4b1fmiyHlP9WGw9gIU/9rT/HniXOcCNjWMQKbDmSL300g vcZ1Xtr0nwvlvjGmdXHGxbb1a1W29Qu3kBLIHVeNEw/0spRWgFPKmW5fe+7tRH4WeXYi +GP0rzcZFTwqgPzBrlugd0Yiz49Ycj5Zp2SELYrHQmkRiG+YHew+edYTEUElzKdJHhiP Q/2IjZ/rRIfEGl0dnMrqFJS7a5PJNUv9asZo7xiVW89Aw9ff93CfEY8cXy+hvIbvWLGp 8ASsXhrN9UyS4sGroGJXvuOEw7OAcEzphDt9uCObTYSdISRZjV19KX1UPwwzaLjPdPfK Eo0A== X-Gm-Message-State: APjAAAWpyIUm8fuYkxx/mbGp5Ayecps62oblxZ37dV4ysdTZwrT93jA9 R/WUfJ7sYXPns8HcVqUn0GuRvwuLiUdW7LjPfrvlTrQ3 X-Google-Smtp-Source: APXvYqy+cA3AH+5bktDWAsr/6rBIeMkG6M2RnzTvpnOMdOBYdX9kClCWFc6O3IJc35qEQe8xNsnZKCKb8ZcPkPo8Fyg= X-Received: by 2002:a5d:4d8d:: with SMTP id b13mr20313810wru.6.1581579379245; Wed, 12 Feb 2020 23:36:19 -0800 (PST) In-Reply-To: <941ae97e-169a-4ab2-991f-f9ecf97e8845@www.fastmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42a X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:20412 gmane.lisp.guile.user:16171 Archived-At: --0000000000001586c1059e70251c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No even if you have cross module inlining you will still be able to tell i a module will allow inlining or not else you will break quite a lot of nice scheme idioms. This means that this is indeed future proof. On Wed, Feb 12, 2020 at 10:50 PM Linus Bj=C3=B6rnstam < linus.bjornstam@veryfast.biz> wrote: > If guile ever gets cross-module Inlining in even the simplest form, this > will break. This kind of inlining is probably the most secure one to rely > on ever (my for loops rely on it, for example). A more future proof optio= n > is maybe to (set! ...) A variable within the same module, which makes it > implicitly boxed. Slow unless guile is able to do unboxing... > > Ludo used the trick here: > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=3Dbf1f5422bdb364667= d6761dd73454558d6dbf895 > > -- > Linus Bj=C3=B6rnstam > > On Wed, 12 Feb 2020, at 18:44, Stefan Israelsson Tampe wrote: > > Hi all, > > > > Current guile inlines even variables exposed in the module interface, > > and I understand that we must live with that and code around it. So > > here is a few tips how to mitigate it. > > > > The simplest way is to put this definition in a module: > > ------------------------ > > (define-module (syntax not-inline) > > #:export (not-inline)) > > > > (cond-expand > > (guile-3.0 > > (define (not-inline x) x)) > > ((or (guile-2.0 guile-2.2) > > (define-syntax-rule (not-inline x) x))) > > > > ------------------------------------- > > And then in another module do, > > > > (use-modules (syntax not-inline)) > > (define variable (not-inline 12)) > > (define function (not-inline (lambda () ...))) > > etc > > > > This is also an option (not perfect but you get the gist) > > > > ----------------------------------------------------------------- > > (define-module (syntax define-not-inlinable) > > #:use-module (syntax not-inline) > > #:export (inline define lambda define* lambda* define-values) > > (define inline (lambda (x) x)) > > (define-syntax define > > (syntax-rules (inline) > > ((define (f . x) . code) > > (define f (not-inline (lambda x . code))) > > ((define f (inline x)) > > (define f x)) > > ((define f x) > > (define f (not-inlinable x)))) > > > -------------------------------------------------------------------------= --------- > > using this module will make all usual define not inlineable and to > > enable inlining you would > > explicitly ask for it like > > > > (define f (inline (lambda (x) (+ x 10)))) > > > > If there is a need for this I can write the modules and expose it on > > the intertubes. > > > > WDYT > > > > /Stefan > > > > > > > > > --0000000000001586c1059e70251c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No even if you have cross module inlining you will still b= e able to tell i a module will allow inlining or not else you will break qu= ite a lot of nice scheme idioms.
This means that this is indeed future = proof.

On Wed, Feb 12, 2020 at 10:50 PM Linus Bj=C3=B6rnstam <linus.bjornstam@veryfast.biz= > wrote:
If g= uile ever gets cross-module Inlining in even the simplest form, this will b= reak. This kind of inlining is probably the most secure one to rely on ever= (my for loops rely on it, for example). A more future proof option is mayb= e to (set! ...) A variable within the same module, which makes it implicitl= y boxed. Slow unless guile is able to do unboxing...

Ludo used the trick here: http://git.savannah.gnu.org/cgit/guile.git/commit/?id= =3Dbf1f5422bdb364667d6761dd73454558d6dbf895

--
=C2=A0 Linus Bj=C3=B6rnstam

On Wed, 12 Feb 2020, at 18:44, Stefan Israelsson Tampe wrote:
> Hi all,
>
> Current guile inlines even variables exposed in the module interface, =
> and I understand that we must live with that and code around it. So > here is a few tips how to mitigate it.
>
> The simplest way is to put this definition in a module:
> ------------------------
> (define-module (syntax not-inline)
>=C2=A0 #:export (not-inline))
>
> (cond-expand
>=C2=A0 (guile-3.0
>=C2=A0 (define (not-inline x) x))
>=C2=A0 ((or (guile-2.0 guile-2.2)
>=C2=A0 (define-syntax-rule (not-inline x) x)))
>
> -------------------------------------
> And then in another module do,
>
> (use-modules (syntax not-inline))
> (define variable (not-inline 12))
> (define function (not-inline (lambda () ...)))
> etc
>
> This is also an option (not perfect but you get the gist)
>
> -----------------------------------------------------------------
> (define-module (syntax define-not-inlinable)
>=C2=A0 #:use-module (syntax not-inline)
>=C2=A0 #:export (inline define lambda define* lambda* define-values) > (define inline (lambda (x) x))
> (define-syntax define
>=C2=A0 (syntax-rules (inline)
>=C2=A0 ((define (f . x) . code)
>=C2=A0 (define f (not-inline (lambda x . code)))
>=C2=A0 ((define f (inline x))
>=C2=A0 (define f x))
>=C2=A0 ((define f x)
>=C2=A0 (define f (not-inlinable x))))
> ----------------------------------------------------------------------= ------------
> using this module will make all usual define not inlineable and to > enable inlining you would
> explicitly ask for it like
>
> (define f (inline (lambda (x) (+ x 10))))
>
> If there is a need for this I can write the modules and expose it on <= br> > the intertubes.
>
> WDYT
>
> /Stefan
>
>
>
>
--0000000000001586c1059e70251c--