[R] weirdness in sourc()ing a dump() (bug?)

[Duncan Murdoch]

On Wed, 5 May 2004 20:50:29 +0100 (BST), Prof Brian Ripley
<ripley at stats.ox.ac.uk> wrote :

>That's not what it says it does, and not what the S version achieves 
>either.  (Do see the documentation on `what is a bug' in the FAQ, which 
>does not agree with you.)

"If a command does the wrong thing, that is a bug. But be sure you
know for certain what it ought to have done."

This is a case where we disagree about what it ought to have done. The
documentation says

"This function takes a vector of names of R objects and produces
 text representations of the objects on a file or connection. A
 'dump' file can be 'source'd into another R (or S) session."

The error generated in the original example contradicts this, and the
incorrect value being loaded in my example contradicts the implication
that when 'source'd, the value will match the original one.

Later it says

"At present the implementation of 'dump' is very incomplete and it
really only works for functions and simple vectors."

Here's where we disagree about the interpretation.  If I understand
you correctly, you're saying that this implies that any behaviour at
all for other objects would be acceptable.  I'd say it's okay to have
limitations on the function, but it's too much of a contradiction with
the purpose of the function given in the initial description if it
silently corrupts data.

>I was trying to be constructive: save/load *is* supposed to reproduce
>objects, and it just not realistic to get dump/source to do that.  And we
>do warn about it in the documentation and I can see nowhere that
>recommends dump/save as a way of saving objects ....  (If there is such a 
>place, then that is a bug and needs fixing.)

I think we're both trying to be constructive.  I'm suggesting that the
internal dump code should check the type of inputs, and generate an
error when it gets something that it can't handle properly.

Duncan Murdoch