surprising behaviour of names<-
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