Of McGehee, Robert
Sent: Wednesday, April 25, 2012 5:19 PM
To: r-devel@r-project.org
Subject: [Rd] delayedAssign changing values
I'm not sure if this is a known peculiarity or a bug, but I stumbled across
what I think is very odd behavior from delayedAssign. In the below example x
switches values
On Apr 25, 2012, at 5:18 PM, McGehee, Robert wrote:
I'm not sure if this is a known peculiarity or a bug, but I stumbled across
what I think is very odd behavior from delayedAssign. In the below example x
switches values the first two times it is evaluated.
delayedAssign(x, {x - 2; x+3})
It is really strange that the delayedAssign is evaluated in the environment
it is called from, and thus can have side effects.
so
x=2
y=3
delayedAssign(x, {y - 7; y+3})
gives
x
[1] 10
y
[1] 7
Both x and y changed.
More intuitive would have been the behavior
x=2
y=3
delayedAssign(x, local({y -
On Apr 26, 2012, at 11:59 AM, ghostwheel wrote:
It is really strange that the delayedAssign is evaluated in the environment
it is called from,
Not quite, it is evaluated in the environment you specify - and you have
control over both environments ... see ?delayedAssign
and thus can have
Simon Urbanek wrote
More intuitive would have been the behavior
delayedAssign(x, local({y - 7; y+3}) )
which only changes x.
That is questionable - I think it is more logical for both environments to
be the same as default. Just think if it -- the point here is to access
lazy
On Apr 27, 2012, at 00:10 , ghostwheel wrote:
Simon Urbanek wrote
More intuitive would have been the behavior
delayedAssign(x, local({y - 7; y+3}) )
which only changes x.
That is questionable - I think it is more logical for both environments to
be the same as default. Just think if
I'm not sure if this is a known peculiarity or a bug, but I stumbled across
what I think is very odd behavior from delayedAssign. In the below example x
switches values the first two times it is evaluated.
delayedAssign(x, {x - 2; x+3})
x==x
[1] FALSE
delayedAssign(x, {x - 2; x+3})
x
[1] 5
On Wed, 26 Sep 2007, Gabor Grothendieck wrote:
I thought that perhaps the behavior in the previous post,
while inconsistent with the documentation, was not all that
harmful but I think its related to the following which is a potentially
serious bug.
The previous discussion already
Thanks for the explanation.
For lists either: (a) promises should be evaluated as they
enter the list or (b) promises evaluated as they exit the
list (i.e. as they are compared, inspected, etc.). I gather
the intent was (a) but it does not happen that way due to
a bug in R. Originally I
On Thu, 27 Sep 2007, Gabor Grothendieck wrote:
Thanks for the explanation.
For lists either: (a) promises should be evaluated as they
enter the list or (b) promises evaluated as they exit the
list (i.e. as they are compared, inspected, etc.).
What makes you conclude that this is what should
I thought that perhaps the behavior in the previous post,
while inconsistent with the documentation, was not all that
harmful but I think its related to the following which is a potentially
serious bug. z is a list with a single numeric component,
as the dput output verifies, yet we cannot
The last two lines of example(delayedAssign) give this:
e - (function(x, y = 1, z) environment())(1+2, y, {cat( HO! ); pi+2})
(le - as.list(e)) # evaluates the promises
$x
promise: 0x032b31f8
$y
promise: 0x032b3230
$z
promise: 0x032b3268
which contrary to the comment appears unevaluated. Is
Also note that earlier in the same example we have:
msg - old
delayedAssign(x, msg)
msg - new!
x #- new!
[1] new!
substitute(x) #- msg
x
R.version.string # Vista
[1] R version 2.6.0 alpha (2007-09-06 r42791)
That is substitute(x) gives x, not msg.
On 9/19/07, Gabor Grothendieck [EMAIL
On 5/19/2006 10:55 AM, Duncan Murdoch wrote:
On 5/19/2006 10:37 AM, Luke Tierney wrote:
On Fri, 19 May 2006, Duncan Murdoch wrote:
On 5/19/2006 9:54 AM, Roger D. Peng wrote:
I noticed something recently that I thought was odd:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within
I noticed something recently that I thought was odd:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or 2
gives me:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or two
x
Error: recursive default argument reference
My
On 5/19/2006 9:54 AM, Roger D. Peng wrote:
I noticed something recently that I thought was odd:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or 2
gives me:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or two
x
On Fri, 19 May 2006, Duncan Murdoch wrote:
On 5/19/2006 9:54 AM, Roger D. Peng wrote:
I noticed something recently that I thought was odd:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or 2
gives me:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit
On 5/19/2006 9:54 AM, Roger D. Peng wrote:
I noticed something recently that I thought was odd:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or 2
gives me:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or two
x
On 5/19/2006 10:37 AM, Luke Tierney wrote:
On Fri, 19 May 2006, Duncan Murdoch wrote:
On 5/19/2006 9:54 AM, Roger D. Peng wrote:
I noticed something recently that I thought was odd:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or 2
gives me:
Luke Tierney wrote:
On Fri, 19 May 2006, Duncan Murdoch wrote:
On 5/19/2006 9:54 AM, Roger D. Peng wrote:
I noticed something recently that I thought was odd:
delayedAssign(x, { Sys.sleep(5); 1 })
x ## Hit Ctrl-C within the first second or 2
gives me:
delayedAssign(x, {
20 matches
Mail list logo
