unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Merging Guile-R6RS-Libs in `master'
@ 2009-04-21 21:18 Ludovic Courtès
  2009-04-21 21:45 ` Julian Graham
  2009-04-21 21:58 ` Andy Wingo
  0 siblings, 2 replies; 22+ messages in thread
From: Ludovic Courtès @ 2009-04-21 21:18 UTC (permalink / raw)
  To: guile-devel

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'.





^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2009-05-29  9:02 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-21 21:18 Merging Guile-R6RS-Libs in `master' Ludovic Courtès
2009-04-21 21:45 ` Julian Graham
2009-04-22  7:55   ` Ludovic Courtès
2009-04-22 14:55     ` Julian Graham
2009-04-22 15:53       ` Ludovic Courtès
2009-04-22 18:32         ` Julian Graham
2009-04-22 19:52           ` Andy Wingo
2009-04-22 20:09             ` Ludovic Courtès
2009-04-22 20:22             ` Julian Graham
2009-04-22 21:53               ` Andy Wingo
2009-04-22 19:08         ` Andy Wingo
2009-04-22 19:57           ` Ludovic Courtès
2009-04-22 19:07     ` Andy Wingo
2009-04-22 19:51       ` Ludovic Courtès
2009-04-22 20:10         ` Julian Graham
2009-04-21 21:58 ` Andy Wingo
2009-04-22  8:04   ` Ludovic Courtès
2009-05-27 22:27     ` Ludovic Courtès
2009-05-28 17:52       ` Andy Wingo
2009-05-28 19:16         ` Ludovic Courtès
2009-05-28 21:25           ` Ludovic Courtès
2009-05-29  9:02           ` Andy Wingo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).