In practice the ability to mutate exported bindings comes handy when you can't
(or don't want) to touch the original library code which was written without the
"hooks" as you describe.  It is not a "right thing" and harmful in the long run,
nevertheless it is indispensable in day-to-day operation (you have to
fix it ASAP
when the customers pounding the door!)

But such dirty hacks require precise knowledge in implementation details anyway,
such as how the code is optimized, so I'm ok to leave such ability as an
implementation's extension, as far as the standard does not prohibit
such extension
(and r7rs meets the criteria, iiuc).

On Thu, Nov 15, 2012 at 1:40 PM, Aaron W. Hsu <arcfide@sacrideo.us> wrote:
> John Cowan <cowan@mercury.ccil.org> wrote:
>
>> Marc Feeley scripsit:
>>
>> > R7RS defines mutation of imported variables as "an error".  This looks
>> > like a restriction to me and goes against the Scheme mantra "Programming
>> > languages should be designed not by piling feature on top of feature,
>> > but by removing the weaknesses and restrictions...".
>>
>> Please note the discussion of error situations that don't use the term
>> "signaled" in 1.3.2 (emphasis added):
>
> While this is true, I also do not see why people have such a problem
> with immutable library exports. In particular, most of the module
> systems with which I am familiar make this assumption. The only one
> that does not to my knowledge is the Chez Scheme 'module' form,
> which is significantly different than the 'library' form, and serves
> a different purpose.
>
> Moreover, preventing mutation of imported variables does *not* make
> things like code redefinition difficult. Consider the following R6RS
> set, which has the same set of restrictions as R7RS:
>
> (library (my-code)
>   (export f1 f2 f3 redefine-f*)
>   (import (rnrs))
>
>   (define %f1 ...)
>   (define %f2 ...)
>   (define %f3 ...)
>   (define (redefine-f* f1 f2 f3)
>     (set! %f1 f1)
>     (set! %f2 f2)
>     (set! %f3 f3))
>
>   (define (f1 . args) (apply %f1 args))
>   (define (f2 . args) (apply %f2 args))
>   (define (f3 . args) (apply %f3 args)))
>
> Here it's perfectly easy to redefine the code that is in the library,
> but in addition, you get control over what functions can be changed,
> and what do not. This means that an implementation can still make
> important efficiency decisions about other functions, while giving
> up on trying to do anything interesting on those mutable variables.
> What's more, this is no different than having a mutable flag per
> export or any of the other schemes of equivalent expressiveness.
> Indeed, this is easily wrapped up into a trivial macro that creates
> mutable variables.
>
> Thus, I see only good things about the immutability constraint on
> library imports and exports. If we admit the additional features
> of identifier syntax then we can have mutable variables with no
> noticable difference in practice, except that now we have more control
> over what is mutable and what is not.
>
> --
>
> _______________________________________________
> Scheme-reports mailing list
> Scheme-reports@scheme-reports.org
> http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports