From murdoch at stats.uwo.ca  Tue Mar 24 15:30:12 2009
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Tue, 24 Mar 2009 10:30:12 -0400
Subject: [Rd] dput(as.list(function...)...) bug
In-Reply-To: <8b356f880903240702r1fc09311rd4d2cd05898cb33a@mail.gmail.com>
References: <8b356f880903231637v4d5d879dqe51c2d52a73802e4@mail.gmail.com>	<49C82917.6090409@stats.uwo.ca>
	<8b356f880903240702r1fc09311rd4d2cd05898cb33a@mail.gmail.com>
Message-ID: <49C8EE74.6030306@stats.uwo.ca>

On 3/24/2009 10:02 AM, Stavros Macrakis wrote:
> Peter, Duncan,
> 
> I understand that the missing value indicator is special and will not
> behave like an ordinary value in evaluation. I was only discussing its
> handling in the text representation functions dput and dump.
> 
> Duncan,
> 
> You are absolutely right that "list(x=)" is parseable (though not
> evaluable).  My mistake.
> 
> However, the point stands that dput/dget do not successfully recreate
> the object, and do not give an error as promised in the documentation.
> 
> I said: "dput does not give a warning as specified" and you quoted
> ?.deparseOpts:
> 
>      Some exotic objects such as environments, external pointers, etc.
> can not [sic] be
>      deparsed properly.  This option causes a warning to be issued if
> any of those
>      may give problems....
> 
> You apparently read this to mean that only environments and external
> pointers are "exotic objects":
> 
>      That's not what "warnIncomplete" is documented to do....  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....
> 
> However, they are listed as examples ("such as"); and there is an
> "etc." indicating that there are other, unnamed, exotic objects (and
> the missing value indicator seems pretty exotic to me...).  What's
> more, the sentence explicitly says that the warning is issued "if
> *any* of those may give problems" (not "some"); the definition is not
> in terms of a list of "exotic objects", but in terms of the behavior
> of "giving problems".
> 
> That is the plain English sense of the passage, and also the
> substantively reasonable one.

It's a documentation problem.  There is not supposed to be a promise to 
warn in every case.

There are two ways to fix this:  the easy way is to patch the docs, the 
very hard way is to analyze the deparser, and make it detect every case 
where it will produce something that doesn't parse back to something 
identical to the original.  If you want to volunteer to do the latter, 
I'll hold off, otherwise I'll fix the docs to weaken the apparent promise.

Duncan Murdoch



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