Re: R-alpha: assignment scoping

Bill Venables (wvenable@attunga.stats.adelaide.edu.au)
Wed, 29 May 1996 12:51:27 +0930


Date: Wed, 29 May 1996 12:51:27 +0930
Message-Id: <9605290321.AA14412@attunga.stats.adelaide.edu.au>
From: Bill Venables <wvenable@attunga.stats.adelaide.edu.au>
To: Ross Ihaka <ihaka@stat.auckland.ac.nz>
Subject: Re: R-alpha: assignment scoping
In-Reply-To: <199605290252.OAA29733@stat.auckland.ac.nz>
 <199605290252.OAA29733@stat.auckland.ac.nz>

Ross Ihaka writes:
...
 > 
 > There are a number of possible solutions:
 > 
 > 1) Adopt a copy-on-modify strategy.  The function "[<-" duplicates
 >    its argument.  We tried this in the past, but the cost is very
 >    high.  consider for example:
 > 
 > 	x <- numeric(1000)
 > 	for(i in 1:1000) x[i] <- i
 > 
 >    Each time through the loop the array must be copied.  This
 >    generates 1000 copies of a 1000 element array.
 > 
 > 2) Recognize that x[1] <- 3 is a mutation of a local object.  If there
 >    is no "x" in the current evaluation frame, find an x from somewhere
 >    else and make a local copy of it.  Then continue with the mutation.
 >    This is in the spirit of what we do at present.  The check for a
 >    local "x" adds a small cost.  This will maintain compatibility with S.
 
Is there any dramatic differernce between 1. and 2.?

 > 3) Claim that x[1] <- 3 is an error in this context.  Attempting to
 >    mutate a local x when there is no local x seems like a rather
 >    odd thing to want to do.

This is my preferred option even if S does do something different.  

(While you are at it, I would personally favour outlawing, or at
least not implementing, the <<- operator.  If people are so
determined to write code with hideous side effects we shouldn't
make it easy for them!  Let them use "assign" and be done with
it.  Oh, and while you are at it, ditch the `_' assignment
operator.  I hate that too...:-)

 > 
 > 4) Fix the whole scoping business (this is what compiler-jocks like
 >    Luke are really after :-).  I like this idea too.  Perhaps all
 >    that is required (Luke?) is a scoping declaration like
 > 
 > 	f <- function() local x=x # local x getting its value from the global
 > 		{ x[1] <- 3 ; x}
 > 
 >    Variables not declared local must be global.
 >    Of course this would break S compatibility in a major way.

Attractive as it might be in some respects, I do not favour such
a major break with S.

I know I argue against it above, but I think some compatibility
with S is pretty important.  I envisage R will be used by many
students at home who will have to run the same code on S at Uni.,
for example.  As things are shaping up that looks like it might
be very feasible.

S version 4 will be a kind of a watershed, though, and will break
many things.  The entire OOP mechanism is radically different and
even the syntax will look different.  For example `=' will become
an allowed (in fact preferred) assignment operator, a la C.

 > For this particular bit of software one of 2) or 3) seems like
 > the right option, but I would like to pursue something like 4).
 > 

-- 
_________________________________________________________________
William Venables, Department of Statistics,  Tel.: +61 8 303 3026
The University of Adelaide,                  Fax.: +61 8 303 3696
South AUSTRALIA.     5005.   Email: Bill.Venables@adelaide.edu.au
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-testers mailing list -- To (un)subscribe, send
subscribe	or	unsubscribe
(in the "body", not the subject !)  To: r-testers-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-