R-alpha: .Options$digits do not (always) work.
Thu, 14 Aug 1997 11:32:04 +1200 (NZST)
> From email@example.com Wed Aug 13 23:11 NZS 1997
> To: Robert Gentleman <firstname.lastname@example.org>
> Cc: Remail@example.com
> Subject: Re: R-alpha: .Options$digits do not (always) work.
> From: Peter Dalgaard BSA <firstname.lastname@example.org>
> Date: 13 Aug 1997 13:13:35 +0200
> Robert Gentleman <email@example.com> 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: firstname.lastname@example.org