Anton van Straaten
Wed Dec 7 16:31:19 EST 2005
Michael Sperber wrote:
> dyb at cs.indiana.edu writes:
>>Assuming we decide on immutability, then, is that for (a) all bindings,
>>(b) all exported bindings (indirect as well as direct) only, or (c) all
>>directly exported bindings only? Are (i) both exporting and importing
>>modules enjoined from mutating an export or (ii) just the importing
>>modules? (I assume we're talking about variable bindings only, in
> I was personally thinking (implicitly, I now realize) that
> "immutability" referred to the fact that the SET! on a top-level
> variable defined in a module has to be in the body of that same
That was my thinking too.
Kent Dybvig wrote:
> I don't like conflating namespace management and mutability control;
> each is useful independently of the other. That is, I would have
> the library system control visibility of identifiers and introduce a
> define-immutable form or allow people to define their own as a macro.
The ability to define a completely immutable variable - one that can't
even be SET! within its defining module - is (or should be) a separate
issue. However, the ability to restrict mutation of a variable by
modules other than the defining module seems to fall within the domain
of the module system.
I don't have any objection in principle to adding support for a
qualifier in the export form which allows a suitably qualified exported
variable to be mutated by an importing module. However, I believe the
default behavior of variables exported from a module should be as
described by Mike above.
P.S. I suppose I should s/module/library/, I haven't gotten used to that
More information about the R6RS