Assigning to a list within a loop (PR#175)

We noticed this bug in more complex code, but this succinctly
describes the phenomenon.

If you do not re-initialize a each time in the following loop,
the final value only is assigned to all places when the loop is
complete.

a <- b <- list()
for(i in 1:5) {

+	a$alpha <- i
+	b[[i]] <- a
+	}

unlist(b)

alpha alpha alpha alpha alpha 
    5     5     5     5     5 

If a is re-created each time, however the correct behaviour
happens:

b <- list()
for(i in 1:5) {

+	  a <- list(alpha = i)
+	  b[[i]] <- a
+	  }

unlist(b)

alpha alpha alpha alpha alpha 
    1     2     3     4     5 

version

           _                 
platform   i586-unknown-linux
arch       i586              
os         linux             
system     i586, linux       
status                       
status.rev 0                 
major      0                 
minor      64.0              
year       1999              
month      April             
day        8                 
language   R                 

Bill Venables & Berwin Turlach.

I think that worse things could happen, the problem seems to be around
 line 1486 of subassign (the first line is missing in the current source)

  1486              if( NAMED(y) ) y = duplicate(y);
  1487              VECTOR(x)[offset] = y;
  1488              break;
  1489

  I think that you need to duplicate y, and have added that line;
  but perhaps what you need to do is to increment NAMED of y(???)
  I'll commit it if Ross doesn't yell too loud

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Before I go too far down the wrong track we need to think a little bit
about how "options" is going to behave in a threaded environment. The
reason for this is that S uses "options" to control most of the error
handling.
 I'm sure that we want thread specific behaviour and that seems to imply
that "options" is going to have to be thread specific. Without worrying
about how we are going to achieve that, does anyone have any qualms
about this?
 Duncan has said that in S, when he threaded it, options was a frame 0
object and frame 0 was thread specific. We don't really have frames.
Conceptually it seems that we are going to have to stick an environment
between GlobalEnv and any evaluation envs where that environment 
contains thread specific items (perhaps all assignments along that
thread).


  As for error handling S offers:
    error, interrupt, and warning.expression
  as options. All of which are supposed to be expressions with no
arguments (no free variables I assume) that are evaluated when an
error, an interrupt or a warning occurs (if warning.expression is
non-null then options("warn") is ignored).
  I should get those in today.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Robert Gentleman <rgentlem@hsph.harvard.edu> writes:

 Duncan has said that in S, when he threaded it, options was a frame 0
object and frame 0 was thread specific. We don't really have frames.
Conceptually it seems that we are going to have to stick an environment
between GlobalEnv and any evaluation envs where that environment 
contains thread specific items (perhaps all assignments along that
thread).

Hmm. Ross has also been talking about "frame 0" when talking about
attachments to position 1. Does that fit in?

If I get the picture right (I've never tried threads in S), there may
be an alternative where the thread-specific environment sits on top of
the the environment from which the thread is started, rather than
GlobalEnv.

O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Robert Gentleman <rgentlem@hsph.harvard.edu> writes:

 Duncan has said that in S, when he threaded it, options was a frame 0
object and frame 0 was thread specific. We don't really have frames.
Conceptually it seems that we are going to have to stick an environment
between GlobalEnv and any evaluation envs where that environment 
contains thread specific items (perhaps all assignments along that
thread).

Hmm. Ross has also been talking about "frame 0" when talking about
attachments to position 1. Does that fit in?

If I get the picture right (I've never tried threads in S), there may
be an alternative where the thread-specific environment sits on top of
the the environment from which the thread is started, rather than
GlobalEnv.

Brian's comment is correct, only Duncan and John ever played with threaded
S and it currently doesn't work with some high probability (and Duncan
said he didn't think it ever would be publicly available).

I guess what I'm thinking is that all threads get started from GlobalEnv,
but that there has to be an extra thread specific env stuck in right
on top of GlobalEnv and before any evaluation envs (so that thread 
specific info can be handled appropriately).

However, having done a little reading over the past few days I'm a bit
discouraged about how difficult it will be to get this stuff correct.
According to at least one author, threads are hard but they are infinitely
easier than signal catching/exception handling. So making a function
thread-safe is possible (not all C level ones that we use are) making
it reentrant on an asynchronous signal is much more difficult.

I am also coming quickly to the belief that POSIX might be the right
coding standard for R. It at least has some standard stuff for letting
you know (at compile time) what level of thread safety is available in
the C library. 

Does that have bad implications for you and Guido, Brian? I'm a bit
worried because alot of the signal handling is if-def'd for Unix only.
Perhaps it should shift and be if-def'd for the correct level of 
POSIX?

What about the Mac?

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._