From radford at cs.toronto.edu  Sat Nov  1 16:03:23 2014
From: radford at cs.toronto.edu (Radford Neal)
Date: Sat, 1 Nov 2014 11:03:23 -0400
Subject: [Rd]  ScalarLogical and setAttrib
In-Reply-To: <mailman.19.1414839607.13132.r-devel@r-project.org>
References: <mailman.19.1414839607.13132.r-devel@r-project.org>
Message-ID: <20141101150323.GA25355@cs.toronto.edu>

> From: Jeroen Ooms <jeroen.ooms at stat.ucla.edu>
>
> It seems like ScalarLogical returns a singleton object, which is not
> the case for ScalarInteger or ScalarReal. I am currently working
> around this using duplicate(ScalarLogical(0)), but was quite surprised
> by this behavior of ScalarLogical.

> From: Hadley Wickham <h.wickham at gmail.com>
> 
> I believe this is by design (and changed relatively recently). FALSE and
> TRUE are singletons, like NULL.


No, TRUE and FALSE aren't like NULL.  There's only ever one NULL, but
there can be many TRUE and FALSE objects.  For example, see below,
done with R-3.1.2:

  > .Internal(inspect(TRUE))
  @2d84488 10 LGLSXP g0c1 [NAM(2)] (len=1, tl=0) 1
  > .Internal(inspect(TRUE|FALSE))
  @2d84308 10 LGLSXP g0c1 [] (len=1, tl=0) 1

The problem is a combination of not documenting exactly what
ScalarLogical is supposed to do, and then changing what it does.

I think it's pretty reasonable for people to have assumed they could
attach an attribute to the result of ScalarLogical, given the lack of
any explicit documentation.  Of course, paranoid users would have
checked NAMED on the result to see it they need to duplicate it, but
the documentation on that is less explicit than it might be as well.

This is why pqR still returns an unshared object for ScalarLogical.
Internally, pqR has a ScalarLogicalMaybeShared function that returns the
shared version, which is in read-only memory so that any attempt to change
it will cause an error.  (Similarly, there are ScalarRealMaybeShared, etc.)

   Radford Neal



[Rd] ScalarLogical and setAttrib
Radford Neal