Re: [Rd] dput(as.list(function...)...) bug
Duncan Murdoch wrote: On 23/03/2009 7:37 PM, Stavros Macrakis wrote: 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. Yes, it actually is the zero-length name that is being used for this, but that is not really useful knowledge because it is forbidden to create them as `` or as.name(). We did briefly consider making the missing object a real R object, but the semantics are too weird: Basically, you can only assign it once, next time you get errors: x - alist(a=)$a missing(x) [1] TRUE y - x Error: argument x is missing, with no default l - alist(a=, b=2) l$b - x Error: argument x is missing, with no default And, as you think about it, you realize that you cannot disable these mechanisms, because _something_ has to trap use of missing arguments. It does actually work to define a function mvi() which returns the missing value indicator and have things like list(x= mvi(), b= quote(!x)) $x $b !x work. I'd hate writing its help page, though. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput(as.list(function...)...) bug
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. -s __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput(as.list(function...)...) bug
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput(as.list(function...)...) bug
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. same in 2.10.0 r48200, ubuntu 8.04 linux 32 bit dput( ff , control=c(all,warnIncomplete)) list(x = quote()) likewise. 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. It appears to be the zero-length name: is.name(ff$x) = TRUE as.character(ff$x) = 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. interestingly, quote(NULL) # NULL as.name(NULL) # Error in as.name(NULL) : # invalid type/length (symbol/0) in vector allocation æsj. vQ -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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- --- Wacek Kusnierczyk, MD PhD Email: w...@idi.ntnu.no Phone: +47 73591875, +47 72574609 Department of Computer and Information Science (IDI) Faculty of Information Technology, Mathematics and Electrical Engineering (IME) Norwegian University of Science and Technology (NTNU) Sem Saelands vei 7, 7491 Trondheim, Norway Room itv303 Bioinformatics Gene Regulation Group Department of Cancer Research and Molecular Medicine (IKM) Faculty of Medicine (DMF) Norwegian University of Science and Technology (NTNU) Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway Room 231.05.060 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dput(as.list(function...)...) bug
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. 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. It appears to be the zero-length name: is.name(ff$x) = TRUE as.character(ff$x) = 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput(as.list(function...)...) bug
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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput(as.list(function...)...) bug
-Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch Sent: Monday, March 23, 2009 5:28 PM To: Stavros Macrakis Cc: r-devel@r-project.org Subject: Re: [Rd] dput(as.list(function...)...) bug 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. The string list(x = ) is parsable: z - parse(text=list(x = )) Evaluating the resulting expression results in a run-time error: eval(z) Error in eval(expr, envir, enclos) : element 1 is empty; the part of the args list of 'list' being evaluated was: (x = ) That is the same sort of error you get from running list(,): list wants all of its arguments to be present. With other functions such a construct will run in R, although its result does not match that of S+ (or SV4): f-function(x,y,z)c(x=if(missing(x))missingelse x, y=if(missing(y))missing else y, z=if(missing(z))missing else z) R f(x=,2,3) x y z 2 3 missing S+ f(x=,2,3) x y z missing 2 3 or R f(y=,1,3) x y z 1 3 missing S+ f(y=,1,3) x y z 1 missing 3 R and S+ act the same if you skip an argument by position f(1,,3) x y z 1 missing 3 but differ if you use name=nothing: in S+ it skips an argument by name and in R it is ignored by ordinary functions (where typeof(func)==closure). I wouldn't say this is recommended or often used or the point of the original post. Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
