Re: r6rs libraries, round two

[Andy Wingo]

Hi Julian,

On Sun 28 Jun 2009 02:20, Julian Graham <address@hidden> 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/