Skip to content
Prev 51039 / 398500 Next

terminology for frames and environments

Peter Dalgaard <p.dalgaard at biostat.ku.dk>
Sure.
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.