Hi Neil,
> I assume the objective here is to allow a Guile program or module to > use a portable R6RS library; i.e., specifically, allowing > `(use-modules ...)' or `#:use-module (...)' to resolve to an R6RS > library. Is that correct? Actually, my immediate-term goal was to add versioning info to Guile's "native" modules in an R6RS-compatible way. Once that's done, the level of compatibility you're describing would be feasible, although I think it'd be up for discussion as to whether it's something we want. I kind of assumed that in the first iteration there'd be an explicit bridge into R6RS library territory, e.g., `(rnrs-import ...)' or something like that. > Yes, at least as far as R6RS library modules are concerned. I've > reviewed the relevant discussions on this now and am happy that > there's no desire to support multiple live versions of R6RS libraries. > > I'd prefer not to rule this out, though, for any future versioning > that we might add to (define-module ...). Is that feasible? Not sure I understand -- the impression I got from earlier messages in this thread was that we would be implementing R6RS libraries on top of Guile modules, after first extending the module form to include version metadata. > - Once we're into R6RS library code, we're OK, because the R6RS layout > requires all of the imports to be declared upfront; so we don't need > to read the rest of the library code. Yes -- from what I can tell, R6RS effectively prohibits "dynamic" access to the import system. That is, an import call always results directly from a previous import, never from the evaluation of an expression. (This strikes me as a little weird, since it means that building an application with a "plugin" architecture would require you to roll your own import system, but I suppose that's not too far afield from what languages like C# make you do in that regard.) > - In a Guile module, we could specify that versioned imports can only > be done by #:use-module expressions as part of the (define-module > ...) form, and not support versioned imports by (use-modules ...). > Then we'd only have to read the (define-module ...) form. So what would the semantics of the version-less (use-modules ...) be in the context of versioned modules already loaded via #:use-module expressions? To minimize version-clash, I'm guessing we'd defer to already-loaded modules when possible -- although this wouldn't address the case in which a module loaded at runtime via (use-modules ...) introduces a #:use-module dependency that conflicts with an already-loaded module. > Hmm.. it seems this boils down to saying that we would partially > deprecate `(use-modules ...)'. Or at least point out that its use prevents Guile from being able to guarantee conflict-less execution. > I can imagine a less clever approach, in which each import is > considered as we come to it, and [snip] I think this is what I was trying to suggest, stated more clearly. And unless I'm misunderstanding, I think this makes sense as behavior for (use-modules ...), with the caveats mentioned above. Regards, Julian
