Hi Julian, On Sun 28 Jun 2009 02:20, Julian Graham <[email protected]> writes:
> With the 1.9 series launched, I wanted to start thinking about R6RS > libraries again, since it would be awesome to have some semblance of > an implementation ready by October. Yes! >> I think such issues should lead us to have a `:version' option that does >> just what's needed for R6RS, and does not try to do anything smart >> (which could seem to be non-deterministic). We could even go as far as >> discouraging its use in the manual. > > Alright -- so, to summarize what (I think) has been decided: > > 1. Having more than one version of a module loaded at a time in a > single Guile process / VM is not going to be supported. I agree. > 2. Mixing load calls that specify version with load calls that do not > should produce deterministic behavior independent of the set of > already-loaded modules. (As described here: [1].) I disagree. I don't think that you can do (2) without (1). 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. Larry Wall was right. Lisp is like oatmeal: of a uniform, mushy consistency. A Lisp system is composed of a procedures and data, permeating each other. You can add (or remove!) procedures and data, and it's still basically the same system. Of course we have modules to keep things manageable, but Guile's take is that modules are mutable entities. You can enter modules and make new definitions, or even remove old ones. Indeed you may have a long-running process that you hack for months, mutating the system over time in response to needs that crop up over time. Of course, with so much mutation -- definition is mutation, after all, in a live system -- you just have to have good practices to keep things under control. Any program that imports unqualified module names (without versions) is inherently not "future-portable" anyway, for the reasons that Ludovic and others discussed on r6rs-discuss[0]. So /we don't even need to worry about it/. We have to let "good practices" take care of us here. [0] http://lists.r6rs.org/pipermail/r6rs-discuss/2007-May/002332.html. The only fully specified program is one that has all of the versions declared, but even that program may not have deterministic results -- if an incompatible library is already loaded in the Guile session, the r6rs program or library will fail to load. 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]? [1] http://article.gmane.org/gmane.lisp.guile.devel/8585 Cheers, Andy -- http://wingolog.org/
