[Rd] 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
    >> 
    >> ______________________________________________
    >> R-devel using r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel

    > ______________________________________________
    > R-devel using r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel