Re: [Rd] str() resets class for environments
[EMAIL PROTECTED] writes: 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: Offhand: Yes, if things are arranged so that you set attributes on the elements of the search path rather than on the environments themselves. This could also be useful if we were to ever make an effort to bring the semantics of detach() in line with its documentation... -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] str() resets class for environments
Henrik Bengtsson hb at maths.lth.se writes: : : -Original Message- : From: r-devel-bounces at stat.math.ethz.ch : [mailto:r-devel-bounces at stat.math.ethz.ch] On Behalf Of : Mark.Bravington at csiro.au : Sent: Wednesday, November 24, 2004 1:43 AM : To: hb at maths.lth.se : Cc: r-devel at stat.math.ethz.ch : Subject: RE: [Rd] str() resets class for environments : : : Henrik Bengtsson wrote: : : Should attr()-, attributes()-, : class()- give an error when applied to an environment? I see : no reason why : not. : : It would break the workspace-organization code in the : 'mvbutils' package, which relies on being able to set and : unset attributes of environments on the search path : (specifically, the 'name' and 'path' attributes). : : So personally I'd much prefer not to have this happen! For : the wider R community, I'm not sure how many users the : 'mvbutils' package has, but I think it's a fair number : judging from emails I get. : : If you do feel the extra security is vitally important, : perhaps there could be 'lock.attributes' and : 'unlock.attributes' functions for environments. The idea : would be that each environment has an invisible (i.e. : internal) mock-attribute locked, which would be TRUE by : default (on creation of the environment). While locked is : TRUE, any attempt to muck about with the environment's : attributes would cause an error. But if you really did need : to change attributes of that , it would still be possible by : calling 'unlock.attributes' first. : : Then I agree with you that it should not be made defunct; in general, if : there is a rational for using a feature in R and if someone relies on it, : then I believe one should be careful and consider alternatives before : removing it. I hope I did not break your code now by bringing it up to the R : core team. : : 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. : The Chambers example simply shows what can happen now -- not what should happen. The real question is what should happen.If all objects can have classes and attributes and if environments are objects then it follows that environments should be able to have classes and attributes too. If the language is to be made irregular in this respect then there needs to be a very good reason and none has been put forth, at least in this thread. __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] str() resets class for environments
Gabor Grothendieck [EMAIL PROTECTED] writes: : 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. : The Chambers example simply shows what can happen now -- not what should happen. The real question is what should happen.If all objects can have classes and attributes and if environments are objects then it follows that environments should be able to have classes and attributes too. If the language is to be made irregular in this respect then there needs to be a very good reason and none has been put forth, at least in this thread. 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? -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] str() resets class for environments
Peter Dalgaard p.dalgaard at biostat.ku.dk writes: : : Gabor Grothendieck ggrothendieck at myway.com writes: : : : 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. : : : : The Chambers example simply shows what can happen now -- not what should : happen. The real question is what should happen.If all objects : can have classes and attributes and if environments are objects then : it follows that environments should be able to have classes and : attributes too. If the language is to be made irregular in this : respect then there needs to be a very good reason and none has : been put forth, at least in this thread. : : 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? 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. __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] str() resets class for environments
: 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. Incidentally, 'pos.to.env(5)$x - 0' results in Error: Target of assignment expands to non-language object. Should I have expected that? BTW sorry about Outlook's mangling of the lines indents-- at least, I presume it's Outlook's fault. Mark *** Mark Bravington CSIRO (CMIS) PO Box 1538 Castray Esplanade Hobart TAS 7001 phone (61) 3 6232 5118 fax (61) 3 6232 5012 [EMAIL PROTECTED] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] str() resets class for environments
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. __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] str() resets class for environments
I noticed the following today --- str() seems to remove any extra class information added to an environment. e - new.env() class(e) [1] environment class(e) - c(foo, class(e)) class(e) [1] foo environment str(e) Classes 'foo', 'environment' length 0 environment class(e) [1] environment I'm not sure if this is related to the external pointer issue mentioned in the NEWS file. Is this the intended behavior for environments? (It happens in today's R-devel also.) version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major2 minor0.1 year 2004 month11 day 15 language R -roger -- Roger D. Peng http://www.biostat.jhsph.edu/~rpeng/ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] str() resets class for environments
On Tue, 23 Nov 2004, Roger D. Peng wrote: I noticed the following today --- str() seems to remove any extra class information added to an environment. e - new.env() class(e) [1] environment class(e) - c(foo, class(e)) class(e) [1] foo environment str(e) Classes 'foo', 'environment' length 0 environment class(e) [1] environment I'm not sure if this is related to the external pointer issue mentioned in the NEWS file. It is. Needed essentially the same fix. Is this the intended behavior for environments? (It happens in today's R-devel also.) I believe the intention is that you should not class environments. Luke suggested earlier that unclassing one be made an error, and I have now done that. Note that environments are not copied, and so everything you do to one instance you do to all other instances of it. Setting a class makes little sense for such an object. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] str() resets class for environments
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Prof
Brian Ripley
Sent: Tuesday, November 23, 2004 4:22 PM
To: Roger D. Peng
Cc: R Devel
Subject: Re: [Rd] str() resets class for environments
On Tue, 23 Nov 2004, Roger D. Peng wrote:
I noticed the following today --- str() seems to remove any extra
class
information added to an environment.
e - new.env()
class(e)
[1] environment
class(e) - c(foo, class(e))
class(e)
[1] foo environment
str(e)
Classes 'foo', 'environment' length 0 environment
class(e)
[1] environment
I'm not sure if this is related to the external pointer issue
mentioned in
the NEWS file.
It is. Needed essentially the same fix.
Is this the intended behavior for environments? (It happens
in today's R-devel also.)
I believe the intention is that you should not class
environments. Luke
suggested earlier that unclassing one be made an error, and I
have now
done that. Note that environments are not copied, and so
everything you
do to one instance you do to all other instances of it.
Setting a class
makes little sense for such an object.
Neither should one set attributes on environment! See thread The class
attribute on an environment seems buggy (PR#2159) from October 14, 2002;
here https://stat.ethz.ch/pipermail/r-devel/2002-October/025197.html and
https://stat.ethz.ch/pipermail/r-devel/2002-October/025203.html. John
Chambers gave the following example and explanation:
Any attribute of environments, not just the class, can be killed by
operating on the object locally in a function.
Example:
R f - function(x){ y - x; attr(y, foo) - NULL; y}
R ev - new.env()
R attr(ev, foo) - bar
R ev
environment: 0x8b515d4
attr(,foo)
[1] bar
R f(ev)
environment: 0x8b515d4
R ev
environment: 0x8b515d4
The reason is that the C routine `duplicate' does not duplicate an
environment OR its attributes.
To extend an environment into new class, the solution is to wrap it up in an
object of another basic data type, for instance as an element in a list or
as an attribute to NA, and set the class on the latter instead. Example:
object - NA
attr(object, .env) - new.env()
class(object) - MyClass
I do exactly this in my root class Object in the R.oo package. At the time,
I found accessing attributes to be a little bit faster than accessing
elements in list (plus NA objects are smaller than any other object).
Thus, I want to raise a warning on this, because after introducing the
$.environment and $-.environment in R v1.9.1, the above problem is
likely to show up more frequently; it is really tempting and it may take
awhile before you detect problems. Should attr()-, attributes()-,
class()- give an error when applied to an environment? I see no reason why
not.
Best wishes
Henrik
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] str() resets class for environments
Henrik Bengtsson wrote: Should attr()-, attributes()-, class()- give an error when applied to an environment? I see no reason why not. It would break the workspace-organization code in the 'mvbutils' package, which relies on being able to set and unset attributes of environments on the search path (specifically, the 'name' and 'path' attributes). So personally I'd much prefer not to have this happen! For the wider R community, I'm not sure how many users the 'mvbutils' package has, but I think it's a fair number judging from emails I get. If you do feel the extra security is vitally important, perhaps there could be 'lock.attributes' and 'unlock.attributes' functions for environments. The idea would be that each environment has an invisible (i.e. internal) mock-attribute locked, which would be TRUE by default (on creation of the environment). While locked is TRUE, any attempt to muck about with the environment's attributes would cause an error. But if you really did need to change attributes of that , it would still be possible by calling 'unlock.attributes' first. Mark *** Mark Bravington CSIRO (CMIS) PO Box 1538 Castray Esplanade Hobart TAS 7001 phone (61) 3 6232 5118 fax (61) 3 6232 5012 [EMAIL PROTECTED] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] str() resets class for environments
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 1:43 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Rd] str() resets class for environments Henrik Bengtsson wrote: Should attr()-, attributes()-, class()- give an error when applied to an environment? I see no reason why not. It would break the workspace-organization code in the 'mvbutils' package, which relies on being able to set and unset attributes of environments on the search path (specifically, the 'name' and 'path' attributes). So personally I'd much prefer not to have this happen! For the wider R community, I'm not sure how many users the 'mvbutils' package has, but I think it's a fair number judging from emails I get. If you do feel the extra security is vitally important, perhaps there could be 'lock.attributes' and 'unlock.attributes' functions for environments. The idea would be that each environment has an invisible (i.e. internal) mock-attribute locked, which would be TRUE by default (on creation of the environment). While locked is TRUE, any attempt to muck about with the environment's attributes would cause an error. But if you really did need to change attributes of that , it would still be possible by calling 'unlock.attributes' first. Then I agree with you that it should not be made defunct; in general, if there is a rational for using a feature in R and if someone relies on it, then I believe one should be careful and consider alternatives before removing it. I hope I did not break your code now by bringing it up to the R core team. 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. Cheers Henrik Mark *** Mark Bravington CSIRO (CMIS) PO Box 1538 Castray Esplanade Hobart TAS 7001 phone (61) 3 6232 5118 fax (61) 3 6232 5012 [EMAIL PROTECTED] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
