[R] Why a list of NULL's are reduced to NULL?

Peng Yu pengyu.ut at gmail.com
Fri Dec 11 22:41:18 CET 2009


On Fri, Dec 11, 2009 at 2:50 PM, Don MacQueen <macq at llnl.gov> wrote:
> I would study the third party function and learn all the types it can
> return.
>
> After all if you don't know what type it's going to return, how can you
> possibly make *any* confident use of its output?
>
> Do you actually have this situation? A third part function that is so poorly
> documented that you can't (1) predict the type of its return, and (2) learn
> what its possible outputs are? Is this function from an R package downloaded
> from CRAN?

Shouldn't there be a better solution at the language level? Perl has a
strict mode and a non strict mode. If it is always better to return
the same type, which is the case in other strong typed language, then
it might better that there is such a mode in R to enforce the same
return type.

> At 12:24 PM -0600 12/11/09, Peng Yu wrote:
>>
>> On Fri, Dec 11, 2009 at 12:05 PM, hadley wickham <h.wickham at gmail.com>
>> wrote:
>>>>
>>>>  A very common situation is that the users don't know all the possible
>>>>  return types of 'some_third_party_function()'. If the users don't know
>>>>  all the return types, he/she can not make sure the return type of
>>>>  function(x) {...} be always the same. How do you deal with this case?
>>>
>>>  It's not that common.  It's pretty bad practice to return different
>>>  types from a function depending on the input parameters.  In many
>>>  languages this isn't even possible.
>>
>> I know this is a bad practice. But R doesn't have a way to forbid such
>> thing happen. To program defensively, I have to test even uncommon
>> case, unless it is impossible. When you use a third party software in
>> your code, do you just ignore the possibility that a function could
>> return different types?
>>
>>>  The solution is to write a function that takes the output from the
>>>  first function, inspects it, and coerces all possibilities to the same
>>>  type.
>>
>> How do you figure out all the possibilities?
>
> You can look at its code. You can try the entire range of inputs you
> anticipate giving to it (you are in charge of the inputs, so you can do
> this). You can talk to the person who wrote it (if that person is not
> available, and the function is just some anonymous thing you got from
> somewhere, you probably shouldn't place any confidence it its correctness).
>
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://*stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://*www.*R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
>
> --
> --------------------------------------
> Don MacQueen
> Environmental Protection Department
> Lawrence Livermore National Laboratory
> Livermore, CA, USA
> 925-423-1062
> --------------------------------------
>




More information about the R-help mailing list