Re: [Rd] The *tmp* variable
Peter:
(Your function doesn't work -- you need to specify runif(1))
What ambiguity?
In the assignment within f(), x - x+1,
the x on the rhs is a free variable in the function, and is
therefore looked for in the environment where the function was
defined. The x on the lhs is defined within the function only.
No matter what f() returns, x remains 1 in the environment from which
f is called. The function does not return x -- it returns a value,
which you can assign as you wish.
So ???
(and apologies if I'm missing something obvious).
Cheers,
Bert
On Sat, Jul 6, 2013 at 9:11 PM, Peter Meilstrup
peter.meilst...@gmail.com wrote:
When complex assignments are performed, the R interpreter creates, then
removes a special variable *tmp*. However, when byte compiling is enabled,
it seems that a different mechanism for making compound assignments is used.
Would it be possible to eliminate *tmp* from interpreted R code as well? It
might be useful for a function to lock its own environment, and the
appearance and disappearance of *tmp* generally precludes that.
(For example, a function might lock its own environment to guard against
lexical-scope-breaking ambiguities such as
x - 1
f - function() {
if (runif() 0.5) {
x - x+1
}
x
}
where it is not clear where the returned x comes from inside or outside f.)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Bert Gunter
Genentech Nonclinical Biostatistics
Internal Contact Info:
Phone: 467-7374
Website:
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The *tmp* variable
Thanks, Peter. Now I get it.
It _was_ obvious!
-- Bert
On Sat, Jul 6, 2013 at 10:22 PM, Peter Meilstrup
peter.meilst...@gmail.com wrote:
The R interpreter does what it does at run time. The ambiguity is in
reasoning at any time _other than run time_ which environment the returned
value of 'x' is taken from.
This is one reason why R has been profiled to spend a significant amount of
time looking up names ( http://www.cs.purdue.edu/homes/jv/pubs/ecoop12.pdf
-- see also:
http://xianblog.wordpress.com/2010/09/13/simply-start-over-and-build-something-better/
). In languages with strict lexical scope, all var references are
straightforwardly compiled into pointer jumps.
But my concern is that it is generally bad _style_ to have bindings that are
ambiguous in scope. Locking function environments would turn those cases, if
they occur, into errors that can be caught and corrected.
Peter
On Sat, Jul 6, 2013 at 9:36 PM, Bert Gunter gunter.ber...@gene.com wrote:
Peter:
(Your function doesn't work -- you need to specify runif(1))
What ambiguity?
In the assignment within f(), x - x+1,
the x on the rhs is a free variable in the function, and is
therefore looked for in the environment where the function was
defined. The x on the lhs is defined within the function only.
No matter what f() returns, x remains 1 in the environment from which
f is called. The function does not return x -- it returns a value,
which you can assign as you wish.
So ???
(and apologies if I'm missing something obvious).
Cheers,
Bert
On Sat, Jul 6, 2013 at 9:11 PM, Peter Meilstrup
peter.meilst...@gmail.com wrote:
When complex assignments are performed, the R interpreter creates, then
removes a special variable *tmp*. However, when byte compiling is
enabled,
it seems that a different mechanism for making compound assignments is
used.
Would it be possible to eliminate *tmp* from interpreted R code as well?
It
might be useful for a function to lock its own environment, and the
appearance and disappearance of *tmp* generally precludes that.
(For example, a function might lock its own environment to guard against
lexical-scope-breaking ambiguities such as
x - 1
f - function() {
if (runif() 0.5) {
x - x+1
}
x
}
where it is not clear where the returned x comes from inside or outside
f.)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Bert Gunter
Genentech Nonclinical Biostatistics
Internal Contact Info:
Phone: 467-7374
Website:
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
--
Bert Gunter
Genentech Nonclinical Biostatistics
Internal Contact Info:
Phone: 467-7374
Website:
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] The *tmp* variable
When complex assignments are performed, the R interpreter creates, then
removes a special variable *tmp*. However, when byte compiling is enabled,
it seems that a different mechanism for making compound assignments is used.
Would it be possible to eliminate *tmp* from interpreted R code as well? It
might be useful for a function to lock its own environment, and the
appearance and disappearance of *tmp* generally precludes that.
(For example, a function might lock its own environment to guard against
lexical-scope-breaking ambiguities such as
x - 1
f - function() {
if (runif() 0.5) {
x - x+1
}
x
}
where it is not clear where the returned x comes from inside or outside f.)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The *tmp* variable
The R interpreter does what it does at run time. The ambiguity is in
reasoning at any time _other than run time_ which environment the returned
value of 'x' is taken from.
This is one reason why R has been profiled to spend a significant amount of
time looking up names (
http://www.cs.purdue.edu/homes/jv/pubs/ecoop12.pdf-- see also:
http://xianblog.wordpress.com/2010/09/13/simply-start-over-and-build-something-better/).
In languages with strict lexical scope, all var references are
straightforwardly compiled into pointer jumps.
But my concern is that it is generally bad _style_ to have bindings that
are ambiguous in scope. Locking function environments would turn those
cases, if they occur, into errors that can be caught and corrected.
Peter
On Sat, Jul 6, 2013 at 9:36 PM, Bert Gunter gunter.ber...@gene.com wrote:
Peter:
(Your function doesn't work -- you need to specify runif(1))
What ambiguity?
In the assignment within f(), x - x+1,
the x on the rhs is a free variable in the function, and is
therefore looked for in the environment where the function was
defined. The x on the lhs is defined within the function only.
No matter what f() returns, x remains 1 in the environment from which
f is called. The function does not return x -- it returns a value,
which you can assign as you wish.
So ???
(and apologies if I'm missing something obvious).
Cheers,
Bert
On Sat, Jul 6, 2013 at 9:11 PM, Peter Meilstrup
peter.meilst...@gmail.com wrote:
When complex assignments are performed, the R interpreter creates, then
removes a special variable *tmp*. However, when byte compiling is
enabled,
it seems that a different mechanism for making compound assignments is
used.
Would it be possible to eliminate *tmp* from interpreted R code as well?
It
might be useful for a function to lock its own environment, and the
appearance and disappearance of *tmp* generally precludes that.
(For example, a function might lock its own environment to guard against
lexical-scope-breaking ambiguities such as
x - 1
f - function() {
if (runif() 0.5) {
x - x+1
}
x
}
where it is not clear where the returned x comes from inside or outside
f.)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Bert Gunter
Genentech Nonclinical Biostatistics
Internal Contact Info:
Phone: 467-7374
Website:
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] residual '*tmp*' variable after [- error
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, [EMAIL PROTECTED] 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] residual '*tmp*' variable after [- error
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 day06 svn rev39158 language R version.string R version 2.4.0 alpha (2006-09-06 r39158) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] residual '*tmp*' variable after [- error
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, [EMAIL PROTECTED] 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
