Grokbase Groups R r-devel March 2009
FAQ
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.

Search Discussions

  • Wacek Kusnierczyk at Mar 23, 2009 at 11:53 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.
    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 at r-project.org mailing list
    https://stat.ethz.ch/mailman/listinfo/r-devel

    --
    -------------------------------------------------------------------------------
    Wacek Kusnierczyk, MD PhD

    Email: waku at 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
  • Duncan Murdoch at Mar 24, 2009 at 12:28 am

    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 at r-project.org mailing list
    https://stat.ethz.ch/mailman/listinfo/r-devel
  • William Dunlap at Mar 24, 2009 at 1:02 am

    -----Original Message-----
    From: r-devel-bounces at r-project.org
    [mailto:r-devel-bounces at r-project.org] On Behalf Of Duncan Murdoch
    Sent: Monday, March 23, 2009 5:28 PM
    To: Stavros Macrakis
    Cc: r-devel at 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))"<missing>"else 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 at r-project.org mailing list
    https://stat.ethz.ch/mailman/listinfo/r-devel
    ______________________________________________
    R-devel at r-project.org mailing list
    https://stat.ethz.ch/mailman/listinfo/r-devel
  • Peter Dalgaard at Mar 24, 2009 at 7:52 am

    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.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
  • Stavros Macrakis at Mar 24, 2009 at 2:02 pm
    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
  • Duncan Murdoch at Mar 24, 2009 at 2:30 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupr-devel @
categoriesr
postedMar 23, '09 at 11:37p
activeMar 24, '09 at 2:30p
posts7
users5
websiter-project.org
irc#r

People

Translate

site design / logo © 2022 Grokbase