[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] REPL

John Cowan <cowan@x> 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