[Rd] str() resets class for environments

[Gabor Grothendieck]

 <Mark.Bravington <at> csiro.au> writes:

: 
: > : Henrik Bengtsson:
: > : > : I am curious though, do you not run into problems by 
: > setting and getting
: > : > : attributes on environment in 'mvbutils'? The example of 
: > John Chambers I
: > : > : re-posted, which shows that attributes can (will?) get 
: > "killed by 
: > operating
: > : > : on the [environment] object "locally" in a function", 
: > suggests that you
: > : > : will.
: > : > : 
: > : > 
: 
: In my code, I do want to permanently set the "global" attributes of an 
environment such as pos.to.env(1)
: from within a function, so the behaviour of [in effect] 'attr<-.env' is not 
at all problematic :)
: 
: [In old versions of R, I used to have to invoke a function 
called 'lib.fixup' after setting an attribute of a
: search path environment, to make sure it "really happened", but this has 
been unnecessary in recent versions.]
: 
: > :Peter Dalgaard <p.dalgaard <at> biostat.ku.dk> writes:
: > : Environments are already irregular in that they are never duplicated
: > : (which is what causes these issues in the first place). External
: > : pointers have the same feature, and Luke Tierney has suggested that
: > : they perhaps should be wrapped in an object with more normal
: > : semantics. Perhaps we should consider doing likewise with
: > : environments? 
: > 
: > Gabor Grothendieck <ggrothendieck <at> myway.com> writes:
: > To me that would make sense in keeping the rules of the language
: > more consistent.  The mvbutils example suggests that it also has
: > uses in addition to regularity and additional ones may come to
: > light too.
: > 
: 
: If environments were wrapped, would it still be possible to change the 
attributes of e.g. pos.to.env (5),
: as opposed to the attributes of a copy? That's the feature I'm keen to 
retain. For example:
: 
: > e5 <- pos.to.env( 5)
: > attr( e5, 'my.attr') <- 'whatever'
: > # If 'e5' is a wrapper, then this will no longer change the attribute 
of 'pos.to.env( 5)'
: > attr( pos.to.env( 5), 'my.attr')
: NULL
: > # So I would need to be able to do something ugly like this:
: > pos.to.env( 5) <- e5  # Yuk!?
: 
: Wrapping environments does avoid the "top level" of nonduplication, but the 
deeper level of
: nonduplicating the contents is unavoidable (and that's the point, of 
course): 
: 
: > pos.to.env(5)$x
: NULL
: > e5$x <- 0
: > pos.to.env(5)$x
: [1] 0
: 
: So I'm not sure all this can ever be made entirely "clean", even if 
automatic wrapping did get used. Equally,
: though, I'm not sure I've correctly understood the intention.


I don't know what the right answer should be but right now
if e1 == e2 for two environments then those environments are 
the same since environments are just pointers.

1. If attributes and classes were somehow stored in the 
environment itself (which is what you are looking for
I think) then the above condition would also
be sufficient to guarantee that they have the same class
and attributes.

2. If attributes and classes are associated with a wrapper
then equality requires that the underlying environments
are the same and also requires that the classes and
attributes of the two wrappers be the same.

Both these viewpoints have a certain sense to them in
that the first is more R-like but the second is
more environment-like.

3. The current situation where environments cannot
have classes and attributes does have the advantage
that one need not decide between the two approaches.

I guess I am arguing, in part, against what I said
before but in thinking about this more I realize
that all three viewpoints seem to have some merit
and its actually quite difficult to choose.