From murdoch at stats.uwo.ca  Tue Feb  8 23:57:09 2005
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Tue Feb  8 23:55:54 2005
Subject: [Rd] Environment with no parent?
In-Reply-To: <x24qgmojys.fsf@biostat.ku.dk>
References: <nl2i01h7pffsdrsmrfoft00ro069e5n8cu@4ax.com>
	<x24qgmojys.fsf@biostat.ku.dk>
Message-ID: <esci01p52n37u6urqulun6ts464rju564c@4ax.com>

On 08 Feb 2005 21:49:47 +0100, Peter Dalgaard
<p.dalgaard@biostat.ku.dk> wrote :

>Duncan Murdoch <murdoch@stats.uwo.ca> writes:
>
>> Looking in envir.c, I see this:
>> 
>>     /* env is now R_NilValue, the base environment */
>> 
>> which doesn't give me much hope, but maybe there's a trick....
>> 
>> If not, would it be reasonable to install a magic "EmptyEnv" to use as
>> a parent in this sort of situation?
>> 
>
>I'm fairly sure the answer is "nope".
>
>It's been annoying me for years, for language aesthetic reasons
>mostly, but also with some consideration of cases like yours, and I've
>been on the brink of implementing a version where the base environment
>was a true environment. Apart from the usual issue of "round tuits",
>I was held back by the fact that one has to consider at least two things:
>
>(a) efficiency. Is it expensive no longer to have the base functions
>bound directly to their symbol? (My gut feeling is that with suitable
>hashing and cacheing, the penalty is minimal.)
>
>(b) you can *only* use get and simple variable retrieval in a non-base
>environment with a NULL parent (eval(x <- 1, envir=foo) would give
>'couldn't find function "<-"' or so). This could cause some confusion.

(b) means that the default should stay the way it is, but I think
there should be a way to set up a truly empty environment.  We have a
fair number of cases where envir=NULL is used, so it would be safest
to make it a different value -- even if NULL is the obvious value for
an empty environment.

Duncan Murdoch


[Rd] Environment with no parent?
Duncan Murdoch