[Rd] The *tmp* variable

[Bert Gunter]

Thanks, Peter. Now I get it.

It _was_ obvious!

-- Bert

On Sat, Jul 6, 2013 at 10:22 PM, Peter Meilstrup
<peter.meilstrup at gmail.com> wrote:
> 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 at 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 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
>
>



-- 

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