Re: r6rs libraries, round two

[Julian Graham]

Hi Andy,

> Your solution of doing whole-program analysis is very much in the spirit
> of R6RS, but it is not in the spirit of Lisp, in my opinion at least.

Well, to be fair, it's not whole-program analysis -- as Neil pointed
out, we only need to analyze the library and program "headers."  But,
sure, point taken.


> I actually think that doing a whole-program analysis is actively harmful
> to the future of Scheme. That's a bit hyperbolic, but it is my opinion.
> To me, Lisp is about living, adaptable systems -- not about static
> programs. There's no need to let mistakes on the part of the R6RS
> editors take us farther down the static path.
>
> Fortunately, we can comply to the letter of the standard, and not the
> spirit.
>
> Back to your question though, what did you think about my symlink
> solution[1]?

It's a fine way of handling version-less dependencies, but I don't see
how it solves the determinism issue.  Let's say my program (or code
stream or script or whatever you want to call it) uses libraries from
two different authors.  Author A trusts his dependencies to remain
stable and doesn't use version specifiers in his library references;
author B does use them.

If my code imports author A's library before author B's, and there's a
version clash in their dependencies, what's the take-away for me, the
user?  Does this mean my code is not well-formed until I reverse the
order of my imports?  Should I not depend on author A's code at all?
On author B's code?  Do I have to patch my libraries before importing
them?

I'm approaching this project in my capacity as a developer with a fair
number of dependencies (that I want manage as abstractly as I can)
wanting to distribute and test my code on as many platforms as
possible.  From my point of view, the fact that there hasn't been a
unified "module" format for Scheme is pretty frustrating.  To the
extent that R6RS has some traction among Scheme implementations, its
library spec is attractive -- although, I recognize, for political
more than technical reasons.

At the same time, after months of poring over the minutiae of R6RS,
I've come around to the position that it's got some serious defects.

Is there some middle ground possible?  The intentions of the R6RS
editors with regard to libraries and programs being "static" seems
pretty clear.  And for certain use cases, that may be appropriate.
But that doesn't mean that Guile modules need to behave that way.
Would people be amenable to having two different ways of working with
libraries / programs?  I.e., the "mode" that Guile would be in when
you ran an R6RS program would be different than when you were in the
REPL.  Maybe it'd even be a different language in the VM.  And we
could establish some prescribed mechanisms by which non-R6RS Guile
code could use R6RS libraries (with caveats attached), and just not
support the converse.

I don't know -- this problem seems to get thornier the more we discuss
it, but I still think it's worth solving.  Sorry if I've missed the
point on any of your comments.


Regards,
Julian