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
(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")
franklin parlamis
> version
_
platform powerpc-apple-darwin8.7.0
arch powerpc
os darwin8.7.0
system powerpc, darwin8.7.0
status alpha
major 2
minor 4.0
year 2006
month 09
day 06
svn rev 39158
language R
version.string R version 2.4.0 alpha (2006-09-06 r39158)
residual '*tmp*' variable after "[<-" error
3 messages · Parlamis Franklin, Brian Ripley
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.
(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. 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)
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
1 day later
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