[ERR5RS] Bindings in R5RS vs R6RS

[David Rush]

Hi all -

There seems to be something of a debate building up over top-level
semantics and how to deal with the immutablity and library constraints
of R6RS in light of the very different model presented by R5RS. In
short, R6RS seems very oriented towards static analyses (such as those
performed by most compilers); but R5RS is much more oriented towards a
constantly mutating REPL.

I'm becoming convinced that these are not interoperable views, and
furthermore, that this is *not* the way that the programming community
in Scheme or any other putative 'competition' for programming
mind-share want. We are working in a world of increasingly dynamic
program updates - web-servers that detect changed shared libraries and
reload them without restarting are common in several languages. In
short, I think that the fully dynamic REPL model of R5RS is the
foundational model required for ERR5RS (and the future of Scheme, but
that's another issue entirely).

I'm posting here, because this issue cuts across many of the ERR5RS
wiki pages. In short:

* the top-level bindings of the basis library must remain mutable
* library versioning must be manageable by user code
* names bound from a library should probably be mutable

Let's remember that names are not a first class entity in Scheme and
that the text of a Scheme program is only a single member of a
congruence class of programs modulo alpha-conversion. Just to be
utterly pedantic: names are a convenient label for specific formal
semantics postulated in a specific unit of source code. R6RS changes
that notion fairly radically (although perhaps unintentionally) by
introducing immutable bindings.

And to be fair to the immutability argument - I am unaware of any
Scheme which truly implements mutable bindings for things like CAR,
MAP, or APPEND. Under the covers of every toplevel are the internal
names of the actual primitives which implement the ur-CAR, ur-MAP, and
ur-APPEND functionality that is required to make *everything* work.
However, this *fact* actually proves the earlier point, IMO. The names
of the primitives are not relevant - the algebra provided by category
of the functions and data *is*.

david rush
-- 
Once you label me, you negate me
    - Soren Kierkegaard