[Rd] strange increase in the reference number

[Duncan Murdoch]

On 12/07/2019 1:22 p.m., King Jiefei wrote:
> Hi,
> 
> I just found a strange increase in the reference number and I'm wondering
> if there is any reason for it, here is the code.
> 
>> a=c(1,2,3)
>> .Internal(inspect(a))
> @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(1)] (len=3, tl=0) 1,2,3
>> is.vector(a)
> [1] TRUE
>> .Internal(inspect(a))
> @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(7)] (len=3, tl=0) 1,2,3
> 
> The variable *a* initially has one reference number, after calling
> *is.vector* function, the reference number goes to 7, which I believe is
> the highest number that is allowed in R.  I also tried the other R
> functions, *is.atomic, is.integer* and *is.numeric* do not increase the
> reference number, but *typeof *will do. Is it intentional?

is.vector() is a closure that calls .Internal.  is.atomic(), 
is.integer() and is.numeric() are all primitives.

Generally speaking closures that call .Internal are easier to implement 
(e.g. is.vector can use the regular mechanism to set a default for its 
second argument), but less efficient in CPU time.  From it's help page, 
it appears that the logic for is.vector() is a lot more complex than for 
the others, so that implementation does make sense.

So why does NAMED go to 7?  Initially, the vector is bound to a.  Within 
is.vector, it is bound to the local variable x.  At this point there are 
two names bound to the same object, so it has to be considered 
immutable.  There's really no difference between any of the values of 2 
or more in the memory manager.  (But see 
http://developer.r-project.org/Refcnt.html for some plans.  That 
document is from about 5 years ago; I don't know the current state.)

Duncan Murdoch