Re: r6rs libraries, round two

[Julian Graham <joolean@gmail.com>]

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