Hi Ludovic, Cool! Thanks for doing this.
> 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. For what it's worth, I'd prefer the `(ice-9 ...)' approach, since, to be fair, these are Guile modules, not R6RS libraries (which have some specific differences in their export interfaces and the way they are looked up / matched). On a related note, have you had a chance to review the R6RS library search mechanism I proposed a while back? [1] Using that algorithm (and going with the `ice-9' prefix), your modules could be wrapped such that: * There would exist a library wrapper module called `(rnrs bytevectors)' * Loading this module would cause the library form for the R6RS library `(rnrs bytevectors (6))' to be loaded (from, say, a file in the same directory called "bytevectors.scm.6") and registered with the R6RS library system. * This library would delegate to `(ice-9 rnrs bytevector)' and re-export its bindings as required. Does that make sense? This way your module would be available both to users of the Guile module and to users of R6RS libraries while maintaining proper version semantics. Regards, Julian [1] - http://article.gmane.org/gmane.lisp.guile.devel/8305
