Re: [Scheme-reports] REPL Helmut Eller (16 Nov 2012 07:23 UTC)
|
||
Re: [Scheme-reports] REPL
John Cowan
(16 Nov 2012 19:10 UTC)
|
||
(missing)
|
||
Re: [Scheme-reports] REPL
John Cowan
(16 Nov 2012 21:07 UTC)
|
||
Re: [Scheme-reports] REPL
Alex Shinn
(16 Nov 2012 22:15 UTC)
|
On Fri, Nov 16 2012, Aaron W. Hsu wrote: > 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. Here are problems that I see: 1.) 'define-library is not exported by any standard library. Evidence that this is a problem is provided by the R7RS test suite: it does not contain a single test for the library system. This is a problem because a) the library system is arguably the most important new feature and should therefore be tested thoroughly b) it's impossible to write such tests within R7RS Scheme because 'define-library is not actually available. > > 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. 2.) I don't by your argument because your example does not do any interesting redefinition. Let's take a more concrete example: the game of life example from Section 5.6.2. Let's assume we have the (example grid) and (example life) libraries in the files grid.scm an life.scm respectively. The first problem we encounter is this: bash> chibi > (import (scheme base) (only (example life) life) (rename (prefix (example grid) grid-) (grid-make make-grid))) ERROR on line 1: couldn't find import: (example life) > So how are we going to make (example life) available? The only way I know is to exit from Chibi Scheme, create a directory example/, move life.scm to example/life.sld, restart Chibi with extra command line options: bash> chibi -A example/ > (import (scheme base) (only (example life) life) (rename (prefix (example grid) grid-) (grid-make make-grid))) > Note that the crucial operations: renaming files, restarting with extra command line options, are outside of R7RS Scheme. At least we can now run the program: > (begin (define grid (make-grid 24 24)) (grid-set! grid 1 1 #true) (grid-set! grid 2 2 #true) (grid-set! grid 3 0 #true) (grid-set! grid 3 1 #true) (grid-set! grid 3 2 #true)) > (life grid 80) [Lots of output, among other things vt100 control sequences] No lets assume we want to stop emitting those v100 control sequences from the life-print function in (example life). How are we going to do that? Well, lets take a text editor and delete the line in example/life.sld. (display "\x1B;[1H\x1B;[J") ; clear vt100 OK, that was easy. But how do we run the modified program? Redefinition of the 'life function, as you suggested, is not an option as the life-print function is not even exported. The only solution that I see is to exit from Chibi Scheme and restart it. Again this exit/restart dance is outside of R7RS Scheme. All in all this kind of development is not any more "interactive" than writing Java programs, i.e. interaction-environment is quite a misnomer. Helmut _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports