Re: [Rd] attributes of environments

From: Duncan Murdoch <>
Date: Wed 05 Jul 2006 - 16:54:40 GMT

On 7/5/2006 12:39 PM, Gabor Grothendieck wrote:
> On 7/5/06, Thomas Lumley <> wrote:

>> On Wed, 5 Jul 2006, Gabor Grothendieck wrote:
>> > On 7/5/06, Thomas Lumley <> wrote:
>> >> On Tue, 4 Jul 2006, Gabor Grothendieck wrote:
>> >>
>> >> > In the code below, e is an environment which we copy to f and then
>> >> > add attributes to e.  Now f winds up with the same attributes.
>> >> >
>> >> > In other words it seems that the attributes are a property of the
>> >> > environment itself and not of the variable.  Thus it appears we
>> >> > cannot have two environment variables that correspond to the
>> >> > original environment but with different attributes.
>> >>
>> >> No, we can't. The two variables are references to the same environment, so
>> >> they are the same.
>> >>
>> >> If you want the attributes to be copies rather than references then create
>> >> a list with the environment as an element and put the attributes on the
>> >> list.
>> >
>> > I realize that that is how it works but what I was really wondering was
>> > should it work that way?
>> >
>> I think it really should (and this question has come up before).  If you
>> do
>>    e<-environment()
>>    f<-e
>> then there is only one object that f and e both point to. Now, since such
>> things as S3 class and matrix dimension are implemented as attributes I
>> think you really have to consider the attributes as part of the object
>> [which is also how they are implemented, of course].  So if e and f are
>> the same object they should have the same attributes.

> I don't think this follows since in the other cases modifying the
> object also creates a copy.

>> Another reasonable position would be to disallow attributes on
>> environments (as we do with NULL, another reference object), but that
>> seems extreme.

> I don't think that that would solve it because there is still the issue
> of the class attribute which you can't disallow.

> In fact consider this:

> e <- new.env()
> f <- e
> class(f) <- c("myenv", "environment")
> F <- function(x) UseMethod("F")
> F.environment <- function(x) 1
> F.myenv <- function(x) 2
> F(e) # 2
> F(f) # 2

> The point is that subclassing does not work properly with environments

> yet subclasses of the environment class should be possible since R
> is supposed to be OO and I see no valid reason for exclusing environments
> for this. I guess in this discussion I am coming to the realization that
> this issue really is a problem with the current way R works.

I don't think subclassing is important here. The issue is that both e and f are references to the same object. As such, changing the class of f will change the class of e, so what you're seeing is what you should expect.

You could fairly easily create f as a new environment, and copy all of the contents of e and its attributes over to f, and then you'd get the   behaviour you're expecting. But that doesn't give sensible semantics for environments in general: for example,

assign("x", 1, envir = e)

had better make the assignment into e, not into a copy of e. Similarly,

 > f <- function() {

+   a <- 0
+   local1 <- function() a <<- 1
+   local2 <- function() a
+   list(f1=local1, f2=local2)
+ }
 > fns <- f()

 > fns$f1()
 > fns$f2()
[1] 1

would not work properly if each of local1 and local2 just had copies of the evaluation environment of f. They need references to the same environment, so the assignment in local1 will be seen in the environment inherited by local2.

Duncan Murdoch mailing list Received on Thu Jul 06 03:00:27 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Wed 05 Jul 2006 - 18:27:14 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.