Mutable top-level bindings (was: vectors are something else)

[Chris K. Jester-Young]

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. 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.

Yes, this does disable the ability to perform monkey-patching. I don't
see this as a big loss, but perhaps there are legitimate use cases for
monkey-patching that I haven't thought of.

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)))

This would obviate the need to use the following pattern:

    (define foo #f)
    (define bar #f)
    (define baz #f)
    (letrec ((my-foo ...)
             (my-bar ...)
             (my-baz ...))
      (set! foo my-foo)
      (set! bar my-bar)
      (set! baz my-baz))

Granted, there are existing modules that use that approach currently, as
we don't currently have define-values. But I think it should be possible
to annotate individual modules as having immutable top-level bindings,
so that we can gradually migrate modules to the define-values style.

Cheers,
Chris.