[Rd] is.environment, as.environment, and NULL
Tue, 28 Aug 2001 08:25:39 +0200
>>>>> Peter Dalgaard BSA writes:
> John Chambers <email@example.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,
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: firstname.lastname@example.org