[Rd] The default behaviour of a missing entry in an environment

Duncan Murdoch murdoch at stats.uwo.ca
Fri Nov 13 22:24:21 CET 2009


On 11/13/2009 3:03 PM, Trishank Karthik Kuppusamy wrote:
> On Nov 13, 2009, at 2:47 PM, Duncan Murdoch wrote:
> 
>> Inconsistent with what happens for lists:
>> 
>> > x <- list()
>> > x$b
>> NULL
>> 
>> and attributes:
>> 
>> > attr(x, "b")
>> NULL
> 
> Ah, I see. I would claim that the same argument for default safety should apply here too.

I have mixed feelings about this.  If you follow the rule in your 
programs that setting x to NULL acts the same as not having x at all, 
then things are fine.  (Sometimes that's impossible, but it is what 
happens when you do the list assignment x$b <- NULL).  Use NA or some 
other special value to signal missing, and NULL will usually cause a 
visible error soon after if you mess up.

> 
>> It is already a little stricter than $ on a list:
>> 
>> > x$longname <- 1
>> > x$long
>> [1] 1
>> > e$longname <- 1
>> > e$long
>> NULL
> 
> I apologize that I cannot say that this is a good idea for reasons of safety and readability.

I think the list behaviour is a bad design, but it's been in the 
language forever, so we're stuck with it.  It's related to the bad 
design of function calls, where arguments can similarly be abbreviated.

Duncan Murdoch

> 
>> so I supposed we could make it even more strict, but there is an awful lot of code out there that uses tests like
>> 
>> if (!is.null(x <- e$b)) { do something with x }
>> 
>> and all of that would break.
> 
> Unfortunately, such code does make it harder to detect programming errors.
> I understand should the hands of R be tied by backwards-compatability; bad habits are hard to break.
> Thanks for your time.
> 
> -Trishank
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list