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 <-
For the amusement of the listserver:
Making use of the counter-intuitive assignment properties of delayedAssign, a
co-worked challenged me to construct a delayedAssign of 'x' that causes 'x' to
change its value _every_ time it is evaluated. The example below does this;
each time 'x' is evaluate
