From simon.urbanek at r-project.org  Thu Apr 26 17:26:01 2012
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Thu, 26 Apr 2012 11:26:01 -0400
Subject: [Rd] delayedAssign changing values
In-Reply-To: <17B09E7789D3104E8F5EEB0582A8D66FCD1EAC8145@MSGRTPCCRF2WIN.DMN1.FMR.COM>
References: <17B09E7789D3104E8F5EEB0582A8D66FCD1EAC8145@MSGRTPCCRF2WIN.DMN1.FMR.COM>
Message-ID: <ED11A19C-0066-4D2C-845C-C41747A94BF5@r-project.org>


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})
>> x==x
> [1] FALSE
> 
>> delayedAssign("x", {x <- 2; x+3})
>> x
> [1] 5
>> x
> [1] 2
> 
> The ?delayedAssign documentation says that "after [evaluation], the value is fixed and the expression will not be evaluated again." However, this appears not to be true.

It is actually true, the value is not evaluated twice: your evaluation of "x" has modified the value of "x" (hence it is no longer a promise) so what you get in the next evaluation is the value that you have set as a side-effect of the promise evaluation. However, the forced value of the promise it still the value returned by the evaluated expression. YOu can see that it is the case by simply adding a function with side-effect (like cat) into your expression.


> Is this a bug, or just a good way to write extremely obfuscated code?
> 

That is a good question and I don't know the answer. The docs don't say which value will be fixed so it could be either way, but intuitively I would expect the promise evaluation to override side-effects.

Cheers,
Simon



[Rd] delayedAssign changing values
Simon Urbanek