[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
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'.
- Merging Guile-R6RS-Libs in `master',
Ludovic Courtès <=
- Re: Merging Guile-R6RS-Libs in `master', Julian Graham, 2009/04/21
- Re: Merging Guile-R6RS-Libs in `master', Ludovic Courtès, 2009/04/22
- Re: Merging Guile-R6RS-Libs in `master', Julian Graham, 2009/04/22
- Re: Merging Guile-R6RS-Libs in `master', Ludovic Courtès, 2009/04/22
- Re: Merging Guile-R6RS-Libs in `master', Julian Graham, 2009/04/22
- Re: Merging Guile-R6RS-Libs in `master', Andy Wingo, 2009/04/22
- Re: Merging Guile-R6RS-Libs in `master', Ludovic Courtès, 2009/04/22
- Re: Merging Guile-R6RS-Libs in `master', Julian Graham, 2009/04/22
- Re: Merging Guile-R6RS-Libs in `master', Andy Wingo, 2009/04/22
- Re: Merging Guile-R6RS-Libs in `master', Andy Wingo, 2009/04/22