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 d
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
> l
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 hav
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", loca
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 <-
.@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf 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
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})
You or Peter stated that promises are internal so clearly they
should be evaluated going in or out of lists. Otherwise you get
the current situation.
If you had just wasted as much time as I have trying to debug
a program with promises you would immediately understand why
it was necessary
to be a
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 "s
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 thought
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 establi
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 compare
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 Grothe
Gabor Grothendieck wrote:
> 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
>
> $y
>
> $z
>
>
> which contrary to the comment appears unevaluat
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
$y
$z
which contrary to the comment appears unevaluated. Is the comment
wrong or is it supposed to return an ev
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 })
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:
>>>
>>> >
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
>>>
>>>
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
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);
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
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
>
22 matches
Mail list logo
