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

Peter Dalgaard BSA p.dalgaard@kubism.ku.dk
14 Aug 1997 10:30:44 +0200

Robert Gentleman <rgentlem@stat.auckland.ac.nz> writes:

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

Aha. Is this a case where S's "expression frame" does something useful
for once? I've always hated it because it prevents the whole language
from being self-similar: Run the good ol' read-eval-print loop and all
the assignments to frame 1 will get cleaned up between commands, make
a menu-style function that runs the same commands and the crud builds

Maybe we need some kind of limited support for dynamically scoped

   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