From ripley at stats.ox.ac.uk  Fri Sep 22 07:45:30 2006
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Fri, 22 Sep 2006 06:45:30 +0100 (BST)
Subject: [Rd] residual '*tmp*' variable after "[<-" error
In-Reply-To: <Pine.LNX.4.64.0609202304230.31076@gannet.stats.ox.ac.uk>
References: <736BC96C-5E09-4DD7-AD44-ACB6DB890102@mac.com>
	<Pine.LNX.4.64.0609202304230.31076@gannet.stats.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.0609220636560.10307@gannet.stats.ox.ac.uk>

On Wed, 20 Sep 2006, Prof Brian Ripley wrote:

> On Wed, 20 Sep 2006, Parlamis Franklin wrote:
>
>> self-sanity check prior to filing a bug report:
>> 
>> attempted replacement that generates an error leaves a '*tmp*'
>> variable in the global environment.
>> 
>> test <- 1:10
>> test[2:4] <- expression(e)
>> ls()
>> 
>> i've read section 3.4.4 of the "R Language Definition" which
>> discusses the mechanism for replacement, and it is not clear to me
>> whether this was intended, but i suspect not (to be honest, it's not
>> clear to me why the process as described doesn't generate an infinite
>> recursion -- perhaps the primitive treats the argument named '*tmp*'
>> different than other arguments).  i've also searched the R site, and
>> can't find this particular issue discussed.
>> 
>> even though, as below, i am using 2.4.0 alpha, this happens as well
>> in 2.3.1.
>> 
>> from my standpoint, desirable behavior would be:
>> 
>> (i) if an error occurs, remove the '*tmp*' variable
>
> That's a bug: it need a context set to clean up.

Fixed in 2.4.0

>> (ii) report the error as occurring in the original replacement call
>> (rather than the '*tmp*' replacement, which may be confusing to those
>> who haven't read the "R Language Definition")
>
> But by that point the call may have been transformed quite dramatically.
> I was going to suggest traceback() would give you a sensible call, but in 
> this case it is not doing so: at a quick glance that is also due to no 
> context being set.

That was true for some of the subassignment error messages, but not this 
one: it depended on whether error() or errorcall() was used.  Since it 
potentially changes error messages in package checking, I have tidied this 
up for 2.5.0 only.

> There is also the question as to whether this should have worked.  It 
> probably could be made to do so as
>
> test <- as.expression(test)
> test[2:4] <- expression(e)

Yes, this was just some missing cases in subassign.c which I have added 
for 2.5.0.  Here is a related case in R-devel:

> test <- 1:10
> try(test[2:4] <- ls) # fails
Error in test[2:4] <- ls : incompatible types (from closure to integer) in 
subassignment type fix

Compare 2.4.0 beta:

> test <- 1:10
> try(test[2:4] <- ls) # fails
Error in `[<-`(`*tmp*`, 2:4, value = function (name, pos = -1, envir = 
as.environment(pos),  :
         incompatible types (from closure to integer) in subassignment type 
fix


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
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, UK                Fax:  +44 1865 272595




[Rd] residual '*tmp*' variable after "[<-" error
Prof Brian Ripley