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

About this list Date view Thread view Subject view Author view Attachment view

From: Prof Brian Ripley (
Date: Thu 06 May 2004 - 21:46:21 EST

Message-id: <Pine.LNX.4.44.0405061206030.15757-100000@gannet.stats>

There is already a bug report PR#4364 on an aspect of this. The comment
there is

  dump somehow needs to recognize that expressions in lists
  probably need to be enclosed in quote().

  S does exactly the same though

(I think it is a symbol not a formal expression in the current examples.)

I believe it is rather difficult to determine what we cannot deparse
successfully, and trying to issue a warning/error would give a false sense
of security. The code (src/main/deparse.c) suggests that at least

external pointers
weak references

will not get a useful textual representation. I don't think the goal can
be as Peter describes -- it has to be more limited, and currently symbols
are also on the list. (We might be able to solve symbols, but it is far
from straightforward -- terms in formulae are symbols, for example, so we
cannot just add quote() around symbols and that does indeed break code.)

There may well be others: it was not so long ago that integer vectors were
dumped in a text representation that was read back in as numeric.

On 5 May 2004, Peter Dalgaard wrote:

> Prof Brian Ripley <> writes:
> > On Wed, 5 May 2004, Duncan Murdoch wrote:
> >
> > > On Wed, 5 May 2004 20:20:51 +0100 (BST), Prof Brian Ripley
> > > <> wrote :
> > >
> > > >I don't think it is a bug. Note that dump does not even claim to dump
> > > >lists let alone symbols, but ?dump says
> > > >
> > > > At present the implementation of 'dump' is very incomplete and it
> > > > really only works for functions and simple vectors.
> > > >
> > > >Given that, this is not unexpected. (Looks like more than one person did
> > > >not check the help page ....)
> > > >
> > > >I think save/load is a much safer way to handle saving R objects, and it
> > > >does work in PD's example.
> > >
> > > I'd still call it a bug, since 'dump("x"); source("dumpdata.R")' could
> > > change the meaning of x without any warning, and that can't be
> > > desirable behaviour.
> >
> > 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.)
> Weelll.. The goal of dump/dput is to create a construct that can be
> evaluated so as to yield the original object. This is one place where
> we fail to meet that goal, so I'll call it a bug, documented or not.
> Especially, since it is something we might actually be able to fix
> fairly simply (note "might" -- we've had our share of "fixes" that
> didn't in the deparsing area).
> > 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 don't disagree that save/load is a better strategy for data storage,
> but dump and friends do have the potential to create an *editable*
> text representation, so there is some point in trying to make them
> work predictably as far as possible.

Brian D. Ripley,        
Professor of Applied Statistics,
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________ mailing list PLEASE do read the posting guide!

About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.3 : Mon 31 May 2004 - 23:05:08 EST