[R] How to Describe R to Finance People

Richard A. O'Keefe ok at cs.otago.ac.nz
Wed Jun 9 07:55:10 CEST 2004


I wrote:
	> The scope rules (certainly the scope rules for S) were obviously
	> designed by someone who had a fanatical hatred of compilers and
	> wanted to ensure that the language could never be usefully
	> compiled.
Drat!  I forgot the semi-smiley!

Tony Plate <tplate at blackmesacapital.com> wrote:
	What in particular about the scope rules for S makes it tough
	for compilers?  The scope for ordinary variables seems pretty
	straightforward -- either local or in one of several global
	locations.

One of *several* global locations.
attach() is the big one.
I spent a couple of months trying to design a compiler that would
respect all the statements about variable access in "The (New) S
Programming Language" book.

	(Or are you referring to the feature of the get()
	function that it can access variables in any frame?)
	
That's part of it too.  Worse still is that you can create and
delete variables dynamically in any frame.  (Based on my reading of
the blue book, not on experiments with an S system.)  And on one
fairly natural reading of the blue book,

    f <- function (x) {
	z <- y "this is a global reference"
	y <- z + 1
	g()
	y/z "this is a local reference"
    }

whether a reference inside a function is local or global would be 
a dynamic* property even if the function g() couldn't zap the local
definition of y.
	
R has its own problems, like the fact than with(thingy, expression)
introduces local variables and you don't know WHICH local variables
until you look at the run-time value of thingy.  Actual transcript:

    > z <- 12
    > f <- function (d) with(d, z)
    > f(list())
    [1] 12
    > f(list(z=27))
    [1] 27

Is that reference to z a reference to the global z or to a local copy
of d$z?  We don't know until we find out whether d *has* a $z property.
How are you supposed to compile a language where you don't know which
variable references are global and which are local?

(Answer: it can be done, but it ain't pretty!)

In this trivial example, it's obvious that the intent is for z to come
from d, but (a) it isn't an error if it doesn't and (b) realistic examples
have more variables, some of which are often visible without 'with'.




More information about the R-help mailing list