Re: Prevent inlining

2020-02-13 Thread Linus Björnstam
Will it not inline "(not-inline x)" and then peval it to x? What are you trying to avoid? I am out on very deep water here, now I am just genuinely curious :D -- Linus Björnstam On Thu, 13 Feb 2020, at 08:36, Stefan Israelsson Tampe wrote: > No even if you have cross module inlining you will s

Re: Prevent inlining

2020-02-12 Thread Stefan Israelsson Tampe
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örnstam < linus.bjorns...@veryfast.biz> wrote:

Re: Prevent inlining

2020-02-12 Thread Linus Björnstam
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 option is maybe to (set! ...) A variable within the same module, which makes it i

Prevent inlining

2020-02-12 Thread Stefan Israelsson Tampe
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-inli