[Rd] dput(as.list(function...)...) bug

[Duncan Murdoch]

On 23/03/2009 7:37 PM, Stavros Macrakis wrote:
> Tested in R 2.8.1 Windows
> 
>> ff <- formals(function(x)1)
>> ff1 <- as.list(function(x)1)[1]
> # ff1 acts the same as ff in the examples below, but is a list rather
> than a pairlist
> 
>> dput( ff , control=c("warnIncomplete"))
> list(x = )
> 
> This string is not parsable, but dput does not give a warning as specified.

That's not what "warnIncomplete" is documented to do.  The docs (in 
?.deparseOpts) say

  'warnIncomplete' Some exotic objects such as environments,
           external pointers, etc. can not be deparsed properly.  This
           option causes a warning to be issued if any of those may give
           problems.

           Also, the parser in R < 2.7.0 would only accept strings of up
           to 8192 bytes, and this option gives a warning for longer
           strings.

As far as I can see, none of those conditions apply here:  ff is not one 
of those exotic objects or a very long string.  The really relevant 
comment is in the dput documentation:

"Deparsing an object is difficult, and not always possible."

Yes, it would be nice if deparsing and parsing were mutual inverses, but 
they're not, and are documented not to be.


>> dput( ff , control=c("all","warnIncomplete"))
> list(x = quote())
> 
> This string is parseable, but quote() is not evaluable, and again dput
> does not give a warning as specified.
> 
> In fact, I don't know how to write out ff$x. 

I don't know of any input that will parse to it.


  It appears to be the
> zero-length name:
> 
>     is.name(ff$x) => TRUE
>     as.character(ff$x) => ""

This may give you a hint:

 > y <- ff$x
 > y
Error: argument "y" is missing, with no default

It's a special internal thing that triggers the missing value error when 
evaluated.  It probably shouldn't be user visible at all.

Duncan Murdoch

> 
> but there is no obvious way to create such an object:
> 
>     as.name("") => execution error
>     quote(``) => parse error
> 
> The above examples should either produce a parseable and evaluable
> output (preferable), or give a warning.
> 
>             -s
> 
> PS As a matter of comparative linguistics, many versions of Lisp allow
> zero-length symbols/names.  But R coerces strings to symbols/names in
> a way that Lisp does not, so that might be an invitation to obscure
> bugs in R where it is rarely problematic in Lisp.
> 
> PPS dput(pairlist(23),control="all") also gives the same output as
> dput(list(23),control="all"), but as I understand it, pairlists will
> become non-user-visible at some point.
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel