Re: Merging Guile-R6RS-Libs in `master'

[Ludovic Courtès]

Hi Julian,

Julian Graham <address@hidden> writes:

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

Hmm, I concur with Andy "that the Guile module `(foo)' should be
representable as the R6RS module `(foo)', and vice versa".  Is there any
reason why this wouldn't be possible (sorry if this has already been
said)?

That means, for instance, that module versioning could first be
implemented in Guile's module system, which would then simply be used by
the `library' form.

The main differences between these two module systems are module
versioning, and phase separation.  Fortunately, R6RS' system is a
superset of Guile's, so we could extend the latter so that it could be
used as the foundation of the former.

Thanks,
Ludo'.