Re: Mutable top-level bindings

[Mark H Weaver]

Hi Chris,

"Chris K. Jester-Young" <address@hidden> writes:

> On Mon, Apr 15, 2013 at 10:00:55PM -0400, Mark H Weaver wrote:
>> Unfortunately, this is rarely possible in a language like Scheme, where
>> calls to procedures bound by mutable top-level variables are frequent.
>> We cannot fix this without making most commonly-used top-level bindings
>> immutable.  Last I checked, there was strong resistance to this idea.
>
> Maybe it's time to reopen this (and hope it's not a can of worms). :-)
>
> With a proper module system, I don't see why top-level bindings should
> be mutable.

Well, if top-level bindings are immutable, then you have to restart the
system, and possibly even recompile .go files that incorporated
assumptions about the immutable bindings, in order to change a binding.
This is quite contrary to the Lisp and Scheme tradition of course.

My preference would be to provide a way to mark bindings as "rarely
mutated", such that the compiler could treat them as immutable.  The
binding could still be mutated, but mutation would be very expensive: it
would cause all compiled code that incorporated assumptions about that
binding to be immediately invalidated.  This is hard to implement,
though, because it requires "on stack replacement".

> That would make even things like direct inlining of cons or
> + somewhat harder than it needs to be. The way I understand it, the
> definition of (@ (guile) cons) or the like should not be subject to
> change at runtime. If people want to change the behaviour of cons, write
> a module that replaces the top-level binding.

Currently, our compiler treats several bindings in (guile) such as '+',
'car', 'cdr', 'cons', 'eq?', etc, as if they were immutable.  See
(language tree-il primitives) for the full list.  However, it's not
handled very well: you are still allowed to mutate those bindings, and I
guess the evaluator will pick up the changes but the compiler won't.

> Another thing we will need to provide is define-values, which allows you
> to make top-level bindings that are mutually-recursive. By which I mean:
>
>     (define-values (foo bar baz)
>       (letrec ((foo ...)
>                (bar ...)
>                (baz ...))
>         (values foo bar baz)))

Yes.  I started work on this quite a while ago, but got distracted.
Doing the job right requires changes to the "fixing-letrec" pass of the
compiler.  I started by reimplementing the improved "fixing letrec
reloaded" algorithm (with some fixes), but for various reasons it's not
yet ready for publication.  The next step is to finish that work and to
extend it to handle letrec-values and letrec*-values.

     Regards,
       Mark