Happy New Year, Guilers!
> So maybe I'm being dense here, but it looks like the way forward might > be to whip up a quick module-to-library mapping system (i.e., > something like (foo bar (version)) -> /foo/bar/version) and then start > working on piecemeal attempts to get imports working? Like, in the > following order, I'd say we could tackle: > > 1) Mapping the existing features of Guile's module system onto their > R6RS counterparts > 2) Implementing version selection > 3) Implementing import levels That last email was written between drinking at a bar and going to bed. The *proper* mapping for versions would be more like: (foo bar (version)) -> (foo version bar) So if your R6RS library name was `(my r6rs library (1 2 3))', then the corresponding Guile module name would be `(my r6rs 1 2 3 library)'. I had a little time this afternoon to play around with some syntax transformations for converting between libraries and modules, which led to the following observations: * Any library-to-module transformations we could do would be one-way (i.e., libraries to modules), since R6RS requires that any non-binding expressions have to come after the bindings in a library; rewriting a module to meet that requirement would be non-trivial. * Module definitions created from R6RS libraries need to use the #:pure keyword. * There's a somewhat perplexing R6RS requirement to allow renaming symbols on export, similar to the way Guile currently supports renaming them on import. I don't see a way to do this without modifications to the core. * I think it'd be possible to implement R6RS "import levels" using Guile's existing #:export, #:export-syntax, #:reexpport, and #:reexport-syntax keywords -- if it weren't for the `(meta <level>)' option for import specifiers. It might still be possible, given the allowances of section 7.2. I don't know, I'm still trying to figure that out. Other than the above, it looks like a lot of the heavy lifting has already been done by the module system. Regards, Julian
