Merging Guile-R6RS-Libs in `master'

[Ludovic Courtès]

Hello Guilers!

I think it'd be nice to merge what's in Guile-R6RS-Libs into `master'.
There are a few issues that need to be sorted out, though.

The API is visible at
http://www.fdn.fr/~lcourtes/software/guile/guile-r6rs-libs.html and the
standard is at
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-1.html#node_toc_start .

  0. Incompleteness

     Guile-R6RS-Libs provides a small subset of what's in /R6RS Standard
     Libraries/.  In particular:

       - The UTF routines in `(rnrs bytevector)' are available, but wide
         string support isn't (yet) available.  I think that's not a big
         issue given that Mike is working on it.

       - The `(rnrs io ports)' provides only binary I/O routines.  These
         routines do not use the right exception mechanism.  For
         instance, `port-position' should raise an `&assertion' R6RS
         error condition, which isn't implemented.

       - Some of the I/O procedures take a TRANSCODER argument but
         ignore it.

    Although it's incomplete compared to the standard, I find it useful
    because the APIs provide functionality not otherwise available in
    Guile.

  1. Module naming

     The 2 available modules are named `(rnrs ...)', as described in
     R6RS.  However, R6RS specifies the version number `(6)' as part of
     the name as well, which we don't support.

     Modules could be called `(r6rs ...)', which would address the
     version number problem, or even `(ice-9 ...)', which would make it
     clear that the implementation is not R6RS-compliant but rather
     "inspired" by R6RS APIs.

     I'm not sure which one of these 3 options is the best one.  This
     will probably depend on how Unicode support evolves.


  2. C name space

     C function/macro/variable names are all prefixed with `scm_r6rs_'.
     Should it change to `scm_'?

  3. Bytevectors as generalized vectors?

     We could easily make bytevectors accessible through the generalized
     vector API.

     Pros: good integration, intuitive, convenient.
     Cons: incentive to use a "standard" API in a non-standard way.

     The latter may not be a problem since SRFI-4 vectors already behave
     this way.

  4. Bytevector read syntax

     ... needs to be implemented.


Comments welcome.

Thanks,
Ludo'.