[plt-scheme] an r6rs library compatible repl?

At Wed, 19 Mar 2008 21:04:20 +1100, Rohan Drape wrote:
> a reworked question first, reply below.
> 
> the actual problem i have is related to 
> mpairs.  i've an r6rs library that i'd 
> like to use with a upd socket from an 
> repl.  ie. 
> 
>   (require local/r6rs/libraries 
>            scheme/udp)
> 
> the r6rs bytevectors work with the socket but list
> processing doesn't work, since the libraries need
> mutable pairs and the repl is making immutable
> lists.
> 
>   $ mzscheme 
>   Welcome to MzScheme v3.99.0.17 [3m], Copyright (c) 2004-2008 PLT Scheme Inc.
>   > (require rnrs/lists-6)
>   > (filter even? (list 1 2 3 4 5))
>   mcar: expects argument of type <mutable-pair>; given (1 2 3 4 5)
> 
> is there a switch i can give mzscheme to make
> it generate mlists?  (ie. to make an r6rs + 
> udp repl?)

No. Our plan to address this mismatch is to offer a variant of each
R6RS library --- except `(rnrs mutable-pairs)' --- that uses immutable
pairs. When that's ready, you'll be able to write

  > (require rnrs/lists-i-6)
  > (filter even? (list 1 2 3 4 5))

The tool to install R6RS libraries (from third-party sources) will
provide a mode to install immutable-pair variants of the libraries,
which will work as long as they don't depend on `(rnrs mutable-pairs)'.

This direction preserves the benefit of immutable pairs for PLT Scheme
code, where we never have to worry about mutation of pairs. And I
believe that it will be practical for all the reasons described in

 http://blog.plt-scheme.org/2007/11/getting-rid-of-set-car-and-set-cdr.html


> > The thing is that (PLT) Scheme is way more flexible than other
> > languages, which makes `emptiness' a questionable concept.  My version
> > was empty to an extreme, for example, the equivalent example using
> > prefixes as show in:
> >
> >>  (perhaps something along the lines of:
> >>  http://haskell.org/onlinereport/modules.html#sect5.3.2)
> 
> thanks, i have managed to learn why 
> 
>   (module x (only-in scheme/base) ...)
> 
> is not much use, all of the semi-opaque #% 
> infrastructure disappears.  and of course
> i recognize plt modules are obviously more 
> flexible than haskell etc. but hadn't realized
> some of the implications, it does seem to make 
> avoiding simple name collisions with 
> scheme/base rather tricky?

Your message prompted me to follow up on Jos Koot's solution to this
problem:

 http://list.cs.brown.edu/pipermail/plt-scheme/2008-March/023709.html


Matthew