Re: [Scheme-reports] REPL Helmut Eller (14 Nov 2012 08:51 UTC)
Re: [Scheme-reports] REPL Alex Shinn (14 Nov 2012 09:07 UTC)
Re: [Scheme-reports] REPL Helmut Eller (14 Nov 2012 09:13 UTC)
Re: [Scheme-reports] REPL Alex Shinn (14 Nov 2012 09:26 UTC)
Re: [Scheme-reports] REPL Helmut Eller (14 Nov 2012 10:22 UTC)
Re: [Scheme-reports] REPL Marc Feeley (14 Nov 2012 21:06 UTC)
Re: [Scheme-reports] REPL John Cowan (14 Nov 2012 21:26 UTC)
Re: [Scheme-reports] REPL Marc Feeley (14 Nov 2012 22:05 UTC)
Re: [Scheme-reports] REPL Alex Shinn (14 Nov 2012 23:46 UTC)
[Scheme-reports] equal? Alan Watson (15 Nov 2012 00:40 UTC)
Re: [Scheme-reports] equal? John Cowan (15 Nov 2012 16:26 UTC)
Re: [Scheme-reports] equal? Alan Watson (15 Nov 2012 16:35 UTC)
Re: equal? Arthur A. Gleckler (17 Nov 2012 20:32 UTC)
Re: [Scheme-reports] REPL John Cowan (15 Nov 2012 16:23 UTC)
Re: [Scheme-reports] REPL Aaron W. Hsu (15 Nov 2012 23:47 UTC)
Re: [Scheme-reports] REPL Shiro Kawai (16 Nov 2012 01:16 UTC)
Re: [Scheme-reports] REPL Per Bothner (14 Nov 2012 21:37 UTC)
Re: [Scheme-reports] REPL Marc Feeley (14 Nov 2012 21:49 UTC)
Re: [Scheme-reports] REPL Andy Wingo (04 Jan 2013 13:02 UTC)
Re: [Scheme-reports] REPL John Cowan (04 Jan 2013 15:42 UTC)
Re: [Scheme-reports] REPL Alaric Snell-Pym (04 Jan 2013 16:30 UTC)
Re: [Scheme-reports] REPL Helmut Eller (15 Nov 2012 07:44 UTC)
Re: [Scheme-reports] REPL John Cowan (15 Nov 2012 16:04 UTC)
Re: [Scheme-reports] REPL Per Bothner (15 Nov 2012 16:17 UTC)

Re: [Scheme-reports] REPL Aaron W. Hsu 15 Nov 2012 23:40 UTC

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