From rgentlem@hsph.harvard.edu  Thu Apr 22 20:06:05 1999
From: rgentlem@hsph.harvard.edu (Robert Gentleman)
Date: Thu, 22 Apr 1999 15:06:05 -0400 (EDT)
Subject: options
In-Reply-To: <199904220345.FAA28639@pubhealth.ku.dk>
Message-ID: <Pine.SV4.4.05.9904221440170.7304-100000@hsph.harvard.edu>


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


options
Robert Gentleman