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
