R devel - Jul 2013 - The *tmp* variable

When complex assignments are performed, the R interpreter creates, then
removes a special variable *tmp*. However, when byte compiling is enabled,
it seems that a different mechanism for making compound assignments is used.

Would it be possible to eliminate *tmp* from interpreted R code as well? It
might be useful for a function to lock its own environment, and the
appearance and disappearance of *tmp* generally precludes that.

(For example, a function might lock its own environment to guard against
lexical-scope-breaking ambiguities such as

x <- 1
f <- function() {
   if (runif() < 0.5) {
    x <- x+1
  }
  x
}

where it is not clear where the returned x comes from inside or outside f.)

	[[alternative HTML version deleted]]

Peter:

(Your function doesn't work -- you need to specify runif(1))

What ambiguity?

In the assignment within f(), x <- x+1,

the "x" on the rhs is a free variable in the function, and is
therefore looked for in the environment where the function was
defined. The x on the lhs is defined within the function only.

No matter what f() returns, x remains 1 in the environment from which
f is called. The function does not "return x" -- it returns a value,
which you can assign as you wish.

So ???
(and apologies if I'm missing something obvious).

Cheers,
Bert

On Sat, Jul 6, 2013 at 9:11 PM, Peter Meilstrup
<peter.meilstrup at gmail.com> wrote:
> When complex assignments are performed, the R interpreter creates, then
> removes a special variable *tmp*. However, when byte compiling is enabled,
> it seems that a different mechanism for making compound assignments is
used.
>
> Would it be possible to eliminate *tmp* from interpreted R code as well? It
> might be useful for a function to lock its own environment, and the
> appearance and disappearance of *tmp* generally precludes that.
>
> (For example, a function might lock its own environment to guard against
> lexical-scope-breaking ambiguities such as
>
> x <- 1
> f <- function() {
>    if (runif() < 0.5) {
>     x <- x+1
>   }
>   x
> }
>
> where it is not clear where the returned x comes from inside or outside f.)
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 

Bert Gunter
Genentech Nonclinical Biostatistics

Internal Contact Info:
Phone: 467-7374
Website:
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm

The R interpreter does what it does at run time. The ambiguity is in
reasoning at any time _other than run time_ which environment the returned
value of 'x' is taken from.

This is one reason why R has been profiled to spend a significant amount of
time looking up names (
http://www.cs.purdue.edu/homes/jv/pubs/ecoop12.pdf-- see also:
http://xianblog.wordpress.com/2010/09/13/simply-start-over-and-build-something-better/).
In languages with strict lexical scope, all var references are
straightforwardly compiled into pointer jumps.

But my concern is that it is generally bad _style_ to have bindings that
are ambiguous in scope. Locking function environments would turn those
cases, if they occur, into errors that can be caught and corrected.

Peter


On Sat, Jul 6, 2013 at 9:36 PM, Bert Gunter <gunter.berton@gene.com>
wrote:
> Peter:
>
> (Your function doesn't work -- you need to specify runif(1))
>
> What ambiguity?
>
> In the assignment within f(), x <- x+1,
>
> the "x" on the rhs is a free variable in the function, and is
> therefore looked for in the environment where the function was
> defined. The x on the lhs is defined within the function only.
>
> No matter what f() returns, x remains 1 in the environment from which
> f is called. The function does not "return x" -- it returns a
value,
> which you can assign as you wish.
>
> So ???
> (and apologies if I'm missing something obvious).
>
> Cheers,
> Bert
>
> On Sat, Jul 6, 2013 at 9:11 PM, Peter Meilstrup
> <peter.meilstrup@gmail.com> wrote:
> > When complex assignments are performed, the R interpreter creates,
then
> > removes a special variable *tmp*. However, when byte compiling is
> enabled,
> > it seems that a different mechanism for making compound assignments is
> used.
> >
> > Would it be possible to eliminate *tmp* from interpreted R code as
well?
> It
> > might be useful for a function to lock its own environment, and the
> > appearance and disappearance of *tmp* generally precludes that.
> >
> > (For example, a function might lock its own environment to guard
against
> > lexical-scope-breaking ambiguities such as
> >
> > x <- 1
> > f <- function() {
> >    if (runif() < 0.5) {
> >     x <- x+1
> >   }
> >   x
> > }
> >
> > where it is not clear where the returned x comes from inside or
outside
> f.)
> >
> >         [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
>
> Bert Gunter
> Genentech Nonclinical Biostatistics
>
> Internal Contact Info:
> Phone: 467-7374
> Website:
>
>
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
>
	[[alternative HTML version deleted]]