[Rd] Assignment to string

The documentation for assignment says:

     In all the assignment operator expressions, 'x' can be a name or
     an expression defining a part of an object to be replaced (e.g.,
     'z[[1]]').  A syntactic name does not need to be quoted, though it
     can be (preferably by backticks).

         "foo" <- 23; foo
         # returns 23
         > is.name("foo")
         [1] FALSE

Is this a documentation error or an implementation error?

The coercion is not happening at parse time:

    class(quote("foo"<-3)[[2]])
    [1] "character"

In fact, bizarrely, not only does it coerce to a name, it actually *modifies* the parse tree:

> gg <- quote("hij" <- 4)
> gg

    "hij" <- 4
> eval(gg)
> gg

    hij <- 4

• The cases below only come up with expression trees generated programmatically as far as I know, so are much more marginal cases. ***

The <- operator even allows the left-hand-side to be of length > 1, though it just ignores the other elements, with the same side effect as before:

> gg <- quote(x<-44)
> gg[[2]] <- c("x","y")
> gg

    c("x", "y") <- 44
> eval(gg)
> x

    [1] 44
> y

    Error: object "y" not found
> gg

    x <- 44

None of this is documented in ? <-, and it is rather a surprise that evaluating an expression tree can modify it. I admit we had a feature (performance hack) like this in MacLisp years ago, where expanded syntax macros replaced the source code of the macro, but it was a documented, general, and optional part of the macro mechanism.

Another little glitch:

    gg <- quote(x<-44); gg[[2]] <- character(0); eval(gg)     Error in eval(expr, envir, enclos) :       'getEncChar' must be called on a CHARSXP

This looks like an internal error that users shouldn't see.

           -s

        [[alternative HTML version deleted]]