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 promises environments 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 <[EMAIL PROTECTED]> writes: > > > On Wed, 5 May 2004, Duncan Murdoch wrote: > > > > > On Wed, 5 May 2004 20:20:51 +0100 (BST), Prof Brian Ripley > > > <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html