R-alpha: .Options$digits do not (always) work.

Robert Gentleman rgentlem@stat.auckland.ac.nz
Thu, 14 Aug 1997 11:32:04 +1200 (NZST)

> From pd@kubism.ku.dk Wed Aug 13 23:11 NZS 1997
> To: Robert Gentleman <rgentlem@stat.auckland.ac.nz>
> Cc: R-devel@stat.math.ethz.ch
> Subject: Re: R-alpha: .Options$digits  do not (always) work.
> From: Peter Dalgaard BSA <p.dalgaard@kubism.ku.dk>
> Date: 13 Aug 1997 13:13:35 +0200
> Robert Gentleman <rgentlem@stat.auckland.ac.nz> writes:
> >   Well it isn't really clear what Splus does to get tst to work. It appears
> >   that they use some form of dynamic scope for Options. Clearly, the 
> >   assignment,
> >     .Options$digits<- xxxx
> >   creates a local copy of .Options and changes the value of that. The only
> >   way that print can find this local copy is if  it looks up the stack of
> >   calling functions to find it (or perhaps Splus squirrels it away somewhere
> Couldn't one have the digits argument of print default to
> .Options$digits (or is that eval(.Options$digits,
> sys.frame(sys.parent)) ??)

  Ah, but how far up do you look? That's fine if print is called from the
  function that sets .Options but what if it is called from a function that
  is called from the function that is....called from the function that set
  .Options. Looking back up all of these is dynamic scope. It is pretty
  inefficient for print to have to look in all these places for a .Options
  before it can do its thing.
  Alternatively you could say that print either gets .Options from the parent
  or from top level and so it looks in sys.frame(sys.parent) but then someone
  will want to do it from the grandparent and not understand why it doesn't
  I think it would be nice if Martin's example ended up in the FAQ (or a
  programming examples repository) with an explanation that the global
  .Options is checked; local copies aren't and that if you want to affect
  the global value you can do it in the manner shown in the example. I think
  this is a big change from what S does so it should be well signposted.
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