[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Merging Guile-R6RS-Libs in `master'

From: Ludovic Courtès
Subject: Merging Guile-R6RS-Libs in `master'
Date: Tue, 21 Apr 2009 23:18:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux)

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 and the
standard is at .

  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

  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]