Re: [Rd] str() resets class for environments

From: Gabor Grothendieck <ggrothendieck_at_myway.com>
Date: Fri 26 Nov 2004 - 14:12:37 EST

 <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.



R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri Nov 26 14:20:56 2004

This archive was generated by hypermail 2.1.8 : Fri 26 Nov 2004 - 15:12:46 EST