Re: [Scheme-reports] REPL

[Helmut Eller <eller.helmut@x>]

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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports