[Rd] surprising behaviour of names<-

[Wacek Kusnierczyk]

Berwin A Turlach wrote:
>
>> sure!
>>     
>
> Glad to see that we agree on this.
>   

owe you a beer.

>   
>>> Read section 2.1.10 ("Environments") in the R
>>> Language Definition, 
>>>       
>> haven't objected to that.  i object to your 'r uses pass by value',
>> which is only partially correct.
>>     
>
> Well, I used qualifiers and did not stated it categorically. 
>   

indeed, you said "R supposedly uses call-by-value (though we know how to
circumvent that, don't we?)".

in that vain, R supposedly can be used to do valid statistical
computations (though we know how to circumvent it) ;)


>  
>   
>>>> and actually, in the example we discuss, 'names<-' does *not*
>>>> return an updated *tmp*, so there's even less to entertain.  
>>>>     
>>>>         
>>> How do you know?  Are you sure?  Have you by now studied what goes
>>> on under the hood?
>>>       
>> yes, a bit.  but in this example, it's enough to look into *tmp* to
>> see that it hasn't got the names added, and since x does have names,
>> names<- must have returned a copy of *tmp* rather than *tmp* changed:
>>    
>>     x = 1
>>     tmp = x
>>     x = 'names<-'(tmp, 'foo')
>>     names(tmp)
>>     # NULL
>>     
>
> Indeed, if you type these two commands on the command line, then it is
> not surprising that a copy of tmp is returned since you create a
> temporary object that ends up in the symbol table and persist after the
> commands are finished.
>   

what does command line have to do with it?

> Obviously, assuming that R really executes 
> 	*tmp* <- x
> 	x <- "names<-"('*tmp*', value=c("a","b"))
> under the hood, in the C code, then *tmp* does not end up in the symbol
> table 

no?

> and does not persist beyond the execution of 
> 	names(x) <- c("a","b")
>   

no?

i guess you have looked under the hood;  point me to the relevant code.

> This looks to me as one of the situations where a value of 1 is used
> for the named field of some of the objects involves so that a copy can
> be avoided.  That's why I asked whether you looked under the hood.
>   

anyway, what happens under the hood is much less interesting from the
user's perspective that what can be seen over the hood.  what i can see,
is that 'names<-' will incoherently perform in-place modification or
copy-on-assignment. 

yes, *if* you are able to predict the refcount of the object passed to
'names<-' *then* you can predict what 'names<-' will do, but in general
you may not have the chance.  and in general, this should not matter
because it should be unobservable, but it isn't.

back to your i += i++ example, the outcome may differ from a compiler to
a compiler, but, i guess, compilers will implement the order coherently,
so that whatever version they choose, the outcome will be predictable,
and not dependent on some earlier code.  (prove me wrong.  or maybe i'll
do it myself.)

>   
>> you suggested that "One reads the manual, (...) one reflects and
>> investigates, ..."
>>     
>
> Indeed, and I am not giving up hope that one day you will master this
> art.
>   

well, this time i meant you.


>   
>> -- had you done it, you wouldn't have asked the  question.
>>     
>
> Sorry, I forgot that you have a tendency to interpret statements
> extremely verbatim 

yes, i have two hooks installed:  one says \begin{verbatim}, the other
says \end{verbatim}.


> and with little reference to the context in which
> they are made.  

not that you're trying to be extremely accurate or polite here...

> I will try to be more explicit in future.
>   

it will certainly do good to you.


>>
>> i just can't get it why the manual does not manifestly explain what
>> 'names<-' does, and leaves you doing the guesswork you suggest.
>>     
>
> As I said before, patched to documentation are also welcome.
>   

i'll give it a try.


> Best wishes,
>   

hope you mean it.

likewise,
vQ