Re: Mutating public bindings of a declarative module

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

Andy Wingo <wingo@igalia.com> skribis:

> On Sun 24 Nov 2019 18:54, Ludovic Courtès <ludo@gnu.org> writes:
>
>> It seems that if you ‘set!’ a public variable of a declarative module,
>> the change is visible to all the module users, but it’s not necessarily
>> visible to procedures within that module, presumably because they use an
>> inlined or specialized variant of that thing.
>>
>> I would have imagined that public bindings are considered mutable and
>> thus not subject to inlining; OTOH, that would obviously be a loss, so
>> the current approach makes sense.
>
> Right, I understand the frustration.  For what it is worth, I think we
> have the right default for what it means to be a declarative module, but
> I'm definitely open to having that conversation.

In C on GNU/Linux, if we have this in the same compilation unit:

  int foo () { … }
  int bar () { foo (); }

then ‘bar’ will not necessarily call the ‘foo’ that’s just above.  It’s
possible to replace ‘foo’ via loader tricks such as ‘LD_PRELOAD’.

That means that (1) ‘foo’ is not subject to inlining, and (2) which
‘foo’ ‘bar’ refers to is determined at load time.

So the semantics we have go somewhat further than this.  Not saying we
should follow C, but that’s what came to mind when thinking about the
pros and cons.

>> Anyway, it complicates a use case for me.  In Guix, we “mock” bindings
>> like so:
>>
>>   (define-syntax-rule (mock (module proc replacement) body ...)
>>     "Within BODY, replace the definition of PROC from MODULE with the definition
>>   given by REPLACEMENT."
>>     (let* ((m (resolve-interface 'module))
>>            (original (module-ref m 'proc)))
>>       (dynamic-wind
>>         (lambda () (module-set! m 'proc replacement))
>>         (lambda () body ...)
>>         (lambda () (module-set! m 'proc original)))))
>>
>> and that allows us to write tests that temporarily modify public (or
>> private!) bindings.
>>
>> It seems like this could be addressed by compiling selected modules with
>> ‘user-modules-declarative?’ set to #false, or by avoiding the above hack
>> altogether when possible, but I thought I’d share my impressions and
>> listen to what people think.  :-)
>
> This works.  (Actually the way I would do it is to pass #:declarative?
> #f in the define-module for the modules in question.)

The problem of #:declarative? is that you can’t wrap it in ‘cond-expand’.
I suppose most users will have a transition period during which both 2.2
and 3.0 are supported, and they cannot rely on 3.0-only forms during
that period.  :-/

> Marking some
> bindings as not declarative also works (e.g. (set! foo foo)).

Yes, I thought about that.  Perhaps we could provide a
‘preserve-binding!’ macro that does exactly that but would look less
weird.  :-)

> For me the most robust solution would be to have `mock' verify that the
> module it's funging isn't declarative.  We don't currently have a way to
> know if an individual module binding is declarative or not (though we
> could add this).

‘mock’ would have to error out if finds out that it cannot fiddle with a
binding, so it wouldn’t make much of a difference, just changing the
error type.

Thanks for your feedback!

Ludo’.