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?
Jim Rees
(15 Nov 2012 02:36 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)
|
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