is.environment, as.environment, and NULL

Peter Dalgaard BSA writes:

John Chambers <jmc@research.bell-labs.com> writes:

There isn't a completely consistent solution, given the use of NULL as
an environment.  For the moment it seemed best to live with that one
anomalous result in the tests.

The use of NULL for the base environment is something which I would
like to see go away anyway. It makes little sense semantically (if
anything, you would want the NULL environment to be an empty one), and
there are pitfalls where a NULL value returned by accident can cause
code to work in base but not in a package.

I did start to look into it at some point but ran out of stamina or
got distracted (probably by release timings as usual...). As I recall
it, NULL for base envir is only really used in a handful of places as
a sentinel for searches through the search path, as in:

    for (rho = R_GlobalEnv; rho != R_NilValue; rho = ENCLOS(rho)) ..

The base environment is special because the symbol lookups are
different there, but it could be represented by R_BaseEnv or some such
instead of R_NilValue. I doubt that much interpreted code needs to
explicitly test whether an environment is the base environment. One
thing to watch out for might be saved workspaces, though. On the other
hand, we do not save the search path, so maybe not...

A question, and a remark.

Question, would we want to keep as.environment(NULL) to give the base
package, so that code like ls(envir = NULL) will still work?

Remark, we once discussed making package environments (in particular for
base) read-only.  One way of doing this is via setting attributes, but
we cannot do this on NULL.  Not that I think this is the way to do it,
though ...

.GlobalEnv

is.null(.GlobalEnv)