Dots are not fixed by make.names()

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Dots are not fixed by make.names()

Kirill Müller-2
Hi


It seems that names of the form "..#" and "..." are not fixed by
make.names(), even though they are reserved words. The documentation reads:

 > [...] Names such as ".2way" are not valid, and neither are the
reserved words.

 > Reserved words in R: [...] ... and ..1, ..2 etc, which are used to
refer to arguments passed down from a calling function, see ?... .

I have pasted a reproducible example below.

I'd like to suggest to convert these to "...#" and "....", respectively.
Happy to contribute PR.


Best regards

Kirill


make.names(c("..1", "..13", "..."))
#> [1] "..1"  "..13" "..."
`..1` <- 1
`..13` <- 13
`...` <- "dots"

mget(c("..1", "..13", "..."))
#> $..1
#> [1] 1
#>
#> $..13
#> [1] 13
#>
#> $...
#> [1] "dots"
`..1`
#> Error in eval(expr, envir, enclos): the ... list does not contain any
elements
`..13`
#> Error in eval(expr, envir, enclos): the ... list does not contain 13
elements
`...`
#> Error in eval(expr, envir, enclos): '...' used in an incorrect context

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Ellipsis and dot-dot-number [Re: Dots are not fixed by make.names()]

Kirill Müller-2
Hi


In addition to the inconsistency in make.names(), the text in ?Reserved
seems incomplete:

"Reserved words outside quotes are always parsed to be references to the
objects linked to in the ‘Description’, and hence they are not allowed
as syntactic names (see make.names). They **are** allowed as
non-syntactic names, e.g. inside backtick quotes."

`..1` and `...` are allowed for assigning, but these symbols cannot be
used in the context of a variable. Example:

`..1` <- 1
`..13` <- 13
`...` <- "dots"
`..1`
#> Error: ..1 used in an incorrect context, no ... to look in
`..13`
#> Error: ..13 used in an incorrect context, no ... to look in
`...`
#> Error in eval(expr, envir, enclos): '...' used in an incorrect context

Does the ?Reserved help page need to mention this oddity, or link to
more detailed documentation?


Best regards

Kirill


On 05.10.18 11:27, Kirill Müller wrote:

> Hi
>
>
> It seems that names of the form "..#" and "..." are not fixed by
> make.names(), even though they are reserved words. The documentation
> reads:
>
> > [...] Names such as ".2way" are not valid, and neither are the
> reserved words.
>
> > Reserved words in R: [...] ... and ..1, ..2 etc, which are used to
> refer to arguments passed down from a calling function, see ?... .
>
> I have pasted a reproducible example below.
>
> I'd like to suggest to convert these to "...#" and "....",
> respectively. Happy to contribute PR.
>
>
> Best regards
>
> Kirill
>
>
> make.names(c("..1", "..13", "..."))
> #> [1] "..1"  "..13" "..."
> `..1` <- 1
> `..13` <- 13
> `...` <- "dots"
>
> mget(c("..1", "..13", "..."))
> #> $..1
> #> [1] 1
> #>
> #> $..13
> #> [1] 13
> #>
> #> $...
> #> [1] "dots"
> `..1`
> #> Error in eval(expr, envir, enclos): the ... list does not contain
> any elements
> `..13`
> #> Error in eval(expr, envir, enclos): the ... list does not contain
> 13 elements
> `...`
> #> Error in eval(expr, envir, enclos): '...' used in an incorrect context
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Ellipsis and dot-dot-number [Re: Dots are not fixed by make.names()]

Martin Maechler
>>>>> Kirill Müller
>>>>>     on Fri, 8 Mar 2019 22:26:17 +0100 writes:
>>>>> Kirill Müller
>>>>>     on Fri, 8 Mar 2019 22:26:17 +0100 writes:

    > Hi


    > In addition to the inconsistency in make.names(), the text in ?Reserved
    > seems incomplete:

    >  "Reserved words outside quotes are always parsed to be references to the
    >   objects linked to in the ‘Description’, and hence they are not allowed
    >   as syntactic names (see make.names). They **are** allowed as
    >   non-syntactic names, e.g. inside backtick quotes."

    > `..1` and `...` are allowed for assigning, but these symbols cannot be
    > used in the context of a variable. Example:

    > `..1` <- 1
    > `..13` <- 13
    > `...` <- "dots"
    > `..1`
    > #> Error: ..1 used in an incorrect context, no ... to look in
    > `..13`
    > #> Error: ..13 used in an incorrect context, no ... to look in
    > `...`
    > #> Error in eval(expr, envir, enclos): '...' used in an incorrect context

    > Does the ?Reserved help page need to mention this oddity, or link to
    > more detailed documentation?

    > Best regards
    > Kirill

I see

> `..9` <- 999
> get("..9")
[1] 999
> `..9`
Error: ..9 used in an incorrect context, no ... to look in

> `...` <- "3 dots"
> `...`
Error: '...' used in an incorrect context
> get("...")
[1] "3 dots"
>

> assign("...", "3 DOTS")
> assign("..1", "1st dot arg")


So get() works for these, but `...` does not for getting but for
assignment.
OTOH,  assign() works for all, reserved words or not, so that
should not count.

Honestly, I'm not sure if the current behavior is necessary in
some sense or just a coincidence.

I do see that the C-internal isValidName()  [defined in the
grammar: gram.y (=> gram.c)] does say that "..." and "..1" etc
are valid names and that's what the C code of make.names() uses.

Also, as you know they *are* valid names as one does and should use them
unquoted although only to "get" and only inside functions.

So, no conclusion from here for now for the latter part.

For the first, about your make.names()  "inconsistency", I'd say
it *is* consistent because e.g.  ...  can be used without quotes
and hence is a valid name (mostly ;-).

OTOH,  make.names() being used to construct "valid" data frame
column names, maybe make.names() could be changed, probably via
a new optional logical argument say 'dotsValid = TRUE' which
when set to FALSE would also treat '...' and '..1' etc.

Unfortunately the code changes needed may be a bit ugly
as the consistency between  make.names() and {C level}  isValidName()
would be broken for  'dotsValid = FALSE'.

Martin



    > On 05.10.18 11:27, Kirill Müller wrote:
    >> Hi
    >>
    >>
    >> It seems that names of the form "..#" and "..." are not fixed by
    >> make.names(), even though they are reserved words. The documentation
    >> reads:
    >>
    >> > [...] Names such as ".2way" are not valid, and neither are the
    >> reserved words.
    >>
    >> > Reserved words in R: [...] ... and ..1, ..2 etc, which are used to
    >> refer to arguments passed down from a calling function, see ?... .
    >>
    >> I have pasted a reproducible example below.
    >>
    >> I'd like to suggest to convert these to "...#" and "....",
    >> respectively. Happy to contribute PR.
    >>
    >>
    >> Best regards
    >>
    >> Kirill
    >>
    >>
    >> make.names(c("..1", "..13", "..."))
    >> #> [1] "..1"  "..13" "..."
    >> `..1` <- 1
    >> `..13` <- 13
    >> `...` <- "dots"
    >>
    >> mget(c("..1", "..13", "..."))
    >> #> $..1
    >> #> [1] 1
    >> #>
    >> #> $..13
    >> #> [1] 13
    >> #>
    >> #> $...
    >> #> [1] "dots"
    >> `..1`
    >> #> Error in eval(expr, envir, enclos): the ... list does not contain
    >> any elements
    >> `..13`
    >> #> Error in eval(expr, envir, enclos): the ... list does not contain
    >> 13 elements
    >> `...`
    >> #> Error in eval(expr, envir, enclos): '...' used in an incorrect context
    >>
    >> ______________________________________________
    >> [hidden email] mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel

    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel