ESS assigns .Last.value to the wrong place in R

[Kurt Hornik]

>>>>> David Brahm writes:

> I repeat my emails of 11/15/01 and 2/26/02, since it looks like this ESS bug is
> still not fixed in ESS 5.1.23, and I think some resolution is needed.

> When help() is invoked, ESS makes a copy of .Last.value in the .GlobalEnv,
> which is *not* where R normally stores it (R stores it in package:base).
> When this copy becomes stale it leads to wrong answers.  The bug is in
> essd-r.el, lines 63-64:

>     (ess-retr-lastvalue-command
>      . ".Last.value <- get(\".ess.lvsave\",inherits=TRUE)\n") ; envir=1

> which should be changed (as I have done on my machine) to:

>     (ess-retr-lastvalue-command
>      . "assign(\".Last.value\", .ess.lvsave, envir=NULL)\n") ; package:base

> Here's an example of how things can go wrong:
R> find(".Last.value")
>    [1] "package:base"
R> 0+1
>    [1] 1
R> .Last.value
>    [1] 1
R> ?seq       # At this point a stale copy of .Last.value is written to pos=1
R> 0+2
>    [1] 2
R> .Last.value                                        # WHOOPS!  WRONG VALUE!
>    [1] 1
R> find(".Last.value")          # The right value is masked by the stale copy
>    [1] ".GlobalEnv"   "package:base"


> Whenever I bring this up, a debate begins over who should change (ESS
> or R).  In particular, my solution will not work if package:base is
> "sealed".  Here's the tail end of our last discussion:

> Rich Heiberger <rmh@surfer.sbm.temple.edu> wrote:
>> ... The effect of sealing package:base from the user means that R will have
>> to store .Last.value in .GlobalEnv, which is the place ESS is using.  This
>> in effect is your solution 2) Change R to store .Last.value in .GlobalEnv
>> 
>> Net result, ESS does not change behavior, R has already promised to
>> change behavior.

> and Kurt Hornik <hornik@mithrandir.hornik.net> replied:
>> Not at all.  Sealing base does not mean that .Last.value needs to be
>> stored in the user's workspace.  The standard approach would be to use
>> dynamic variables which are in fact functions with internal state
>> (typically maintained in their environments).  E.g., .libPaths() in R
>> 1.4 or better illustrates the idea.  There might be a .Last.value()
>> along these lines.  The most prominent example is options() which is
>> used for manipulating .Options (see also the R FAQ): this is currently
>> visible to the user but it really should not.
>> 
>> Let me discuss our strategy re .Last.value with some r-core members.

> Also, Rodney Sparapani <rsparapa@post.its.mcw.edu> suggested:
>> I may be in way over my head here.  But, I think there is a 4th solution.
>> Have ESS save .Last.value as some other variable in .GlobalEnv like
>> .Last.value.saved.  That way .Last.value would not be hidden, and it could
>> still be retreived if someone had done a help() or whatever.

> Any more thoughts?

I had raised this issue with a couple of r-core people, but without
coming to a final conclusion.  I think the underlying issue is rather
subtle: what is attempted by playing with .Last.value is somehow to
restore the 'state' of the system before ESS started 'invisibly'
interacting with it.  I have no idea if this makes sense conceptually in
a multithreaded setting.  (And the same applies to .Last.value, up to
some extent.)

I would actually prefer that we stop playing with .Last.value, and
document this.  If not, David's suggestion about assigning in envir =
NULL (i.e., the base package) is certainly preferable to what ESS
currently has, but will need to reviewed once name spaces are fully in
place.

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._