In ?exists it says: inherits: should the enclosing frames of the environment be searched? I believe what it is saying is that if inherits is TRUE and it fails to find the variable it will look in the parent environment and the parent of the parent, etc. (as opposed to looking in the calling frame next and the caller of the caller, etc.) Now I thought that standard terminology in R was: 1. enclosing environment or parent environment if one wanted to refer to the parent relative to the parent/child hierarchy of environments or 2. calling frame or parent frame if one wanted to refer to a parent relative to the environments corresponding to the functions in the stack of currently outstanding function calls but here we seem to be referring to a parent frame as a #1. Could someone please clarify what standard terminology is? Thanks.
Your understanding agrees with mine. I always figured that the parent environment is determined by the lexical scope while the parent frame is determined by the function call stack. -roger Gabor Grothendieck wrote:> > In ?exists it says: > > inherits: should the enclosing frames of the environment be searched? > > I believe what it is saying is that if inherits is TRUE and it fails > to find the variable it will look in the parent environment and > the parent of the parent, etc. (as opposed to looking in the calling > frame next and the caller of the caller, etc.) > > Now I thought that standard terminology in R was: > > 1. enclosing environment or parent environment if one wanted to > refer to the parent relative to the parent/child hierarchy > of environments > > or > > 2. calling frame or parent frame if one > wanted to refer to a parent relative to the environments > corresponding to the functions in the stack > of currently outstanding function calls > > but here we seem to be referring to a parent frame as a #1. > > Could someone please clarify what standard terminology is? > > Thanks. > > ______________________________________________ > R-help at stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >-- Roger D. Peng http://www.biostat.jhsph.edu/~rpeng/
"Gabor Grothendieck" <ggrothendieck at myway.com> writes:> In ?exists it says: > > inherits: should the enclosing frames of the environment be searched? > > I believe what it is saying is that if inherits is TRUE and it fails > to find the variable it will look in the parent environment and > the parent of the parent, etc. (as opposed to looking in the calling > frame next and the caller of the caller, etc.) > > Now I thought that standard terminology in R was: > > 1. enclosing environment or parent environment if one wanted to > refer to the parent relative to the parent/child hierarchy > of environments > > or > > 2. calling frame or parent frame if one > wanted to refer to a parent relative to the environments > corresponding to the functions in the stack > of currently outstanding function calls > > but here we seem to be referring to a parent frame as a #1. > > Could someone please clarify what standard terminology is?Not sure there is one... We have been approaching consensus on a couple of occasions, but (obviously) not been too good at enforcing it. I think the consensus is that a "frame" is a set of variable bindings (implemented as a hashed list), an environment is a frame plus an enclosing environment, i.e. a linked list of frames, terminated by NULL. It is occasionally necessary to refer to the individual frames as opposed to the whole list, which is exactly the point of the inherits argument. Notice that exists() talks about "enclosing" which is only ever used in sense #1 above. "parent" is used in both senses (which is a bit unfortunate -- not quite sure whether we have decided to get rid of parent.env() eventually). -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
> From: Peter Dalgaard <p.dalgaard at biostat.ku.dk> > Date: 14 June 2004 5:42:29 PM > > "Gabor Grothendieck" <ggrothendieck at myway.com> writes:>> ....................... >> Could someone please clarify what standard terminology is? > > Not sure there is one... > > We have been approaching consensus on a couple of occasions, but > (obviously) not been too good at enforcing it. I think the consensus > is that a "frame" is a set of variable bindings (implemented as a > hashed list), an environment is a frame plus an enclosing environment, > i.e. a linked list of frames, terminated by NULL. It is occasionally > necessary to refer to the individual frames as opposed to the whole > list, which is exactly the point of the inherits argument. > > Notice that exists() talks about "enclosing" which is only ever used > in sense #1 above. "parent" is used in both senses (which is a bit > unfortunate -- not quite sure whether we have decided to get rid of > parent.env() eventually). > > -- > O__ ---- Peter Dalgaard Blegdamsvej 3 > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907I have found it helpful, in trying to explain (to myself and others) what happens, to say that there is both a lexical stack and a call stack. Is that a legitimate use of terminology? John Maindonald email: john.maindonald at anu.edu.au phone : +61 2 (6125)3473 fax : +61 2(6125)5549 Centre for Bioinformation Science, Room 1194, John Dedman Mathematical Sciences Building (Building 27) Australian National University, Canberra ACT 0200.
Peter Dalgaard <p.dalgaard at biostat.ku.dk>> > > Gabor Grothendieck <ggrothendieck at myway.com> writes: > > > Thomas Lumley <tlumley <at> u.washington.edu> writes: > > > > > The distinction between "environment" and "frame" is important. The frame > > > is what you find things in with get(, inherits=FALSE) and the environment > > > uses get(, environment=TRUE). > > > > The thing I find odd about this one is that if we have: > > > > e <- new.env() > > e$x <- 1 > > f <- new.env(parent=e) > > f$x # gives an error > > (Actually not. I get NULL)Sure.> > > > then I would have expected x to be returned since f is an environment > > and x is in that environment. On the other hand, if an environment > > is defined to be the same as a frame (and there is some other word for > > an environment and its ancestors) then the above notation makes sense. > > Why? f$x is documented to be basically equivalent to > get("x",f,inherits=FALSE). In contrast, > > > evalq(x,f) > [1] 1 > > works fine.Well this certainly is more environment-like if one defines environment as a frame plus ancestors but it does not address the issue that if f is an environment in that sense then $ "should" pick out its components. One can define + to mean subtraction but that's not natural. I agree that it would have been nice if environment had been used to mean a frame plus its ancestors and class(f) was "frame", not "environment" but, of course, that's not how it turned out. I think its better to maintain backward compatiblity as far as possible and make the terms suit rather than use environment in a way which is inconsistent with the way R works. In fact, it might have been nice if there were both a frame class and an environment class so one could have either behavior. With this new setup R might have worked like this: # create parent environment # (in the sense of frame+ancestors) & populate Pe <- new.env(): Pe$x <- 1 # create child environment Ce <- new.env(parent=Pe) # create corresponding frames Pf <- as.frame(Pe); Cf <- as.frame(Ce) # x exists in child environment exists(Ce$x) # TRUE # but not in child frame exists(Cf$x) # FALSE Unfortunately this can't be done without breaking backward compatibility although it would still be possible to come up with a new word for environment plus ancestors (call it the envlist class) using environment as a synonym for frame. In that case this example would become: # create parent using envlist class & populate Pel <- new.envlist(): Pela$x <- 1 # create child environment+ancestors class Cel <- new.envlist(parent=Pel) # create corresponding environments (in the sense of frames) Pe <- as.env(Pel); Ce <- as.env(Cel) # x exists in child environment exists(Cel$x) # TRUE # but not in child frame exists(Ce$x) # FALSE and this one is upwardly compatible with the current R.
There was a typo in the previous version of this message. Pela should have been Pel. Here it is corrected. Peter Dalgaard <p.dalgaard at biostat.ku.dk>> > > Gabor Grothendieck <ggrothendieck at myway.com> writes: > > > Thomas Lumley <tlumley <at> u.washington.edu> writes: > > > > > The distinction between "environment" and "frame" is important. The frame > > > is what you find things in with get(, inherits=FALSE) and the environment > > > uses get(, environment=TRUE). > > > > The thing I find odd about this one is that if we have: > > > > e <- new.env() > > e$x <- 1 > > f <- new.env(parent=e) > > f$x # gives an error > > (Actually not. I get NULL)Sure.> > > > then I would have expected x to be returned since f is an environment > > and x is in that environment. On the other hand, if an environment > > is defined to be the same as a frame (and there is some other word for > > an environment and its ancestors) then the above notation makes sense. > > Why? f$x is documented to be basically equivalent to > get("x",f,inherits=FALSE). In contrast, > > > evalq(x,f) > [1] 1 > > works fine.Well this certainly is more environment-like if one defines environment as a frame plus ancestors but it does not address the issue that if f is an environment in that sense then $ "should" pick out its components. One can define + to mean subtraction but that's not natural. I agree that it would have been nice if environment had been used to mean a frame plus its ancestors and class(f) was "frame", not "environment" but, of course, that's not how it turned out. I think its better to maintain backward compatiblity as far as possible and make the terms suit rather than use environment in a way which is inconsistent with the way R works. In fact, it might have been nice if there were both a frame class and an environment class so one could have either behavior. With this new setup R might have worked like this: # create parent environment # (in the sense of frame+ancestors) & populate Pe <- new.env(): Pe$x <- 1 # create child environment Ce <- new.env(parent=Pe) # create corresponding frames Pf <- as.frame(Pe); Cf <- as.frame(Ce) # x exists in child environment exists(Ce$x) # TRUE # but not in child frame exists(Cf$x) # FALSE Unfortunately this can't be done without breaking backward compatibility although it would still be possible to come up with a new word for environment plus ancestors (call it the envlist class) using environment as a synonym for frame. In that case this example would become: # create parent using envlist class & populate Pel <- new.envlist(): Pel$x <- 1 # create child environment+ancestors class Cel <- new.envlist(parent=Pel) # create corresponding environments (in the sense of frames) Pe <- as.env(Pel); Ce <- as.env(Cel) # x exists in child environment exists(Cel$x) # TRUE # but not in child frame exists(Ce$x) # FALSE and this one is upwardly compatible with the current R.