[Chicken-hackers] emptiness of R5RS "environments"

[Thomas Bushnell BSG]

By empty, I mean pointless, not null. :)

R5RS specifies three kinds of environments for passing to eval: a null
environment, a standard environment, and an interaction environment.

In an R5RS compliant Scheme, the interaction environment is a superset
of the standard environment, which is always a superset of the null
environment.

Consider first whether null-environment is needed.  The only difference
between null-environment and scheme-report-environment is that the
latter returns one with some variable bindings in it.  But no error-free
standard-compliant program can detect the difference.  It is an error to
refer to an unbound variable, but the system is not required to report
this in any way.  It could, in fact, behave in such a case as if the
variable were bound to its R5RS standard top-level meaning.  You can see
I am inspired by Yi DAI's question today over on chicken-users.  Nor can
syntax-rules macros detect the presence or absence of a top-level
binding without actually evaluating a variable.

Now, R5RS says that set! of things bound in a scheme-report-environment
is undefined.  But then, that just means that an implementation could
simply permit it to take effect (whether permanently or not makes no
difference).  If it does so, then a "null-environment" filled with
standard bindings could not be detected as such.

Ok, what about (interaction-environment)?  Well, it's a fine thing, but
the standard says nothing about it.  Suppose you want it, and you thus
need it to be different from scheme-report-environment?  Again--even
then!--no.  While normal systems make the interaction-environment
mutable and persistent, the standard requires nothing of it.  A system
could conform entirely by making interaction-environment always return
the same augmented set of (unmodified) bindings, and then, also have
scheme-report-environment and null-environment return the same things.  

R5RS should have dropped environments entirely, and specified eval with
one argument.  It should have said that modifications of top-level
bindings in eval have unspecified results, and that eval always gets a
complete r5rs environment.  Implementations that want the
(interaction-environment) behavior could then get it with an extra
(non-standard) argument to eval.

None of this is relevant to r6rs, because in its grody immutable-binding
world, the identifiers imported into an eval's environment are
immutable, and in its grody mandatory-exception world, the
implementation is required to raise an exception when such a
modification or redefinition is encountered.  (It is unclear to me how
such mandatory things fell within the r6rs committee's mandate.)

Thomas