[ERR5RS] Bindings in R5RS vs R6RS

[AndrevanTonder]

On Sat, 15 Sep 2007, David Rush wrote:

> There seems to be something of a debate building up over top-level
> semantics

Indeed.  ERR5RS should decide soon what it wants to do about this.

> 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 do not think I agree with this.  As far as I am aware, the meaning of a 
portable R5RS program does not depend on whether it is interpreted
dynamically or first compiled and then run.  Will can probably answer
this better, but I wouldn't be surprised to hear that this was by
careful design.(*)

> I think that the fully dynamic REPL model of R5RS ...

See above.

> ... is the
> foundational model required for ERR5RS (and the future of Scheme, but
> that's another issue entirely).

It is very difficult to come up with an interactive model that is
obviously the right thing.  Various existing Scheme implementations
have widely different and incompatible interactive models.  It would
cause a lot of controversy, not to mention bloat, if ERR5RS were to
attempt to specify one particular model.  Furthermore, do we really
want to exclude compiler-only Scheme systems from the ERR5RS label?

In my opinion, the best one can do is follow the approach of R5RS
and specify a subset of possible portable programs that will have the
same meaning interactively and when compiled.

> * the top-level bindings of the basis library must remain mutable

R5RS certainly does not say that top-level primitive bindings are
mutable.  It quite clearly prohibits portable programs from mutating
them by stating:

   Altering any top-level binding that has not been introduced by a
   definition has an unspecified effect on the behavior of the built-in
   procedures.

R5RS does allow one to use a definition to introduce a /new/ binding
for CAR, which can then be mutated, which is a different story.

If one is to follow the examle of R5RS, then bindings imported
from other libraries should also not be portably 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.

This is not quite right.  SET! changes the value stored in the location
to which the name refers.  Even if you prohibit SET!ing the location,
you can still change the name you use to refer to it all you want.
So R6RS does nothing that changes the notion of alpha-conversion.

But yes, the question of what it means to import stuff into a top
level, and what one can do with that stuff, should certainly be
addressed clearly, but maybe our philosophy on this is different.
I would not try to do too much.  In fact, I would try to do as
little as possible, in the sense that I think

1) One should give a simple characterization, as close to R5RS as
    possible, of portable programs whose meaning is the same in /both/
    dynamic and compiler-based systems.

2) One should allow implementations to otherwise do what they want
    in the REPL, subject to the constraint implied by (1).

Cheers
Andre

(*) Remember, both LOAD and INTERACTION-ENVIRONMENT are optional
procedures in R5RS.