[R6RS] libraries

[dyb at cs.indiana.edu]

> There's a whole spectrum here, leading all the
> way up to SML, where all bindings are immutable, so it doesn't seem
> clear that program analysis should trump us to any particular place in
> the middle of that spectrum.

Going as far as SML wouldn't make program analysis any easier than
making exports completely immutable: settable variables don't cause
any more problems than ML's ref cells (or Scheme's pairs, vectors, and
now records), as long as one can look at a piece of code and determine
which of the variables are actually settable.  One can automatically
convert a Scheme program with assignments into one without assignments
by introducing a ref cell for each settable variable and end up with
exactly the same number of ref cells and resulting indirects as in the
corresponding ML program (without burdening the programmer with the
responsibility for introducing them explicitly), if and only if one
knows which variables are settable.

So I'm not trying to trump us to any particular place *in the middle
of that spectrum*.  I'm trying instead to trump us to the place
where we can determine the exact set of settable variables, both in
the exporting and importing modules.  That is, I prefer either total
mutability for convenience or total immutability for program analysis
(by programmer and tool).  I'm not opposed to some middle ground if it's
easily understood and supports a reasonable share of both convenience
and program analysis, but I don't believe there is such a middle ground.
Restricting assignments only to the post-expansion residual code of the
exporting module comes closest, but it is isn't as easy to understand
as either total mutability or total immutability and it doesn't help
with the analysis of the importing modules.

Kent